Repro-1/Hive: Effects on/off and Mod Matrix midi learn missing
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
The point is that the menu is probably dynamically generated depending on available modulators, so the order of entries in the menu can change quite wildly between versions. Hence, volatile.
- u-he
- 28042 posts since 8 Aug, 2002 from Berlin
Well, by "volatile" I actually meant that each entry of the target parameter is created from all available parameter IDs. These parameters internally have flags and stuff. We sometimes change those flags and we add/remove things, so the list changes from build to build. It could even change based on a preference, or as ED pointed out, based on other parameters. (Latter is more of a cosmetic issue, because if one deactivates the module with an assigned target parameter, the connection persists even though the parameter isn't in the list anymore).
NRPN style control might be possible, but the most likely option might be Sysex, where the target parameter name and mod slot are encoded in a literal string, like we do in the preset. Such that assigning filter cutoff to, say ModMatrix slot 2 would look like this:
F0 00 00 00 // Sysex header
75 2D 68 65 // u-he
75 5F 52 31 // u_R1 (Repro-1 Unique identifier)
4D 64 41 73 //MdAs (Mod Assignment)
4D 4D 32 3A 54 61 72 67 65 74 3D 56 43 46 31 3A 43 75 74 6F 66 66 //MM2:Target=VCF1:Cutoff
F7
That would be an option I'd be happy to discuss. However, as we don't do MIDI out, there wouldn't be a feedback path.
NRPN style control might be possible, but the most likely option might be Sysex, where the target parameter name and mod slot are encoded in a literal string, like we do in the preset. Such that assigning filter cutoff to, say ModMatrix slot 2 would look like this:
F0 00 00 00 // Sysex header
75 2D 68 65 // u-he
75 5F 52 31 // u_R1 (Repro-1 Unique identifier)
4D 64 41 73 //MdAs (Mod Assignment)
4D 4D 32 3A 54 61 72 67 65 74 3D 56 43 46 31 3A 43 75 74 6F 66 66 //MM2:Target=VCF1:Cutoff
F7
That would be an option I'd be happy to discuss. However, as we don't do MIDI out, there wouldn't be a feedback path.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
IF the mod target lists are dynamically changed on runtime, you'd need to synchronize the lists between the controller and the plugin via an onChange event. Yeah, that's a problem and is probably not possible via standard midi.EvilDragon wrote:The point is that the menu is probably dynamically generated depending on available modulators, so the order of entries in the menu can change quite wildly between versions. Hence, volatile.
BUT for example in Repro these dropdown lists look static to me. You can even select the same target on both slots and so on. They're always stay the same, so no problem.
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
At some point you should probably implement MIDI out. Or, perhaps even better, OSC? Exactly for relative adjustments from external controllers, I feel OSC might fit the bill - and is plugin type agnostic, AFAIK, since it's using network protocols!Urs wrote:However, as we don't do MIDI out, there wouldn't be a feedback path.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Thank you for the more detailed explanation. I think it could work nonetheless, maybe with some small concessions (ie in case of deactivated modules you mentioned). The key would be to have an additional CC/Value index reserved per parameter.Urs wrote:Well, by "volatile" I actually meant that each entry of the target parameter is created from all available parameter IDs. These parameters internally have flags and stuff. We sometimes change those flags and we add/remove things, so the list changes from build to build. It could even change based on a preference, or as ED pointed out, based on other parameters. (Latter is more of a cosmetic issue, because if one deactivates the module with an assigned target parameter, the connection persists even though the parameter isn't in the list anymore).
I often see CC values evenly spread over the 0...127 range. If you've for example 13 mod targets you get stepping from 0...9 (first param) and 10...19 (next param) and so on. That would not work of course, since each value has to be an unique identifier.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Something like that would be so nice. I could live with the 'no feedback' limitation, though i'd rather like to have it. What's the reason to not support midi out? I thought u-he plugins send midi back to the controller for example on preset change. Or do you mean continuous synchonization of all params?Urs wrote:NRPN style control might be possible, but the most likely option might be Sysex, where the target parameter name and mod slot are encoded in a literal string, like we do in the preset. Such that assigning filter cutoff to, say ModMatrix slot 2 would look like this:
F0 00 00 00 // Sysex header
75 2D 68 65 // u-he
75 5F 52 31 // u_R1 (Repro-1 Unique identifier)
4D 64 41 73 //MdAs (Mod Assignment)
4D 4D 32 3A 54 61 72 67 65 74 3D 56 43 46 31 3A 43 75 74 6F 66 66 //MM2:Target=VCF1:Cutoff
F7
That would be an option I'd be happy to discuss. However, as we don't do MIDI out, there wouldn't be a feedback path.
I read somewhere that Sysex is slow because of the much bigger data stream, but that could be overcome with things like OSC or RTP-Midi iirc. But maybe people mean it's a problem only for old hardware synths with little processor power.
- KVRAF
- 4129 posts since 11 Aug, 2006 from Texas
Sysex doesn't have to be slow. It's just a vendor-specific series of bytes between F0 ... F7. Something as short as F0 00 F7 is valid sysex. How much data vendors put between there, and if they offload sysex to a slower midi processing pass could cause it to appear slower. With MIDI over USB and modern CPUs it shouldn't be an issue in this case.
Feel free to call me Brian.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
I wonder about the pro's and con's of Sysex vs OSC in this case.
Sysex
- subset of MIDI protcol, extends it
- no 128 CC's limitation
- varibale message length
- typical use cases: patch transfer, patch editing
- typical transport: DIN, USB
OSC
- new protocol
- standardizes value types, formats and the addressing of entities -> simpler
- 'message bundles' possible
- typical use cases: same as Sysex?
- typical transport: LAN
Both
- OSC and MIDI are message protocols that are hardware transport independent
I assume Sysex is preferred by Urs because it's already supported by many hard-/software devices.
Sysex
- subset of MIDI protcol, extends it
- no 128 CC's limitation
- varibale message length
- typical use cases: patch transfer, patch editing
- typical transport: DIN, USB
OSC
- new protocol
- standardizes value types, formats and the addressing of entities -> simpler
- 'message bundles' possible
- typical use cases: same as Sysex?
- typical transport: LAN
Both
- OSC and MIDI are message protocols that are hardware transport independent
I assume Sysex is preferred by Urs because it's already supported by many hard-/software devices.
- KVRAF
- 4129 posts since 11 Aug, 2006 from Texas
I think the biggest pro for Sysex is he already has a MIDI implementation in his plugins. The OSC standard is not well supported by DAWs and is quite different packet-wise from MIDI. Dumping strings and values in his code to sysex might be as simple as:
Code: Select all
SendSysexStartParam();
SendSysexBytes(ParamName + ParamDelimiter + ParamValue);
SendSysexEndParam();
Feel free to call me Brian.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Makes sense. If i understand it correctly, we then could transmit/receive parameter names as string literals like in the preset handler.bmrzycki wrote:I think the biggest pro for Sysex is he already has a MIDI implementation in his plugins. The OSC standard is not well supported by DAWs and is quite different packet-wise from MIDI. Dumping strings and values in his code to sysex might be as simple as:Code: Select all
SendSysexStartParam(); SendSysexBytes(ParamName + ParamDelimiter + ParamValue); SendSysexEndParam();
I'm further intrested what would be possible with plugin midi out. I see these scenarios:
1. send an entire preset (eg after preset change)
2. send infos about available parameters and their types/ranges
3. send parameter updates
Another question is how bidirectional communication could work. How would you request things from the plugin or get notified about updates?
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Does anyone know whether u-he plugins send out parameter updates after preset changes? If yes, is this only working via host automation and therefore limited to automatable params?
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
There's no MIDI out in u-he plugins, so they don't send parameter updates after preset changes unless they're all automated using host automation.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Ok, thanks. Should i use host automation instead of midi cc with external midi controllers then? I remember getting bidirectional parameter binding with Cubase Quick Controls, which i suspect is using host automation. Unfortunately i can't find much background info on this.
- KVRAF
- 23077 posts since 7 Jan, 2009 from Croatia
Yes, you also get better precision with host automation instead of CCs.
-
- KVRist
- Topic Starter
- 438 posts since 13 Apr, 2017
Sorry, for asking so much. But i find it very hard to get a precise idea, which way to go.
Which protocol is used to connect the controller when using host automation, is this midi cc (7 bit) again? The only advantage over midi cc would be bidirectional data stream, right?
VST <- parameter automation -> HOST <- midi cc -> CONTROLLER
Is there a way to get lists of all parameters u-he plugins expose to the host?
Which protocol is used to connect the controller when using host automation, is this midi cc (7 bit) again? The only advantage over midi cc would be bidirectional data stream, right?
VST <- parameter automation -> HOST <- midi cc -> CONTROLLER
Is there a way to get lists of all parameters u-he plugins expose to the host?