borfo

That's unfortunate. It still works on the pi though... The GUI is unnecessary, but it doesn't prevent it from working. Maybe I'll try playing with the code sometime. Thanks.

[nevermind]

Yet another feature request, if it wouldn't be too difficult to implement: The BLM emulator app works on the Raspberry Pi () Could an option be added so that the app could be run headless, with no GUI? ...so that it could be run from the terminal on the raspberry pi, without having consume resources on the Pi by starting X? ...and maybe adding an argument that points to the xml config file? So you could run it something like this: pi@pi $ ./BLM --headless --config /home/pi/BLM/MIDIbox_BLM16x16.xml This would allow us to make and share a standard raspberry pi image that could be used to run the Novation BLMs.

The next set of things I'm planning on experimenting with on the SEQ are some new generative track types - it'll probably take me a while to get around to this, it's a bit of a more complicated project than the robotizer thing. And I'll probably implement first, since doing that will help me understand how track types are currently implemented. But I thought I'd post this thread to discuss some of the ideas I have and see if anyone can build on them or if anyone has any other interesting ideas. Particularly to see if TK has any thoughts about how this sort of thing would best be implemented. MUTABLE INSTRUMENTS GRIDS DRUM ALGORITHM The first generative thing I'd like to implement is something like the Mutable Instruments Grids algorithm as a track type (an earlier version of the same algorithm generates the drums on the Anushri). It's basically an x-y map filled with different drum patterns. There are also "density" settings for the individual drums. Depending on the x-y coordinates and density settings, the algorithm generates some very interesting drum patterns without much effort from the user. More info on the algorithm here: http://mutable-instruments.net/modules/grids/manual Very useful when you're just messing around and need a backing drum track... It would be a very powerful addition to the SEQ, I think, because you could do a lot more with it than can be done on the Grids module - you could automate moves on the X-Y map, and density settings, etc. You could use it to control sounds other than drums, and some interesting stuff could be done with loopbacks. I have Olivier's permission to port the code over to the SEQ and release it under the SEQ license. This could be implemented with a normal-ish pattern based edit screen with new parameter layers that could control automation of the X-Y Coordinates, change drum densities, etc., as well as doing the more standard stuff like controlling velocity, etc. OR it could be implemented without a pattern based edit screen, and any automated changes to x-y or densities could be done with a loopback CC track. Either way it would also have a config screen like a drum track type, with editing of MIDI assignments for the instruments as well as editing of the X-Y position and instrument densities. On the SEQ, the algorithm conceivably could control many more drums than the Grids module can control. This could also be very interesting combined with some random/robotizer-type features. I haven't worked this out 100% yet, so suggestions are welcome. For experimental purposes I may implement a basic version of this in the FX menu, just because I understand how that menu area works pretty well now, and we could make it into a track type later if TK likes it. CELLULAR AUTOMATA CONTROLLED GENERATIVE TRACK TYPES This idea is still a work in progress, but I think there are some interesting possibilities with using Cellular Automata for generating changing patterns that aren't quite "random", but have recurring features without being repetitive. They're pretty simple to generate, and a track type that generated a new iteration of one or more cellular automata with every step would probably not consume too many resources. Those automata could be used as sources of bits to produce music in a variety of ways... I've attached a simple python script (rename it to [sOMETHING].py) that visualizes a 64 bit wide strip of one-dimensional cellular automata data. It uses the three neighbouring "bits" above each bit to determine the state of that bit, and for the leftmost and rightmost bits it loops around to the other side of the strip to get the third "neighbour". If you look at the code, there are several rules in there - just move the one you want to see to the bottom of the rules section. Or make your own (most rules create fairly boring results, but of the 256 possible rules in the script, there are many that go on forever and are interesting). Here's the output of one rule: O OO O O OO OOO OO OO OOOOOO OOOOOOOO O OOO O O OO O OOO O OO O O OO OOOO OOOOOO OOOO O O OO O O OOO O O OOO O OOOOO OO OO OO OOOO O OO OO OO O OO OO O O OO O OOO OOO OOO O OO OO O OOOO O OO OO O O O O OOOO O OOO OOO O OOOO OOOOO OO OOO OOO OOO O O OO O O OO O O O O OOO OO OO OOO O O O O OOO O OOO O O O OO O O OOO O O OO O OOOOO O O O O O O O O O OOOO O OOO O O O O O OOOOOOO O O OOO O O O O O OO O O OO OO O O OOO O OO OO O OOOOO OOO O O OO O O O O O O O OO OO O O O O O OOO O O O OO O O O O O OOOO O OOOO OO O O OO OOOOOOO O O OO O OO O OO O O O OO O OO OOOOOO O OOOOO O OO O O OOOO O OO O O O OO O OOOO OOOO O OOOO OOO OO O OOO OOO OO OO O O O OO O OO OO OO OO OO O O OOOO O O O OOOOO O O OOO OO O O OOO OO OO OO OO OOO OOOOO O OOOO O O OOO O OOOOOO OOO OOO OO O O O OOO OO OO O O O O OOOO OO O O O OOOOOOOOOOO OOOO OO O OO O O OO OO O OO O O OOO OOOOO OOOOOOOOO OO O O OOOOO OOO O O OO OOO O OOO O OOOOOOO OO OOOOO O O OOOO O OOOOOOO O OO O OO OO O OO OOOOO O OO OOO O OO OOO O OOOOO O OOOO O O O O OOO OO OO O OO O O O O OOO OO OOO OO O OOOOOO O OOO O O OOOO O O OOOO O OO O O O O OO OOOO O O OO OO OOOOO OO O OOO OO O O O OO OOOO OOOO O OO OO OO O OOO OO O OO OO OOOO O OO OO OOO O O OOOOOO O OOOO OO OO OO O OOOO OO O O OOOO OOOOOO OOOO O O OO OO OOO OOO OO OO OO OOO O O OO OOOO O OO OO O O OO OO OO O OO O O OO O O O OO OO OO O O OOOO OO O O O O O OOO OOO OO O OO O OOO O OOOO OOO OO O OO OOO O OO O O OOO O O OOOOOO OO OO O O OOOOO O O O OOO OOOO O OOOO OO O OOOO OOO OO OO OOOO OOOOOO OO OOOO O OO O O OO O OO OOOOOOO O OO O OOOO OO OO OO OO O OOOOO O O OOOOO O OOOOOOOO O OO OOOOO O OO O OOO OOO O OOO OOO OO OOOOOO OO O O OOO OOO OOOOO OOO O O OO O O O O O OOOO O O OO OOO O O O OOO OO O OO OOO O OO OO O OO OOO OO OO O O OO OO O OO O O O O O O OO O O O O O OOOOO O O O OO OOO O OOOO OO OOOOOO OOOOO OO OOO OOO Bits in a one-dimensional cellular automaton have only two states, but it's possible for each "bit" to have many states in higher-dimensional cellular automata... It's pretty easy for each "bit" to have many possible states - certainly easy to create a set of rules that would generate 128-state "bits" that could be used directly as MIDI data (or you could just pull 7 bits from some offset in a one-dimensional automata). Morphing two automata together could be interesting as well. Using the same "rules" approach, but checking against already existing data on the SEQ instead of checking the previous iteration of an automaton to generate new states could create some interesting dependencies, too. (like checking notes in the note stack, and applying rules to that data to generate dependent new data) These tracks could have "profiles" composed of a set of rules that would determine how the cellular automata data is processed into MIDI signals, and would make the output more "musical" in different ways, with configurable parameters. Many different profiles could be developed for different types of track behaviour, even with different UIs and parameters. The user could select different profiles to get the tracks to behave in different ways. Or the automata could be used to automate changes to trigger layers like roll or repeat. There are a lot of possibilities. I'm not sure if these CA based track types would use a 16 step editor like the other track types do, and have separate configuration menus, or if the edit screen for these CA track types should just show the configuration parameters. Using a step editor as well as config menus could allow some neat automation of the CA parameters, but it might make things too complex. There are lots of other types of cellular automata that could be used. Conway's Game of Life is one that could conceivably be interesting implemented on the BLM, for example. ...I have a lot of experimenting to do to really flesh out this idea before I have any solid ideas on how it should be implemented (and there are probably several different implementations that would be useful), but I'd be interested to hear any comments or suggestions. There are other CA based sequencers out there, if you know of any particularly good implementations, let me know. ...and I'll set up a new branch of the code in the svn playground when I start experimenting with this stuff, since I don't want to break anything. auto.py.txt

