Repro-1/Hive: Effects on/off and Mod Matrix midi learn missing

Official support for: u-he.com
RELATED
PRODUCTS

Post

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.

Post

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.

Post

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.
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.

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.

Post

Urs wrote:However, as we don't do MIDI out, there wouldn't be a feedback path.
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!

Post

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).
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.

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.

Post

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.
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?

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.

Post

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.

Post

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.

Post

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.

Post

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();
Makes sense. If i understand it correctly, we then could transmit/receive parameter names as string literals like in the preset handler.

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?

Post

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?

Post

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.

Post

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.

Post

Yes, you also get better precision with host automation instead of CCs.

Post

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?

Post Reply

Return to “u-he”