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

[EvilDragon]

I do beta testing for u-he, and in this case am paraphrasing what Urs mentioned at some point in one of his posts. With good enough keywords you should be able to search for it.

[mi-os]

Ok, thanks.

I'm fairly disappointed that it's not already possible to MIDI control all parameters. I currently have DIVA and Repro, but it looks like DIVA is the only plugin of the bunch that is worth looking into for building a dedicated MIDI controller. I wish i could say the same about Repro and Hive.

I'll wait for Urs' final statement about this nonetheless.

[EvilDragon]

One thing that I agree with you is that global FX bypass SHOULD be MIDI learnable. But mod matrix and patch prev/next, nope. Patch browsing should be sorted out with established methods (MIDI Programs folder, then Bank Select + Program Change messages) and how it's intended to work within u-he's framework.

[mi-os]

As someone not interested in building a MIDI controller your wish may be sufficient.

I for one need everything, but could live without things like sequencers. The synth and fx engins should be fully controllable.

[Urs]

Sorry, i think my plea remains valid.

If something can be controlled over the GUI, it must work with other interfaces too. I mean the GUI wouldn't work either if it were true. We had that discussion before, but i was never convinced why it shouldn't work.

It's not a simple parameter which controls two states (on/off). The parameter in question is rather complex - it's comprising of a few kilobytes of data. It's then same kind of parameter which Zebra's Grids are based of. It controls on/off state, order, name (!), routing and side chain, number of rows/columns in the matrix, mute/shade/hidden states and probably a few more things. It's the full representation of the underlying modular mesh of audio objects, which we reused in Repro, Bazille and Hive for their FX section because we could leverage the use UI interface object from Zebra.

The problem with MIDI learn is, we would need to add a parallel set of parameters just for that, and those parameters would only control a tiny aspect of the actual data. These parameters would exist in parallel and act as "meta parameters". Existing presets - also those saved with project - would need to somehow be upgraded to the new parameter scheme, as would the UI controls. We would have to write fallbacks so that 3rd party UI skins would adapt automatically.

Our experience with such issues is, if we add parameters to somehow meta-control other (more complex) parameters, we end up with conflicts. We once ended up spending months to fix another product for all sorts of situations where things like that went tits up. It's a design flaw, if you want, but the general concept has served us very well in every other aspect. I can see how it would be nice to have a fully mouse-free controller, but there simply are concepts which benefit form the mouse - such a changing the order of modules. While there's the sacrifice that not everything can be controlled by knobs and buttons, I still believe that the benefits outweigh the drawbacks.

[mi-os]

The problem with MIDI learn is, we would need to add a parallel set of parameters just for that, and those parameters would only control a tiny aspect of the actual data.

Hmm, it sounds like you don't have MIDI learn at all. How do you handle parameters which are already controllable? What separates them to those not controllable?

[mi-os]

I've some coding experience myself (surely not nearly as good as you) and see these things the way i'd have structured an app like this. I assume you have some kind of mvc style decoupling and an event system. To me it doesn't make much of a difference whether a GUI element or MIDI event triggers the change of a var in a data object and which in return reports that something has been changed.

But yeah, it's absolutely possible that i'm simply too dumb to get why it is much more complicated then this.

[Urs]

The problem with MIDI learn is, we would need to add a parallel set of parameters just for that, and those parameters would only control a tiny aspect of the actual data.

Hmm, it sounds like you don't have MIDI learn at all. How do you handle parameters which are already controllable? What separates them to those not controllable?

Normal parameters can be expressed by a number. Such as parameter which ranges between 0 and 100. Those are controlled by knobs, sliders, buttons or drop down boxes.

Let me give you an example of a parameter that's different. Take the labels of Hive's XYs for instance. Those are made out of text, and thus they can not be expressed by a number between, say, 0 and 127. If you could MIDI-Learn a knob to that, what would you expect the knob to do? How would you use the single knob to edit the text?

Likewise, if you look at the UI widget that controls the state of the effects, it lets you drag the effects into a different order. So it's not just on/or off, it's also this-after-that-before-those which can *not* be expressed by a number such as 0 - 100. Also, obviously, the same UI element controls the state of many effects, not just a single one. That's why the parameter is not something that's expressed by a simple number. In other words, there is no way a MIDI knob can be used to reorder the effects, switch them on and off and make this whole thing a usable experience - just like a knob can't edit a text.

That's what set the *one* parameter which controls the state and order of all effects apart from a parameter like filter cutoff or envelope attack.