Wishlist: Modal or shift capability (Future feature - layers)

[phedders]

I hope i didnt miss it already, but the one thing that would really make this project completely indispensable to me (ok so it already is...) would be the capability for inputs to trigger a modal capability - or act as a temporary or permanent "shift". For example

• further (select) inputs are redirected to a different device
• further (select) inputs are given different channel or notes

The shift could be momentary (while input "on" or key pressed) or variable (expression pedal divided into ranges) or multilevel (press for shift 1, press again for shift 2 etc.)

Multiple different shifts should be possible with different config of levels, permanence, and all mappings should be either as normal or dependant on a particular named shift and level.

Just some random thoughts what it might look like in the config:

[shift myshiftone] levels 1 mode momentary

[shift myshifttwo] levels 3 ; implies mode static

midikeys.ch2.cc1 -> myshiftone midikeys.ch2.cc2 -> myshifttwo.next midikeys.ch2.cc3 -> myshifttwo.next midikeys.ch2.cc4 -> myshifttwo.1 midikeys.ch2.cc5 -> myshifttwo.2 midikeys.ch2.cc6 -> myshifttwo.3

midikeys.ch0.note66 <> daw./key1 ^myshiftone=0^ midikeys.ch0.note66 <> daw./key4 ^myshiftone=1^ midikeys.ch0.note66 <> daw./key6 ^myshifttwo=2^

[phedders]

I'm looking at it again and wondering if it could be implemented as a plugin....

keys.ch0.note{0.255} <> shift.in.keys.note{0.255}

shift.out0.note{0..255} <> daw.ch0.note{0.255} shift.out1.note{0..255} <> daw.ch1.note{0.255} shift.out2.note{0..255} <> daw.ch2.note{0.255}

The triggers would be defined in the plugin definition...

[cbdevnet]

Hi and thanks for your interest and the suggestion! I think you could probably do something that works like that using the Lua plugin.

This would just be implementing a handler function for incoming channels and having it redirect the event to other channels on the output side based on, for example, an internal variable set by another channel :)

[cbdevnet]

I just pushed a rather simplistic example of doing mapping layers using a Lua script. Doing it this way might suffice for smaller projects.

I'm thinking about making layers of channel mappings a named entity (for example, a configuration section like [map layer1], which the user could then switch on or off with normal input channels. This will take some time to implement though as the current focus is on getting a working 1.0 release out there :)

[phedders]

Argh I'll push Lua back up the priority of "languages I want to learn" :) Although I guess its a pretty small subset required for this.

Thanks for that example - it would definately work for what I want (x32/bcf2000 to control simple lighting via QLC+) Seems I was right that plugins could do it!

However your layers idea looks like the real business - would certainly allow to keep all the logic in the config file rather than adding more code (lua) files.

Thanks again! Happy Christmas!

[phedders]

BTW - I'm happy to close this unless you want to leave it as a placemaker/target for the "layers" code?

[Spacelord09]

I think you can leave it open for now.

[cbdevnet]

@GralfR brought up the idea of having the named mapping section enable inputs also function as a constant multiplier on the forwarded events. This could be done for absolute type channel mappings, once we support different channel types (#41), there needs to be a strategy on how that could be applied there.