-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assigned controllers conflict with fixed controllers #7
Comments
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. This is how I checked it:
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. 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).
The text was updated successfully, but these errors were encountered: