I thought this was a problem with the beta but I find it’s happening in 2.05 too (guess I hadn’t played enough with it recently).
recording automation is messed up. Midi recording itself seems Ok but as soon as I try and record knob tweaks I get a number of playback errors. e.g. if I record something like cutoff it then sets cutoff to zero at the start of the track when I play it back. It also sets it to zero at the end. Seems to do this with any automated param.
Anyone else having this problem? Seems to be with any VSTi? Even basic ones like iMPoscar and Linplug Alpha.
I tried automating the cutoff of Firebird but I haven’t any problem. Could you post a step to step to reproduce the problem?
Just insert plugin – record midi – tweak knobs.
On playback knobs set themselves to zero at the beginning and end of the track.
Ah this issue. It’s not a bug I think you’ll find. I asked about this a while ago. I was thinking I could make short clips that moved knobs and then when the clip ended, the knob would stay where it was last set. Podium does not work this way, however. If you get into the innards of the settings for the imported VST paramter, you can set the default value, which gets set whenever a clip is not present.
The solution is to have the clip last the entire length you need it to be set to any value you choose.
I can see the virtue of both sides. If you have no clip after a change, and it sets to really high, but at the start of the clip it sets to lower, and you then start playback from earlier after it went later, it will be high then suddenly jump to low at the clip.
I think I mentioned, though I can’t remember if Frits read and responded to it or not, a solution.
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.
So yes, you’ll find the default value setting in the parameter’s settings.
[edit]
Yes, Frits did say he *may* add an option in the future to allow the behaviour I described (in some form).
See here for my thread, and inside there another link to another thread, discussing this “issue”.
http://www.zynewave.com/forum/viewtopic.php?t=1672&highlight=
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. 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). Similarly it should always retain the last position it was in when last moved for the same reason – it is me who should be in control of knob positions – not Podium. I can’t see what has changed it always recorded automation perfectly before. Flawless and set up free automation has up till now been the main reason I’ve stuck with Podium despite it’s difficulty in other respects. If I need to start using workarounds just to get it to record automation properly I can’t see why I should bother. It should not be doing this so as far as I’m concerned its a bug.
@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.
Glad I can be of some help with ideas. 😉
It would be greatly appreciated if you did this Frits. Entire song length envelopes are all well and good, but there is a lot to be said for using shorter clips too.
For instance, I could want to clone a MIDI clip and an automation clip that are meant to go together. If I have a full track length automation clip, I can’t copy it along with the smaller MIDI clip. Or, even if I did, it would overlay the large automation clip with a smaller one. Very messy. But if one can use smaller clips, these can be attached to the MIDI and treated as one. This may be beneficial for filter sweeps and the like where a MIDI 0-127 parameter is just .. a little bad for resolution.
One could always use short clips, then when the song is complete, select all and glue together (as I have done so far) but then one must suffer the potential issues while producing, until they complete the track (or at least the automation lane).
I also tend towards pattern-based approaches, so to me the more efficient method of using smaller clips makes more sense. 😉
@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.
In Podium I can make the same sequence but it will drop to the cutoff to zero at the start of the track right up until the point I tweak the knob and again at the end – making the sequence silent right up until the point where I touch the knob even though I am playing notes before that. And this is just a simple sequence – imagine how this would affect a more complex sequence with lots of params being moved at different times – nothing would sound the same on playback as it did when I recorded it. That can’t be right.
@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.
@Zynewave wrote:
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?
No if you change the patch the cutoff jumps to the recorded position rather than retaining the patch position – but I would expect that.
@Zynewave wrote:
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?
This
But note even then it does not start at zero – it starts at the patch’s value of 49%
(The host is Energy XT 2 btw but this is what I expect as standard behaviour regarding automation of plugin values – it should always record exactly what is played)
@Zynewave wrote:
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.
Yes there is – all I’m saying is that point (and the end point) should be determined by the starting and end positions of the plugin param (which would normally be at the start the position set by the patch loaded and at the end the last point that value was left at after being moved by the player), not by some arbitrary “default” value or setting like zero. Otherwise what you play back will not be a faithful replication of what you played when recording.
@aMUSEd wrote:
@Zynewave wrote:
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?
No if you change the patch the cutoff jumps to the recorded position rather than retaining the patch position – but I would expect that.
So would I.
@Zynewave wrote:
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?
This
But note even then it does not start at zero – it starts at the patch’s value of 49%
(The host is Energy XT 2 btw but this is what I expect as standard behaviour regarding automation of plugin values – it should always record exactly what is played)
Not entirely true.
I got curious, so I just downloaded the XT2 demo. As I anticipated: If you move the first point on the automation lane to the right on the timeline, then XT2 will not set the parameter value when starting playback before this point. In other words, if you stopped playback at a point where the parameter was automated at a low value, starting playback from zero will start out with the low value. If you stopped playback where the parameter was at a high value, starting playback from zero will start out with the high value. Thus playback up to the first automation point will be unpredictable, and will depend on where you stopped playback last. That is the situation I would like to avoid.
I’m going to extend the automation system in Podium so that a default starting point will always be inserted at the start of new curve sequences, and if it’s a VST parameter then the starting value will be grabbed from the current plugin preset. This should elliminate the problem you experience with the parameter value jumps.
That would be great thanks
I’ve made this change to the latest 2.06 beta:
• New curve sequences now by default have a point event at the start of the sequence. If it controls a VST parameter then the value of the point is set to the current parameter value in the plugin.
Let me know if this improves your automation experience 😉
What may still be an inconvenience to you, is that the parameter will revert to the default value outside of any curve sequence events on the parameter track. Making an alternative to this behaviour will have to wait for a later release.