I committed a few changes to seq_robotize.c - eliminated the unnecessary checks you pointed out, fewer random generator calls now, and the probability checking is now in its own function which bitmasks out 10 bit parts of 32 bit random numbers, and only gets new random numbers if and when required. It's a bit more efficient, seems to have shaved off about 5 - 7 uS. Thanks for all your help with this, by the way. A few more questions: Is there a preferred method for determining the number of the track that's currently being worked with from within, for example, SEQ_CORE_ScheduleEvent()? Can the current track number be determined from a seq_core_trk_t or seq_cc_trk_t object? ...or should I just pass the track number to SEQ_CORE_ScheduleEvent() as an argument if it's needed? Are there Doxygen documents specifically for the SEQ like there are for the NG? (http://ucapps.de/midibox_ng/doxygen/index.html) Is there a search interface for those NG docs? ....and a comment/question re: reusing bits of the same 32 bit number: I said "take bits 1-10, 2-11, 3-12, etc.,", which was a bit dumb... Wasn't thinking when I wrote that. Moving over by only one bit would obviously create a significant dependency... But since my randoms are 10 bit numbers, wouldn't shifting over further, say by 5 bits (taking bits 1-10, 6-15, 11-20, etc.) create enough randomness for this purpose, without too much dependency? I could get five 10bit pseudorandom numbers out of one 32 bit number that way... EDIT: Added the sustain robotizer. It adds 7-10 uS, but that seems to all be from the existing SUSTAIN implementation, not from the fact that it's being robotized. Edit Edit: Added the +Echo and the +Duplicate robotizers... These robotizers use the settings on the Echo and Duplicate FX pages, ignoring the enabled/disabled state of those FX. In other words: adjust the +Echo setting on the FX robotizer page to occasionally apply echo to notes, using the echo settings currently selected on the FX echo page. Change the settings on the Echo page to change the robotized echo. With all the robotizers enabled, the CPU usage goes up significantly, but I think most of that is coming from the other FX implementations, not too much from the robotizer. The robotizer seems to add +18 uS or less compared to just having Echo, sustain, and duplicate on. Optimizing suggestions are more than welcome, of course. LPC-project.hex STM-project.hex

