Hive 2.X Feature Requests

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

accessdune3 wrote: Wed Mar 31, 2021 7:50 pm
Urs wrote: Wed Mar 31, 2021 7:43 pm
accessdune3 wrote: Wed Mar 31, 2021 7:07 pm... are outdated and not fun to use
Quickest way to persuade developer to follow your ideas.
I'm sorry if I offended but just try to use msegs on serum and dune 3, it's so smooth and easy to use. Or another example Shaperbox by cable guys :-)

P.s. i bought and i love Zebra 2/hz :-)
I just tried MSEG on Dune... It doesn't seem particularly easier than Zebra. Dune needs double click to add a point and Zebra doesn't. Still tends to be tedious to edit a bunch of points. Plus I like the Attack/Loop/Release stages of the Zebra MSEG's, which most other MSEG's don't have including Dune.

In any case, the fast, easy UI of Hive is well suited to the Shape Sequencers and imo, full editable MSEG's should left for Zebra.

Post

Yeah a double-click is better because it is done with one hand. In Zebra, you gotta Alt+click to add a point, so gotta use two hands, which is super meh. And let's not talk about the super-fickle and unintuitive linear-quadratic-S curve mixture for slope change... Those two things are the main pitfalls of Zebra's MSEG for me personally. It could be much smoother workflow-wise.


As an aside, when I (as part of Surge Synth Team) worked on figuring out the UX of the MSEG in Surge, we spent months investigating all the different MSEG implementations out there. None of them is perfect. But we took the best things out of all those various implementations and smashed them together. Everyone seems happy, and the workflow is really really nice and smooth too.


That said, I agree that not every synth needs to have an MSEG. Shape sequencers are cool too.

Post

EvilDragon wrote: Wed Mar 31, 2021 8:12 pm Yeah a double-click is better because it is done with one hand. In Zebra, you gotta Alt+click to add a point, so gotta use two hands, which is super meh.
Ahh... yeah, I much prefer the single click and find it faster and I don't care if it is 2 hands cause I would not be playing notes or doing anything else and adding MSEG points at the same time.

Also, in Dune3, trying to put a point at the bottom or top, the double click easily misses and either you get no point or it is slightly off from the very top or bottom and then needs manual moving. In Zebra, if you click a bit above or below the actual MSEG graph, you still get a point and it is 0 or 100 for sure.
EvilDragon wrote: Wed Mar 31, 2021 8:12 pm And let's not talk about the super-fickle and unintuitive linear-quadratic-S curve mixture for slope change
yup... that is what I don't like about Zebra MSEG's... imo, it should be alt-click drag to add a point and offer a set of curve/shape options for that point.

I forgive it cause of the Attack/Loop/Release stages which I find so useful.

Post

Yeah I just think using two hands is needless workflow slowdown and should be avoided as much as possible. But also, one size does NOT fit all, and when designing something it's good to take care of multiple usecases instead of just one.

For example, in Surge, you could use Ctrl or Alt to do snapping, but there are also obvious buttons to enable horizontal and vertical snapping right below the MSEG. No need to use a context menu for that. And a nice selection of curves IS what a context menu is good for (as well as various MSEG processsing actions etc.)

Post

You all certainly know that the main reason for a major update to Zebra is and has been the unification of the complex editors. Hehehe, I hope you do, I've repeated that over and over, simply also because it's the one area that needs most work :clown:

I'm aware of the inconsistencies in Zebra's editors, but I personally find the waveform editor more of a pita than the MSEG editor.

Serum has this funny trick in its LFO-editor of secretly adding a horizontal line to an existing segment to "squeeze" the bend into a corner, which I do like on the one hand but find difficult on the other. I'm torn on how to go about it in our own new editor which otherwise exceeds any of the known editors in speed and flexibility - without promoting certain outcomes ("same same"). I don't have Serum nor Cableguys installed on my current machines, I'm happy to give them another go.

In any case, and back to Hive, I still would like to see a curve that isn't oozing arbitrariness ("Let's randomly paint this thing here") that can't be matched in the Shape Sequencer or wasn't better applied by host automation. This isn't to be schmuck about it, I'd really like to see examples to know what we're actually talking about.

