Assigned controllers conflict with fixed controllers

[dhemery]

The extension's initialization procedure sends a SysEx that establishes a template. The template creates several conflicts between assignable controls and non-assignable controls:

• In MIDI mode, Encoder 7 sends the same CC (0x1B) on the same channel (0) as the Rewind button.
• In MIDI mode, Encoder 8 sends the same CC (0x1C) on the same channel (0) as the Fast Forward button.
• In MIDI mode, Fader 1 sends the same CC (0x29) on the same channel (0) as Impulse's various "program change" controls (the + button, the - button, and the Data knob).

The extension interprets the Encoder 7 and 8 messages (in MIDI mode) as transport messages. As a result, the extension:

• Rewinds each time Encoder 7 sends the value 1.
• Fast Forwards each time Encoder 8 sends the value 1.

The extension currently doesn't handle MIDI Fader 1 or program change messages (CC 0x29), so it doesn't (yet!) behave weirdly for those.

I'm pondering several solutions for my own controller:

1. Assume that the CC message was sent by the non-assignable control.
   • This has the effect of making the faders and encoders act strangely in MIDI mode. The exact weirdness will depend on how the extension interprets values other than 0 and 1.
2. Assume that the CC message was sent by the assignable control.
   • The Rewind and Fast Forward buttons send only the values 1 (press) and 0 (release). The program change controls send only the value 0. If the plugin/device that ultimately responds to these MIDI messages expects values in the normal range (0–127), these limited, button-initiated values will be problematic.
3. Create extension Preferences to allow the user to choose the appropriate command for each conflicting CC message.
4. Initialize the Impulse with a pre-defined template that has no conflicting assignments.
   • I'm concerned that this may overwrite the template in the user's currently selected template slot.I haven't verified that this would happen.
5. Discover the encoders', faders', and buttons' MIDI-mode assignments by examining the current template.
   • Given that a user template may include assignments that conflict with each other and with non-assignable controls, I'll have to deal with the conflicts using solution 1, 2, or 3.

Another complication: What to do if the user switches templates while the extension is active. (This makes me lean toward solution 5, which alas is the most complex one).

[tlipinski]

Thanks for sharing your findings!:) Personally I like 4. option most because it actually solves the issue without leaving any possibility for conflicts or surprising behaviors depending on 0/1/2-127 values.
I've just played around with templates a bit just now and I learned that overriding templates won't be an issue.

This is how I checked it:

1. I dumped template from Impulse using DumpSYX command in Setup menu
2. Controller script will receive then sysex message with full template so make sure you have sysex callback set.
3. According to documentation https://github.com/martinwittmann/impulse-bitwig/blob/master/TEMPLATES.md I changed CC values of encoders and template name
4. From controller script I sent modified template simply by calling sysexSend on midi output:

sysexSend("f0002029 43 0000 4269747769672020 00030201400b00243b4000003c6040010024544010042454401004 09357f00100801 09367f00100801 09377f00100801 09387f00100801 09397f00100801 093a7f00100801 093b7f00100801 093c7f00100801 08437f0010080108457f0010080108477f0010080108487f00100801083c7f00100801083e7f0010080108407f0010080108417f0010080109297f00100801092a7f00100801092b7f00100801092c7f00100801092d7f00100801092e7f00100801092f7f0010080109307f0010080109317f0010080111337f0010080111347f0010080111357f0010080111367f0010080111377f0010080111387f0010080111397f00100801113a7f00100801113b7f0010080109017f00100801f7");

5. When Impulse receives tempate then it is in unsaved state. You need to confirm changes with Save action on Impulse, otherwise Impulse will ask if you want to discard them when you try to switch to another template.

The only issue left will be that sending template on each controller script initialization will require confirming/discarding changes even if the current template is exactly the same as the one just sent from Bitwig. I think that sending template on demand would be a good way to solve it. Maybe with some trigger in script's Preferences or "unusual" button combination on Impulse itself with shift button pressed or whatever.

[dhemery]

Ah, so Impulse treats the template sent in via SysEx as unsaved edits. Yay!

I'm now almost entirely sold on the idea of the extension sending a fixed template. My one hesitation: Users may want control of which CC ID each control sends (as MIDI) to their plugins. But that's a tiny issue, especially if the extension's help file shows how the extension maps the controls to the CC IDs that get delivered via the NoteInput.

Here's possibility that may be more trouble than it's worth: Add Preferences to let the the user map each control to a CC. The device will still send whatever CC the template dictates, but the relevant command object can re-map those before forwarding them to the NoteInput.

As for when to re-send the template, consider: Every time the extension receives CC 0x29 on channel 0. That is: re-send every time the user selects a different template with the data knob or + or - buttons. That's mildly rude, but if users really want to use a different template, they can disable the extension (which probably won't work with their chosen template anyway).

An alternative: When the user changes the template, exit the extension. That's also mildly rude, in a different way.

For my experimental extension, I will likely make my command objects (fader, encoder, button) the authoritative source for each physical control's CC. Once I've constructed the command objects, and told them what CCs they respond to (e.g. MIDI_FADER_BASE_CC + faderIndex), I can construct the template to match those CCs. That way, if I want to move the CCs around, I can do it in one place (MIDI_FADER_BASE_CC) and the template will automagically assign the CCs to the physical controls accordingly.

Or something like that.