Hive 2: Recording modulation source

[goli]

Consider the following:
I have a patch in Hive that modulates the cutoff of filter 1 using LFO 1.
LFO 1 uses the 'rand glide' waveform.

Let's say for the most part the result I get with this "randomness" are pretty good.
But occasionally I'd like to tweak it a bit.

My thought was to somehow record this modulation (e.g. as automation or midi CC), so that I could thereafter unmap the LFO and modulate the cutoff using the tweaked automation envelope in combination with a 'Constant' modulation source in Hive.

But even after reading into the manual I couldn't figure out a way to achieve this "recording of internal modulation".
I tried modulating a modulation matrix depth controller with the LFO, hoping I could record that parameter.
But it seems to me that the LFO's modulation is only added internally within Hive; it doesn't cause any external changes that I could record as an automation event.
And it's not like I could select MidiCC as a modulation target either to map the LFO externally that way.


My "good enough" workaround for the time being is to render a patch with "randomness" a bunch of times and then choose the best takes accross all "performances".
But that comes with all the drawbacks of "rendering" (i.e. no longer tweakable).


So now the question:
Is there any way one can "record" Hive's internally modulation sources (e.g. LFO, Envelopes, Share Sequencer, etc.) externally (i.e. as automation event or MidiCC)?




Hive version: 2 (8676 linux VST2)
DAW: Reaper for linux (latest stable; 6.15)

[Urs]

I'm afraid, there's not much one can do to publish modulation signals to the host environment.

You can of course use the "Constant" modulation source to push host automation into the plug-in, but the other way round is difficult. That is, plug-in formats are not meant to publish automation data that's generated by LFOs and such, automation data is always meant to bu the result of user interaction.

[goli]

Ok, didn't know that the VST standard defines it that clearly that automation data is unidirectional
I did hope that because VSTs that generate MidiCC exist, there might be some other way to achieve this.

But anyway: Thanks for the clarification!

[Urs]

It's certainly possible to do it, but it's a bit can or worms. It won't work everywhere... which puts us in a dilemma (would love to do it, but am afraid of the amount of support for people who are disappointed when it doesn't work for them)

[goli]

Yeah, I guess "the less you know, the easier you think it is" thing applies here as well.
Obviously I don't know the details of what it would require from a development point of view and can only vaguely guess how much it would take to make it a "robust" feature (going for "works more or less in most cases" obviously is not the goal).

[EvilDragon]

Host automation is in fact bidirectional (because the plugin talks to the host regarding parameters that are being moved so that host can pick them up and write the knob movements in the automation lanes when you arm automation). But indeed, plugins can't SET automation. They just tell the host "oh hey I was moved, write me down!", and listen to what host sends back.

However, there are certain plugins (Expert Sleepers Silent Way) which convert modulation into CVs that's sent over plugin outputs outside of your computer. That's basically DC signals. There's definitely a way for a secondary plugin to pick this up and do something with it. I bet in Reaper, Bitwig and maybe FL this is all possible and you can a lot of curious stuff with it.

[clangorous]

A low-tech workaround...use the LFO (set to random glide) to modulate OSC volume (set to just a basic waveform), play a single note for the duration you need (maybe the whole track) and record it. Then use the waveform of the recording as a guide to manually draw the automation curve for Mod Wheel or any automatable mod source...Since it is random anyway, it doesn't have to be perfect, and is tweakable.

[goli]

A low-tech workaround...use the LFO (set to random glide) to modulate OSC volume (set to just a basic waveform), play a single note for the duration you need (maybe the whole track) and record it. Then use the waveform of the recording as a guide to manually draw the automation curve for Mod Wheel or any automatable mod source...Since it is random anyway, it doesn't have to be perfect, and is tweakable.

Actually an interesting idea!
But I forgot to mention that the LFO is restarted based on "gate".
So a single note won't give the desired results.

Anyway, here's what I've tried:
- reuse the original MIDI item with the actual melody
- make a new track with a really basic patch that modultes a single sine wave osc's volume with the desired modulation (i.e. LFO "rand glide" with desired settings).
- render the track
- manually draw a new envelope that matches the waveform outline



But yeah, that's just three single notes.
Depending on the length and complexity of a melody, this process could take some time.
Nevertheless, you'd end up with an envelope how I originally wanted it. Thereafter one could play around with scaling and constant automation to match up with the original patch.

But while doing this, a couple more problems came to mind:
1) Due to the LFO restating based on "gate", I would have to be mindful of every MIDI note move I make thereafter to make sure I line up the envelope as needed.
2) This method won't work that easily (if at all) for something like "random phase' on an osc. But depending on how subtle such randomness is, it might be fine to leave "uncontrolled" (i.e. Hive's own randomness).
3) Another thing that will be quite difficult to reproduce that way is random modulation of polyphonic material (i.e. random modulation per midi event).

Looking at this from a workflow point of view, it just seems not even worth it at this point.
Simply rendering a random patch a bunch of times and then comping the "performances" to get a good final take actually seems more practical in the context of producing music.

[pdxindy]

Looking at this from a workflow point of view, it just seems not even worth it at this point.
Simply rendering a random patch a bunch of times and then comping the "performances" to get a good final take actually seems more practical in the context of producing music.

+1