ultra

i've been working on this for the past couple days, and struggling to understand it, but i think i can help a little. the pattern of pin numbering will depend on how you wired it up. to find a pattern, just print pin number in a debug message to the mios studio terminal. you can easily figure out what the pin states mean by printing the value too. led is a lot more tricky, but the answer is where the notes turn the leds on and off. connect your midi keyboard and start hitting notes, eventually you'll see your leds start to light up. use different velocities to change the colors. look at this section of the code: if( midi_package.event == NoteOff || velocity == 0x00 ) { // Note Off or velocity == 0x00: clear both LEDs blm_scalar_led[led_mod_ix][led_row_ix][0] &= ~led_mask; #if BLM_SCALAR_NUM_COLOURS >= 2 blm_scalar_led[led_mod_ix][led_row_ix][1] &= ~led_mask; #endif } else if( velocity < 0x40 ) { // Velocity < 0x40: set green LED, clear red LED blm_scalar_led[led_mod_ix][led_row_ix][0] |= led_mask; #if BLM_SCALAR_NUM_COLOURS >= 2 blm_scalar_led[led_mod_ix][led_row_ix][1] &= ~led_mask; DEBUG_MSG("green - mod_ix: %d row_ix: %d col_ix: %d mask: %d", led_mod_ix, led_row_ix, led_column_ix, led_mask); #endif } else if( velocity < 0x60 ) { // Velocity < 0x60: clear green LED, set red LED blm_scalar_led[led_mod_ix][led_row_ix][0] &= ~led_mask; #if BLM_SCALAR_NUM_COLOURS >= 2 blm_scalar_led[led_mod_ix][led_row_ix][1] |= led_mask; DEBUG_MSG("red - mod_ix: %d row_ix: %d col_ix: %d mask: %d", led_mod_ix, led_row_ix, led_column_ix, led_mask); #endif } else { // Velocity >= 0x60: set both LEDs blm_scalar_led[led_mod_ix][led_row_ix][0] |= led_mask; #if BLM_SCALAR_NUM_COLOURS >= 2 blm_scalar_led[led_mod_ix][led_row_ix][1] |= led_mask; DEBUG_MSG("both - mod_ix: %d row_ix: %d col_ix: %d mask: %d", led_mod_ix, led_row_ix, led_column_ix, led_mask); #endif those DEBUG_MSG lines are all mine (put #define DEBUG_MSG MIOS32_MIDI_SendDebugMessage in mios32_config.h if you don't have it there). i'm still in the process of decoding this for my own purposes (my blm doesn't match the normal layout), but you'll see the patterns that are being used for column, row, and mod. pay attention to the 0/1 at the end of blm_scalar_led, and the way the operators are used against led_mask. that is resetting the state of the led, and turning on the correct color based on velocity. i'm still in the process of figuring this out myself, so i'm sorry i can't completely explain things. but this should point you in the right direction. ultra

edit: removed.

i inserted a debug message (to the mios studio terminal) into blm_scalar.c to make sure BLM_SCALAR_NUM_MODULES was set to 2, and it is. but i've also verified all my electrical connections on the pcb and they're fine. so i really have no idea where to go from here. someone please help!

i've tracked down BLM_SCALAR_NUM_MODULES, and put this code in mios32_config.h: #define BLM_SCALAR_NUM_MODULES 2 should this have both of my blm circuits working? i've tested all the hardware connections and they seem to be fine. ultra

i must have killed my brain designing this thing, b/c i overlooked some fundamental things. it's working, and the only problem i'm having right now is that the buttons on the second scalar circuit aren't working. should they work automatically with the blm_scalar firmware?

i've had my blm pcb made, but i'm not sure it's working properly. my configuration is 2 scalar circuits and all the switches (haven't put in the leds yet) on a single board. i'm not sure which app to use to test it. i've compiled and tested blm and blm_x in the examples folder on the svn, as well as blm_scalars under controllers. should i at least get a response on the lcd or debug window when i hit a button? i'm just not sure where to begin with troubleshooting this. thanks, ultra

you can also install an irc client and type /server irc.mibbit.net, then /join #midibox.

finalized designs:

hey, yeah i think the api has getNotes and setNotes methods, so this should be possible. i'm almost done with the pcb design for two controllers. a tracks controller and a clip trigger controller. they start out as relatively simple devices, but fully integrated with live. a future controller i had in mind is some kind of "clip designer". for one, it gives you fast access to settings related to the clip you're working on. also, it'll be used to build sequences. my thought was to build the sequences internally in the midibox. you basically start out with a clean slate, and start adding things such as note and cc sequences to build your loop. there could be a series of "overlays" that you can apply to the sequence, such as knob sweeps or some nifty modulation patterns. also, an existing sequence could be retrieved from live and then operated on. when you're done, one button could set the track to record, start, and then stop when the loop is done. i have access to virtually anything i want, and can deliver the info to the midibox. clip/track/scene names are even transmitting, but i don't have a use for them in the two i'm designing right now. more and more ideas have been popping into my head about what i/we can do with midibox live. my first thought was to make controllers that basically replace the apc40 and launchpad, and those are in the works. but since you can execute code based on whatever is happening in live, and use any value (such as a device parameter's value) in your code, quite a bit is possible. as an example, you could queue parameter changes and not have them fire until the beginning of a loop, and have several fire simultaneously. you could also force one parameter's value to be a % of the other's. etc etc etc. not that these are necessarily useful, but useful ideas can come to mind. another example, and this one i'm actually implementing: i'm using rotary encoders on the tracks box, which sucks for crossfading. but (hopefully) as a solution, i'm able to make a virtual center detent by using a "limit" switch. say your crossfader is at 25%. you hold the limit switch, move the encoder, and it won't allow it past 50% (or whatever value you've preset these to). once you've let go, you can go past 50%. but if you're holding it again going from 75% to 50%, it'll again stop at 50. i'm open to any and all ideas that people may have for this, and i'm not against trying things that go a bit into the experimental category. i think that entirely new ways of using live can come out of this. for now, i'm short on time and i'm just doing what i can to produce the first two boxes, which will hopefully end up as easy and inexpensive (under $200 i hope) kits. the third box i'm planning (tentatively) is designed to expand the power of the other 2 boxes. ultra edit: i'm not building a rgb matrix for clips, it's bi-color. but still, a clip designer midibox could certainly communicate with the trigger box and put it into a mode for building sequences. i would do it via live, so you still only need your usb cable connected to the pc and no interconnections between the boxes. i figured out how to make scripts communicate.