One pair please.

What sort of stopwatch +uS number should I be aiming for on the LPC core? ...also, with the long random number thing: I'm thinking that if I take bits 1-10, 2-11, 3-12, etc., I could take a lot more than 3 pseudorandom sequences out of a 32 bit number... I think they'd all be more or less random enough, especially if I used them in different parts of the robotizer. I'll do some experimenting and see how that affects the stopwatch value. What should I pass as the seed to SEQ_RANDOM_Gen?

OK, committed the efficiency changes in robotize.c -- thanks again for the svn access, hope I didn't destroy anything with my first commit. It looks like the function adds about +20 uS now on an LPC core, if I'm reading the stopwatch correctly. Is that reasonable processor time for a function like this? Would it be more efficient if I pulled a long (say 64 bit) random number only once, and then used bit sequences within that long number as my random numbers later in the robotizer function? I'm thinking I could pull quite a few pseudorandom numbers out of 64 bits with some simple bitmasking, which would allow me to do a lot more complex robotizing with only one call to the random function. Would that be more efficient than the current implementation, or would pulling a 64 bit number once and manipulating it be more of a drain?

Definitely not ready for any PIC assembler headaches. Haha. Thanks for confirming.

Oh... That's a drag. Thanks for clarifying though. is it just the MB6582 that it doesn't work with? ...or is it also problematic with the newer core based MIDIbox projects?

Yeah, my 40 x 2's worked out of the box... But that other thread does say that there were issues with the UWQ5J version on the SID. More discussion here: Hawkeye got his working though, and the code is there.

Looks like there's code for it already though - this one is the just the international fonts version of the one Hawkeye talks about in this thread: ...what type of display do you have?

EDIT: Nevermind - according to Altitude these displays don't work with the MB6582 boards without some driver hacking... See his posts below. ################################################ Anyone interested in a group buy from Noritake-vfd.com? They have great sales on a pretty regular basis, and right now 20x4 VFDs are on sale for $18. Just so happens I have to buy a 20x4 for the SID PCB I just ordered.. CU20045-UW5A - 20x4 VFD - $18 http://noritake-vfd.com/cu20045-uw5a.aspx They're very nice displays - I have 40x2's on my SEQ and they are great. Very fast updates. I'm happy to run a buy, but if someone in the states wants to do it, it would be significantly cheaper. Noritake ships from the US, I think shipping is about $10 within the US for a small-ish order. Shipping to Canada would mean higher shipping costs + the possibility of import taxes on a large order. The picture below is a little blurry, these displays are very sharp - much sharper than it looks in the picture below. Really bright too.