(where I'm coming from: I often start laughing when I see marketing material / screenshots of MSEG type of things in synths where the envelopes displayed look like a first attempt with an Etch a Sketch, i.e. completely free of any musical meaning)

Post

Urs wrote: Thu Apr 01, 2021 7:55 am You all certainly know that the main reason for a major update to Zebra is and has been the unification of the complex editors. Hehehe, I hope you do, I've repeated that over and over, simply also because it's the one area that needs most work :clown:

I'm aware of the inconsistencies in Zebra's editors, but I personally find the waveform editor more of a pita than the MSEG editor.
I could not possibly forget that! Very much looking forward the unified, streamlined and fun to use complex editors! :tu:

Post

Urs wrote: Thu Apr 01, 2021 7:55 amIn any case, and back to Hive, I still would like to see a curve that isn't oozing arbitrariness ("Let's randomly paint this thing here") that can't be matched in the Shape Sequencer or wasn't better applied by host automation. This isn't to be schmuck about it, I'd really like to see examples to know what we're actually talking about.

(where I'm coming from: I often start laughing when I see marketing material / screenshots of MSEG type of things in synths where the envelopes displayed look like a first attempt with an Etch a Sketch, i.e. completely free of any musical meaning)
I'm curious about that too...

In the future, I'd like to see a new editing approach so that I could select say Shape Sequencer A and instead of one step being editable at a time, all the selected steps for A (continuous or not) would be visible in the editor at once to edit in relation to each other. Then have a key option (alt) to edit and affect all at once.

One more feature suggestion for the future... when I make a 2,3 or 4 duplicate, I would like for a 3rd adjustment to appear so I can scale the heights to slope up or down. That would be much easier than having to use 4 stages to do that! And it saves stages for other uses too.

Post

The feature I miss most is units of measurement. The data display widget can (and does) show arbitrary text for a number of controls, especially those with discrete values selected from a popup menu. For continuous parameters, it generally just shows a number from 0 to 100. I wish it could tell me how that would translate into, say, milliseconds (for envelope parameters) or hertz (for LFO rate modulation).

There's at least one DAW vendor that does this as a rule with all its stock plugins. It's technically doable. I also realize it isn't likely to happen. The code that scales those raw parameter values for use in the sound engine isn't necessarily modular enough to be reused by the UI, and even if someone refactored it to make that possible, they'd run the risk of introducing horrible new bugs. I've never seen anyone else complain about this, so it must be of limited utility to other users. As such, I'll have to leave it in "I want a pony" territory. At least for now.
I hate signatures too.

Post

I agree on units of measurement being great wherever possible - especially in combination with typing to enter values it's pretty crazy (especially if you can do basic math in that write in box like C2*3 to get the third harmonic of C2 in a pitch value or C3*5/3 to get integer just tuning increments etc) but that's something that almost certainly needs to be baked into your plugin right from the start and frankly it sounds like a nightmare to do in a plugin rather than a DAW since you have no idea how a host is going to handle keyboard inputs to your plugin.

Post

I'm not too worried about keyboard input in principle. If a plugin can handle text entry in its preset browser, then text entry in general shouldn't be a problem. There are slightly bigger fish to fry. For example:
  1. If the control's behavior is nonlinear, how should text input be translated back into parameter values? An inverse function? What if you can't write one? Maybe a lookup table? How exactly should that be generated, and when? (I have to remind myself not to freak out over performance, because this operation will be performed very rarely.)
  2. What about measuring modulation? When you modulate a nonlinear control, how do you report the amount of modulation to the user without making everything confusing? Maybe by showing them the range of possible values (eg. "3ms to 750ms")? How should this representation distinguish between unipolar and bipolar modulation ranges? What if other modulation sources are affecting the same parameter?
  3. Can the user input text to change the degree of modulation? What parts can they edit? In the event that they modify one end of a bipolar modulation range, what else changes? The obvious answer is "the other end of the range," but if they're specifically setting one end of the range to an exact amount, isn't it likely that they'll want it to stay there while they edit the other end?
  4. How does the UI accommodate all this? In the current incarnation of Hive (as with most controls in most u-he plugins) there are no numeric indicators on the knobs or sliders, and the data display widget only shows the value of a parameter when you hover over it. Where does the editable text widget go? Does it appear temporarily over the control the user is editing? How does the user initiate "edit mode?" How is it different for modulation controls?
Like I said, this feature is a pony. Maybe I should take it to the Zebra 3 thread...
I hate signatures too.

Post

oh yeah, I would literally never expect that feature to be added to an existing product unless it was a major version number upgrade.

Post

Super Piano Hater 64 wrote: Sat Apr 03, 2021 3:46 am
  1. If the control's behavior is nonlinear, how should text input be translated back into parameter values? An inverse function? What if you can't write one? Maybe a lookup table? How exactly should that be generated, and when? (I have to remind myself not to freak out over performance, because this operation will be performed very rarely.)
  2. What about measuring modulation? When you modulate a nonlinear control, how do you report the amount of modulation to the user without making everything confusing? Maybe by showing them the range of possible values (eg. "3ms to 750ms")? How should this representation distinguish between unipolar and bipolar modulation ranges? What if other modulation sources are affecting the same parameter?
  3. Can the user input text to change the degree of modulation? What parts can they edit? In the event that they modify one end of a bipolar modulation range, what else changes? The obvious answer is "the other end of the range," but if they're specifically setting one end of the range to an exact amount, isn't it likely that they'll want it to stay there while they edit the other end?
  4. How does the UI accommodate all this? In the current incarnation of Hive (as with most controls in most u-he plugins) there are no numeric indicators on the knobs or sliders, and the data display widget only shows the value of a parameter when you hover over it. Where does the editable text widget go? Does it appear temporarily over the control the user is editing? How does the user initiate "edit mode?" How is it different for modulation controls?
We've solved all of those problems in Surge, it's totally doable, sometimes tricky, but doable.

1. Yes, inverse functions.
2. Modulation usually done in percentages unless it's a linear scaling, then you can use the actual unit that the parameter is using. OTOH, we do allow setting filter cutoff modulation in Hz, but then it is valid for the positive direction only, negative direction gets rescaled exponentially - however we do have an option to show actual min-max modulation ranges in the popup so that helps in understanding how far your modulation swings numerically. Example:

Image

3. Bipolar modulators always swing -1 to 1, that's what the modulation engine sees. Now if something's been remapped using a modmapper that's a different thing, but what matters most is setting up the extremas.
4. We have these things on a right-click. You get "Edit Value", then a list of all mod assignments for that parameter, all of which are also clickable in order to edit their amounts.

Post

I don't think one can compare an engine that drives one plug-in with a Reaktor-like engine that drives a whole range of rather different plug-ins. That is, what works for Surge might not work for u-he.

Post

For sure. However the principle of "control types" we use is rather generic and expandable, so any specific use case can be handled for whatever parameter unit, scaling or range. Yes, there's a forest of them, takes a little bit of getting used to, but results are there. Crucial stuff is in Parameter::get_display(), ::get_display_of_modulation_depth(), ::set_value_from_string_onto(). There are of course methods for quantizing to arbitrary steps (::bound_value(), ::quantize_modulation()) and so on.

Post

Well, I think that part of what makes our user experience great is that parameters are not scaled in non-linear manner. There are exceptions in Presswerk and Satin IIRC, and those are constant source of grief.

We still achieve linearity by using meaningful units wherever we can. For example, filter cutoff is always set in semitones. Therefore, the way of mouse travel is always the same for each octave, which feels natural. A display in Hertz for instance would make this awkward - either mouse travel or value change would be out of proportion. That's just one example, but a very large part of our parameters is actually based on dB, percent, semitones, octaves, order-of-magnitude or gain, even if we don't necessarily display the actual unit.

Other examples are abstract parameters. Envelope times for instance are completely non-linear. They are often tweaked so that a "region of interest" gets more mouse travel - thus, finer control - than "regions of arbitrariness" where fine control matters less. In addition, such parameters may change their scaling based on other parameters. In Diva for instance there's exactly 1 attack parameter per envelope, but it is interpreted entirely differently among the variety of envelope models. This example shows what obstacles there are:

- parameters may offer "better feel" and better control if using an abstract unit
- parameter value distribution may be based on non-trivial concepts ("region of interest")
- parameter value distribution may change based on other parameters (e.g. mode selection)

A further example is the "times" and "time base" combo in Uhbik's modulation effects. One parameter actually sets the unit of the other. Thus the meaning can completely change:

- parameters may fully change their behaviour based on other parameters (e.g. mode selection)

Now, this is the bar. There's no use to start implementing visual display and text input unless it works for any of these more complex cases. It is obvious that the solution is not a mere issue of user interface design. The logic behind meaningful units for parameters that require abstract and dynamic scaling needs to exist on parameter level, which in our case is a property on the DSP-level. This makes it a non-trivial issue for us since executable code from the DSP part can't be passed to the UI and vice versa. Only data can be passed, for good reason. While that's not complicated (we don't do asynchronous data exchange), there's another obstacle: It might take a while.

And that's what happened. We do have the display side (not the text entry side) "ready to merge" on a branch in our code repository. However, this project took a long time, it was devised by a developer who left us and it may well be out of step with some of the other things which took a long time to implement. And that is before updating hundreds if not thousands of parameters in our existing projects. It reminds me of the aftermath of updating our preset browser which has brought a lot of tedious work to QA as well as content development.

In short: We are aware, we have the tech side almost finished, but we are a bit afraid that it's opening pandora's box on us. And it still doesn't let people enter text with arbitrary units or formulas even.

Post Reply

Return to “u-he”