Open dhemery opened 7 years ago
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:
DumpSYX
command in Setup
menusysexSend
on midi output:
sysexSend("f0002029 43 0000 4269747769672020 00030201400b00243b4000003c6040010024544010042454401004 09357f00100801 09367f00100801 09377f00100801 09387f00100801 09397f00100801 093a7f00100801 093b7f00100801 093c7f00100801 08437f0010080108457f0010080108477f0010080108487f00100801083c7f00100801083e7f0010080108407f0010080108417f0010080109297f00100801092a7f00100801092b7f00100801092c7f00100801092d7f00100801092e7f00100801092f7f0010080109307f0010080109317f0010080111337f0010080111347f0010080111357f0010080111367f0010080111377f0010080111387f0010080111397f00100801113a7f00100801113b7f0010080109017f00100801f7");
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.
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.
The extension's initialization procedure sends a SysEx that establishes a template. The template creates several conflicts between assignable controls and non-assignable controls:
The extension interprets the Encoder 7 and 8 messages (in MIDI mode) as transport messages. As a result, the extension:
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:
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).