Cool. Thanks. Is there a good reference anywhere that you know of on how to structure code to minimize consumption of RAM and CPU cycles? I've never programmed for anything where I really had to be concerned about that sort of thing before. Your comment about not calling the random function until absolutely necessary makes sense, as does not copying existing variables into local variables. I'll fix that stuff up. Should I be concerned about straightforward math? ...like, should I try not to multiply/divide/add/concatenate/etc. things unless absolutely necessary, or is the impact of straightforward evaluation like that relatively minimal? How about structures like if or switch statements? Any other stuff I should try to avoid?

I'm sure that'll get sorted out soon enough - support for MIDI devices would seem to be pretty near the top of the list of "must haves" for a MIDI app. Apparently it does support some sort of MIDI connection directly over USB, where the Android is in USB debugging mode and some software is running on the connected computer. But I haven't tried that out because, well, the software isn't available for linux..

TK - in order to implement NoFX, +Echo and +Duplicate, I need to pass variables into core.c (and probably live.c as well, but I haven't implemented anything there yet). Currently, SEQ_ROBOTIZE_Event() returns a binary coded set of flags - that works for NoFX, but the variable needs scope outside of SEQ_CORE_Tick in order to implement +Echo and +Duplicate (those functions would activate the Echo and Duplicate functions for the step even if FX Echo is set to off). How would you recommend passing variables from SEQ_ROBOTIZE_Event() into functions in seq_core.c and seq_live.c from SEQ_ROBOTIZE_Event() (eg: functions like SEQ_CORE_Echo())? I thought about putting the flags in the track CCs, but there's probably a better way. Also, any hints on how to implement a +sustain robotizer? I got it to cause a note to sustain, but it never turned off, and no more notes were played. Sustain, +Echo and +duplicate are fully implemented on the Robotizer side, that code is commented out of the UI though. SEQ_ROBOTIZE_Event() returns the flags, and the flags are parsed in SEQ_CORE_Tick() into u8 robotizer_sustain, u8 robotizer_nofx, u8 robotizer_echo, and u8 robotizer_duplicate. nofx is the only flag that core.c currently does anything with though, because of the scope thing. ###### Also, nerdy copyright lawyer note re: the copyright notice - Thanks for putting my name in the code, that's pretty cool actually... But why don't you just list me as a contributor in the header of the robotizer files, and list yourself as the copyright owner. I will (and hereby do) assign the copyright in my contributions to this code to you, that way you retain clean ownership of the whole MIDIbox source if this code makes it into the official release.

OK. I added a NoFX function, which disables effects applied after the Robotizer temporarily, for the current step. Right now it only disables LFO and Echo - I figured people might want to use the limiter after the Robotizer. I'm working on three more robotizers: Sustain (sustains the current note until the next note is played), Add Echo to the step (even if echo is disabled), and Add Duplicate. But they're a little more complicated than the others, and I don't want to fuck anything up, so they're not fully implemented in this version - the parts that are done are commented out of the UI. Here are the files. There are changes in all the files attached. I changed the name from Humanizer2 to Robotizer throughout, including filenames, so there are a few more changes to make outside of the attached files. Specifically: seq_live.c 29: change filename to robotize.h Change HUMANIZE2 function call to ROBOTIZE Replace the following references to HUMANIZE2 with ROBOTIZE seq_ui.h:328:extern s32 SEQ_UI_FX_HUMANIZE2_Init(u32 mode); seq_ui_fx.c:34: SEQ_UI_PAGE_FX_HUMANIZE2, // GP3 seq_ui_pages.h:68: SEQ_UI_PAGE_FX_HUMANIZE2 = 38, And replace this: seq_ui_pages.c:85: { "FX_HUMANIZER2","Hum2 ", "Track Fx: Hum.2 ", 57, (void *)&SEQ_UI_FX_HUMANIZE2_Init }, With this: { "FX_ROBOTIZE", "Robo ", "Track Fx: Robotize", 57, (void *)&SEQ_UI_FX_ROBOTIZE_Init }, And replace this: seq_ui_fx.c:133: SEQ_LCD_PrintString("Echo Hum. Hum2 Limit LFO Dupl."); With this: SEQ_LCD_PrintString("Echo Hum. Robo Limit LFO Dupl."); ALSO - the main FX Menu page seems to be broken in my local copy, either because of something in rev. 2117, or because of one of the lines above... Loop and Scale are offset on the LCD from the GP button that controls them... Loop is over GP 10, Scale is over GP 11, but GP9 and GP10 control them. How to use the thing: MENU+FX -> Robo - enters the robotizer page Robot on/off - enables and disables all robotizers for this track. Prob - the overall probability that any robotizers are applied. This overall probability setting is combined with individual probability settings for each robotizer, so you can make one robotizer happen more often than others (eg: change notes often, but never skip them, and only rarely change the velocity). Hold SELECT and use encoders to set individual robotizer probabilities (indicated by vertical bars beside each robotizer). Individual probability is multiplied by overall probability, then compared with a random number. If the random number is lower, then the robotizer will be applied. A different random number is called for each individual robotizer. Skip - skip steps (play them at zero velocity) Octave - changes octaves. the selected number is the range - if "2" is selected, the note will jump up or down 0, 1, or 2 octaves. Note - changes notes. Cumulative with octave changes. VelCC - velocity changes. This robotizer is weighted using some bad math in order to avoid out-of-range numbers, and produce more musical results. As a result of the way it's implemented, it's got a distinct character when the numbers are low (you'll get more loud accents if you keep the number low when you're starting with a velocity that's already relatively loud.), and a different character when the number is higher. Len - changes the gate length. NoFX - temporarily disables Echo and LFO. Prob, Skip, and NoFX do not have ranges, only probabilities. The vertical bar and the number for these robotizers controls the same variable. ROBOTIZER MASK: - hold SELECT on the robotize page and use GP buttons to edit robotizer mask (indicated by GP LEDs). Only selected steps will have robotizers applied to them. Mask is 16 steps long, so it repeats from measure to measure. seq_cc.c seq_cc.h seq_core.c seq_robotize.c seq_robotize.h seq_ui_fx_robotize.c LPC-project.hex

haha... Dammit - I just bought two more today.

Here's a couple of quick and dirty examples of this thing - 5 mp3s, all tracks are exactly the same, only difference is robotizer settings on the guitar track, which is a 4 bar loop. No effects other than the robotizer. https://soundcloud.com/zound-6/sets/robotizer-test

Sure, I'll do that this weekend. Thanks.

There are special tools, but you don't need them. I put the connector on my desk, lay the ribbon cable in it, put the top piece on, and then put something solid, heavy-ish and flat on top of it and push it down with your hand. Just make sure the pressure is even across the connector and straight down. You can crimp them in a vise too. Some people use pliers.

No - I use linux for everything, and there's no lemur daemon for linux... I may wind up running a virtual machine just to run the daemon though, I guess. I expected it to be able to recognize USB -> MIDI devices though, like the iPad version does.

Making the connectors properly takes a bit of practice, but it's not too hard... You might screw a couple up before you get it right, but once you figure out the technique, the IDC cables "just work". When you apply pressure to crimp the cables, make sure the pressure is perpendicular to the connector, don't apply uneven pressure, or pressure at an angle. If you have trouble with a connector you've made, test it with a multimeter to make sure all wires are connected, and no wires are shorted to their neighbour. Make sure the two connectors are orientated properly before crimping them on to the ribbon cable - there are "pin 1" indicators on the connectors, make sure the Pin 1 indicators on both connectors are both attaching to the wire you've designated as Wire 1. Take a minute to think about orientation before crimping, there are several different possible ways to attach the connectors to the cable, and only one of them is right. There are also little protrusions on the connectors that fit in the connector shroud on the PCB, so you can only plug them in one way if you're using shrouds on your PCB... The protrusions are marked on the PCBs... Just take a minute to think about orientation before crimping the cables, and you'll figure it out - it's easy once you get it, but it's hard to explain in words. https://www.google.ca/search?&q=idc+connector And make sure the cable is orientated properly when you plug them in (although for most of the connections on the MIDIbox SEQ other than maybe the LCDs, it's unlikely anything bad will happen if you get the orientation wrong, or if you've crimped your connectors on backwards, other than that the connected mudule won't work properly.)

I've got it installed on my phone and tablet... I can't get it to connect to USB midi devices though... I've tried the SEQ directly (via a powered hub) - the phone seems to recognize it as a midi device (it offers to launch another MIDI app), but there's nothing listed in Lemur's MIDI connect dialog. Same with a USB-MIDI adapter. How are you connecting to MIDI?

Good news: I left it running all night, and it was still going when I woke up. So, it's at least that stable. But: I just configured the Pi to autostart X, and log in automatically, then run the BLM. It runs fine, but it's not remembering settings anymore, so I have to manually configure the launchpads and SEQ connection each time it runs... Not sure why that is, it was remembering settings before. Anyone know where it would be storing the settings from the last time it ran? Model B (not the B+) with the standard Debian install.