well the hardware integration is what i'm taking care of. no m4l. if you want to see the first controller i've come up with, the details are here: there's one more revision to that design, which i'll post later on once i decide it's actually final. ultra

sorry i missed this post. i do think that you can set midi notes, but i haven't looked into it much.

i've made a few modifications to make this easier to look at. i've also added the following: - play/stop transport control - a nudge button. turning this on will control clip nudge rather than solo/mute edit: for more functionality, holding the alt button while pressing a track stop button can turn clip looping on and off.

so i'm pretty much settled on a clip trigger design, and i've decided to go minimal. it will make this project *much* cheaper to build than before. this design uses simple tact switches without a cap and bi-color leds. very simple and cheap. i will be able to put the entire project, including the shift registers, on a single pcb. also, i'll have enough space to use thru-hole components. it all looks pretty simple, but there's some extra capabilities behind it. i still plan on doing other live related midiboxes, but i threw in some features that should allow some extra control using only this midibox. most of the non-clip trigger related functions will be more for studio use than live performance. what you see is an 8x6 grid of buttons with bi-color leds to indicate the status of a clip. it will be able to indicate if a clip is playing, stopped, existing, or queued. the 9th column at the right is for scenes, with the same kind of indication. the 7th row (first row of red) are stop buttons for the track, and a led to show the track has nothing playing. each track comes with a pair of buttons at the bottom. one is for mute and the other is for solo, and each gets an indicator led as well. at the bottom right is a preview button. in case you get lost in the clip matrix, you can hold it and tap a clip to set live's red box around only that clip. the top knob (track) moves live's red grid horizontally, while the scene one moves the grid vertically. the bottom-right knob and alt button are where the extra capabilities come into play. before i continue, i realize that the ergonomics of the added features aren't the greatest, but like i said, it's more for in the studio when you're using this thing as a scratch pad. the extra features are pretty easy to add (at least, physically) so why not? by default, the bpm/vol/pan knob controls bpm in live. if you press the alt button, you enter a mode to control volume or pan for a track by selecting a track's mute or solo button (depending on if you want vol or pan) after pressing alt. for instance, if you want to control the volume of track 3, you hold alt and press the mute button for track 3, and volume control mode is enabled. then the column of clip status led indicators can turn into a crude volume level indicator like how the novation launchpad works. pressing the mute or alt button again would return it to the clip triggering state. i've decided to keep these projects as simple as possible. the silicon buttons pretty much guarantee you'll be using surface mount components if you want the shift registers on-board, and using other buttons is just too expensive. also, i can easily keep this theme going with the other boxes i want to build. ultra

i think i may have to go that route. not so much because of button rows, but because i'm looking at it a bit differently. i haven't thrown out the modular idea, but serious money could be saved on core32's, lcds, cases, etc if i make an all-in-one box. a 4u or 5u design would allow for motorfaders and a lot of the other controls i'd like to have.

i'm looking into a different way of doing the buttons after a conversation with smashtv: in the end, the price should be about the same (after led, silicone grid, spacers, etc) - maybe $2/each. they also can be red, green, or orange. also, they're 10mm and can give me more space to work with on the panel, which is also making me rethink some things as well. i like the modular idea, but it might save some money in the end by going all-in-one with this. 2 pac-tec boxes are $80, where it's $60 for the seq case tk is working on. also, a pair of dogxl lcds can be used for the entire controller, where clip information and other information can be swapped on the screen. the metal case seems far more professional, and there's plenty of room for a 9x6 clip grid (not using the colored buttons for clip stop anymore) as well as motorfaders, lcd, etc. one more advantage is that the entire thing can be perfboarded, instead of having to buy a pcb. i'll still make a pcb because i'm not crazy enough to perfboard a blm. i'll post some drawings later. ultra

i've done some more looking into using rgb leds, and i think i'm not gonna do it. there's too many negatives involved: - power requirements - driver changes - no schem for rgb leds, i'd have to modify the blm and hope i understand what i'm doing - routing the pcb would be a nightmare the buttonpad is going to be its own pcb, which means if someone nails down the correct way to do it in the future, it can be changed. ultra

i'm familiar with those devices. if there's a certain behavior you think it should have, you should let me know. i'm starting the pcb layout but i expect that to take me a while. still looking for schematics. but extra column is for scene triggering, and their website says the buttonpad can be cut apart to make new dimensions.