Hive2 feature request thread

[chrisstiles]

I think the new Equator 2 is probably the best balance of this - it's not flashy, but all of the visual stuff is implemented in a really sensible and practical way.

That's really functional in a beautiful sort of way, I don't expect everyone to agree because some folk seem to still like skeumorphic interfaces, but it looks like they've put in a ton of work into making something that's visually clear and with controls that are easy to adjust on a computer with a mouse.

[Pepin]

Hey, I've started using Hive in Bitwig (on mac), and unless I'm missing something there don't appear to be keyboard shortcuts for undo and redo. It would be super useful for these to exist for DAWs like Bitwig that don't have their own undo system for VSTs.

As an example, Reason Rack Plugin has working undo shortcuts in Bitwig, so it should be possible I think. Bitwig appears to prioritize plugins over itself for keyboard shortcuts.

[Stirner]

Switching wavetables is not automatable. Is there a reason for it?
All wavetable parameters can be tweaked with a MIDI controller (NKS in my case), without looking on the monitor. But for switching the wavetables (a very important parameter in the beginning of a patch) a mouse is needed. It would be great if completely mouseless programming would be possible.

+1 to the earlier suggestion that the endpoint of the wavetable-position-loop should also be controllable.

[Urs]

Automatable parameters need to have a fixed range, say, 0-100. If we made wavetable selection an automatable parameter, it would have a different range every time new wavetables are added. This would break existing projects where the wavetable selection is automated.

[Stirner]

This makes sense of course. What about not automatable but just controllable by MIDI/NKS? Two "PRG UP/PRG DOWN" triggers that are used for programming patches, not for track automation.

[Dazd_N_Confuzd]

Apologies if it's been mentioned already but a delay/fade in on the LFOs would be handy.

[MitchK1989]

Apologies if it's been mentioned already but a delay/fade in on the LFOs would be handy.

You can already do that in a more controllable manner by multiplying the LFO by a ramp generator or ADSR in the mod matrix but yeah a 1 knob control that doesn't use up another module could certainly be handy sometimes.

[zerocrossing]

I think the new Equator 2 is probably the best balance of this - it's not flashy, but all of the visual stuff is implemented in a really sensible and practical way.

That's really functional in a beautiful sort of way, I don't expect everyone to agree because some folk seem to still like skeumorphic interfaces, but it looks like they've put in a ton of work into making something that's visually clear and with controls that are easy to adjust on a computer with a mouse.

It’s not as much about people liking or disliking skeuomorphic UI designs as much as it is about the difficulty in designing a good non-skeuomorphic UI well. A good design of either type contains visual information that informs the user of the purpose of that element and how one is to interact with it. A bad design removes that visual information and leaves it up to the user to figure things out. If your mind has to think, “is this number something I can click and drag or is is just a display of information?”then you have failed. It doesn’t have to look like a vintage chicken-head knob from 1965, but you need to somehow inform your user.

[Dazd_N_Confuzd]

Apologies if it's been mentioned already but a delay/fade in on the LFOs would be handy.

You can already do that in a more controllable manner by multiplying the LFO by a ramp generator or ADSR in the mod matrix but yeah a 1 knob control that doesn't use up another module could certainly be handy sometimes.

Thanks I'll give that a shot.

[chrisstiles]

A bad design removes that visual information and leaves it up to the user to figure things out. If your mind has to think, “is this number something I can click and drag or is is just a display of information?”then you have failed. It doesn’t have to look like a vintage chicken-head knob from 1965, but you need to somehow inform your user.

I think often the skeumorphic option is often the safe and lazy option in vsts. And plenty of effects manage to implement the chicken knob without thinking much about how you might use a mouse to ‘turn’ it.

[Hanz Meyzer]

Panning also for dry output, so you can actually pan the sum of other fx vs the reverb/delay. Ultimately each fx's wet amount + dry out would have a panning

[psycargo]

Switching wavetables is not automatable. Is there a reason for it?
All wavetable parameters can be tweaked with a MIDI controller (NKS in my case), without looking on the monitor. But for switching the wavetables (a very important parameter in the beginning of a patch) a mouse is needed. It would be great if completely mouseless programming would be possible.

+1 to the earlier suggestion that the endpoint of the wavetable-position-loop should also be controllable.

Automatable parameters need to have a fixed range, say, 0-100. If we made wavetable selection an automatable parameter, it would have a different range every time new wavetables are added. This would break existing projects where the wavetable selection is automated.

It would be great if you could make the arrow buttons "next wavetable" and "previous wavetable" accessible to MIDI. That would help a lot to be able to program sounds with a MIDI controller without a mouse.

[Alex_Longard]

Psycargo
For several years, i begging for Urs to make some parameters convenient for midi-controller. He is still disagreeable. For me it is very sad...

For example, i can't drag the effects to another location in FXGrid, and i can only dream that the menu appears in the future to move the up / down effect.

[Urs]

To be fair, I usually lay out the reasons as to why this or that isn't automatable. Sometimes it's historic limitations of plug-in formats or host powers. Often though it's by design.

For instance, MIDI events reach a plug-in on realtime threads. They are time critical. This means, one can not load a file in direct response to a MIDI event (or allocate memory, or do otherwise complex computations). So, implementing prev/next buttons for presets (which are files) in response to MIDI events is not as trivial as it sounds. There needs to be built an infrastructure around this, and we simply haven't had resources to prioritise this yet.

The matter of order of modules in our "Grids" is even more complicated. Sure, for one column and a couple of rows there might be a solution. But bear in mind that some Grids have multiple columns and even more rows. For some Grids there are more modules available to insert than there are spaces in the Grid. While I can come up with concepts to attach some kind of navigation or status to individual modules or cells in the Grid, I can't begin to fathom what a custom built MIDI Controller would look like which may handle this.

That said, we are very aware of these issues. We would love to find solutions and provide them to you. If we haven't yet, it's not that we don't want to or that we insist that they're bad. It's merely so that we either haven't been able to, haven't had the time to or simply haven't found a good solution yet.

[Alex_Longard]

Urs,
i do not blame you, you promised to think far in the future and make, i am patiently waiting

I still break the skin, and i think how to replace FXGrid, to collect effects in the menu, as is work in the oscilator menus.

In Hive already there is a well working automation, i will collect my notes and try to explain. Perhaps we will come up with a compromise together, which will be convenient for everyone.
Sorry, i am a programmer, i easily show my thoughts in the code.