OpenDeck platform

[paradajz]

Cool project. Did you use the I2C pins for part of the multiplex? I think on
Pro mini they pop out the middle of the board? It would be great if those
were free, so things like MCP23017 could be added for LED display modules,
or other switches or... who knows what. I understand, if you had to use them, but
it would be a bonus if they are free.

Updated 2015-08-29: v1 board info - now obsolete

Thanks. No, free pins are 12, 13, 2 and 3. Please note that this is just first revision of the board, it will get better eventually.

[paradajz]

Here's the first demonstration of controller configuration using OpenDeck platform.

[nem0nic]

This is all great stuff, and I admire how much work you've put into it so far. It seems like a very robust solution!

If you're looking for features to add, I have a couple suggestions...

For pots, it would be nice to define an upper and lower limit that isn't 0 and 127 (for instance 45 and 115). This function would not create "dead zones" on the pot - instead it would interpolate the defined range across the pot's entire length of travel. This would be modified by the invert command as well. The use case would be to limit the range to only "useful" values when manipulating an effect.

For encoders, it would be useful to have settings for sensitivity, acceleration, and message type. Sensitivity would act as a multiplier or divider for the number of "ticks" in the natural resolution of the encoder (25 pulses per revolution for example). This could be used to not only help address "slow" pots, but also to slow down higher resolution pots (8 bit or higher). Acceleration would act similarly to sensitivity, except it would ramp resolution up based on how quickly the pot is being twisted. This would allow the encoder to have fine control over a parameter but allow for more radical value changes. Message type would allow the user to select what KIND of relative message is being sent from the encoder (binary offset, 2s comp, etc). Sometimes one is more suited to the task than another, and allowing the host software to set those values would be useful.

For buttons or knobs, it would be great to allow the control output message to also set a state in the controller. So a button might send 90 21 7F, but it might also send F0 00 53 43 01 00 42 00 13 01 F7 (to change the mode of button 19). Ideally it would be possible to send multiple commands of this type - allowing the user to reconfigure the controller on the fly. To take that idea even further, it would be AMAZING to allow incoming MIDI messages to trigger a similar stack of SYSEX strings. At that point, the host application could drive controller configuration based on any number of conditions (what view is selected, what effect is loaded, etc).

In any case, thanks for bringing a smile to my face this morning! Great work!

[paradajz]

This is all great stuff, and I admire how much work you've put into it so far. It seems like a very robust solution!

Thank you!

If you're looking for features to add, I have a couple suggestions...

Sure I am, it's one of the reasons I've opened this thread.

For pots, it would be nice to define an upper and lower limit that isn't 0 and 127 (for instance 45 and 115). This function would not create "dead zones" on the pot - instead it would interpolate the defined range across the pot's entire length of travel. This would be modified by the invert command as well. The use case would be to limit the range to only "useful" values when manipulating an effect.

This seems like a straightforward thing to, consider it done for next release.

For encoders...

Version 1.0 of software doesn't have any support for encoders yet, even though hardware is capable of controlling them. Initial encoder support will come soon, and when I get it done, I'm going to read your message again, to include the stuff you've mentioned. I've never dealt with proper encoders before, so support for them is probably going to take a while.

For buttons or knobs, it would be great to allow the control output message to also set a state in the controller. So a button might send 90 21 7F, but it might also send F0 00 53 43 01 00 42 00 13 01 F7 (to change the mode of button 19).

How do you suggest I do this? I mean, you certanly don't want to change button mode each time you press it. Maybe I could add a feature to GUI (once I start working on it) to define some combination of "magic keys", ie. press couple of keys together, certain LEDs light up to indicate that you're in edit mode, and then you can change stuff you want. Certanly possible.

Ideally it would be possible to send multiple commands of this type - allowing the user to reconfigure the controller on the fly. To take that idea even further, it would be AMAZING to allow incoming MIDI messages to trigger a similar stack of SYSEX strings. At that point, the host application could drive controller configuration based on any number of conditions (what view is selected, what effect is loaded, etc).

Also very much possible. Do note that I'm the only developer involved in all this, so you won't see all these features right away in next release, but eventually you will.

In any case, thanks for bringing a smile to my face this morning! Great work!

I'm really glad you like it!

[nem0nic]

How do you suggest I do this? I mean, you certanly don't want to change button mode each time you press it.

So the basic use case is to allow the user to define "pages" for the controller that would allow the controls for each page to act differently. So I would define the buttons on the controller I want to switch pages, then I would program those buttons to modify the behavior of a set of controls.

So here's a more defined use case. Let's say I have 4 encoders arranged above my up fader in a mixer-style controller. I'm using encoders in this case because I want 2 channel strips to control 4 decks. But I also want to use one of those knobs to act as a "fine scrub" so I can line the waveform up against the play marker. To control EQs I'm going to want the knobs to output an absolute message, but when the deck isn't playing I want one of those knobs to switch to relative so I can jog. So in this case, the play button (or the "deck is playing" message from the application) would change the behavior of that encoder.

There are actually a ton of ways I can see this being used. Typically if someone wanted to do something like this they would build a preset in MIDI Translator, or Max or something else. But I think it would be pretty handy to support in the firmware.

[paradajz]

I see where you're getting at. That's going to be tricky bussiness and will require some careful code design in order to make it as simple as possible. But I definitely like your idea, and it's now on my to-do list.

[paradajz]

For pots, it would be nice to define an upper and lower limit that isn't 0 and 127 (for instance 45 and 115)

Done! Still working on some unrelated code optimizations before releasing it.

[paradajz]

Okay, another post about SysEx programming:
http://shanteacontrols.wordpress.com...otocol-stable/

[paradajz]

Finally added support for encoders!

https://www.facebook.com/video.php?v...type=2&theater

[paradajz]

Even though it's not commited yet, buttons can now be configured to send Program Change instead of note/CC messages.

Since I'm working on several projects right now, GUI won't be finished any time soon - summer time is likely. I've also written new blog post about OpenDeck code:

http://shanteacontrols.wordpress.com...3/assumptions/