Zynewave's Forum Page

You can avoid the starting gap on the parameter track, by enabling punch-in on the transport toolbar, and keeping the punch-in position at zero.

But your post made me think. Starting recorded sequences at the play cursor position makes sense for note sequences, but not really for automation. So there is a new 2.06 beta7 with:

• Recording parameter automation will create curve sequence events starting at the beginning of the arrangement instead of at the current play position.

@aMUSEd wrote:

@Zynewave wrote:

The problem here is in the way that automation is designed in the VST spec. When a VST parameter is automated it will change the loaded patch directly. Stopping playback during automation will thus leave that parameter/patch at the last automated value. If you then restart playback at a point before the first recorded automation, it would result in a random patch (= random sound) depending on where you last stopped playback. That is why Podium always sets the parameter value at playback start.

I’m sorry but I don’t understand this at all – if this is in the VST spec then how come no other host I know of sets the cutoff or other param to zero at the start and end? Surely the “default” starting point should be the position the instrument is set to at the start of recording, not zero? Just as a comparison look at how this is handled in another host:

Note the cutoff value for this patch “kickass drone” is at 49% and even though I don’t actually touch the knob to change the cutoff value till halfway through the sequence (marked in red) the host correctly starts the envelope at the 49% position and ends at the point where I let go of the knob.

What I was arguing for was that a host needs to set all parameter values at playback start, to make sure that the automated parameter values are consistent no matter where on the timeline you start playback. I misunderstood your post as suggesting that the host should not set the parameter values until the first recorded parameter change. That can lead to random sound. What the host can do is to set a starting point on the curve when the automation lane is created. The value of this event can be set to the current parameter value in the plugin. This value will then be played by the host up to the point where you start recording changes. I think that’s also what you see on your screenshot of the other host. There is a point at the start of the automation lane.

Questions:

If you change the VSTi patch after you created this automation lane, will this host change the starting point of the curve to match the value of the parameter in the new patch?

Can you grab the first point on the automation lane and drag it to the right on the timeline? In that case, what will the curve look like up to the first point?

Thanks for the feedback.

@aMUSEd wrote:

It never used to do this. If a cutoff knob was at a third of the way round it always stayed there until you moved it and didn’t reset it self to zero every time – I can’t see any possible musical value in a knob doing that as it means the VSTi starts silent.

Podium has always set the automation value of all automated parameter tracks at playback start. You may not have noticed this if you have started automation recording before playing notes on the VSTi, or if you have automated parameters whose default value does not make the VSTi go silent.

A plugin should always start at the position it is at for the particular patch it has loaded – otherwise Podium is changing that patch at the start and affecting the sound (which no host should do).

The problem here is in the way that automation is designed in the VST spec. When a VST parameter is automated it will change the loaded patch directly. Stopping playback during automation will thus leave that parameter/patch at the last automated value. If you then restart playback at a point before the first recorded automation, it would result in a random patch (= random sound) depending on where you last stopped playback. That is why Podium always sets the parameter value at playback start.

The question is where this default value should be taken from. As explained above, it cannot rely on the current parameter value in the VSTi. Currently Podium uses the default value defined in the parameter object properties. I’m going to do a thorough revision of the automation system in one of the next releases, at which point I’ll look at the alternative solution that druid nicely described:

@druid wrote:

One solution is for Podium to know there is an automation, then when playback is started quickly look for the previous clip from playback point and set it to the last value, and if there isn’t one, look for the next clip after playback point, and set it to the first value. Unless someone has hundreds of automation lanes (which isn’t unreasonable I guess) I don’t think this would slow anything down.