Topic: Preview 2.15: New automation system

This topic has 55 replies, 11 voices, and was last updated 14 years, 11 months ago by Zynewave.

Viewing 15 posts - 1 through 15 (of 56 total)

1 2 3 4 →

April 30, 2009 at 02:40 #1921

Zynewave
Keymaster

The 2.15 release will feature a revision of the way that automation (parameter tracks) are handled. For years, the old system has often been the subject of discussion on this forum, so this update has been under preparation for a long time.

The old system handled each curve sequence on a parameter track as a separate playback object, similar to how note sequences and sound events are handled. This had the effect that parameters reset to default values when playback went over a timeline section where there were no curve sequence events. Many users have reported this to be an undesirable behaviour.

The new system still uses the same old curve sequence events and curve editor, but instead of handling all curve sequence event as individual curves, there now is a single track curve. The points in this track curve is made up of the points in the visible part of the curve sequences. The track curve stretches from the start of the arrangement to infinity on the timeline. If you have two joining curve sequences then the track curve is seemless from the last point in the first sequence to the first point in the following sequence. In the old system you could get a sharp edge in the transition between the two curve sequences.

The new system also allows for curve sequence events to be overlapped. This resulted in unpredictable playback with the old system, as playback of the individual curves would conflict. Overlapping curve sequence events can now be used to for example create a fade in/out on top of a longer fade curve.

I’ve considered many different approaches, before settling on this design. Full backward compatibility with older projects was not possible. If your older projects relies on the parameter reverting to default values on parameter tracks, you will need to modify these curves by adding points that will set the curve to the default value. I’m sorry for this inconvenience, but I found it necessary in order to get the best possible automation system.

I still need to do a lot of testing and optimization, and I’m still tracking down some crash-bugs. Those that are eager to try the new system can download the 2.15 beta1 in the VIP lounge.

Please post your thoughts about the new automation system.

April 30, 2009 at 05:38 #15022

thcilnnahoj
Participant

Very clever and simple solution. Nod, nod.
Off to download it for testing in the evening! 🙂

April 30, 2009 at 05:58 #15023

LiquidProj3ct
Participant

I’m testing it right now. Big effort Frits! rewritting an entire part of the code of a program is something that is rare in vst host [like Live with its (old?) 128 parameters limitation]. Thanks 😀

1. (see picture) It’s smudged, as if it’s trying show also the big event points.

2. (see picture) I like to draw my own automation curves with pencil tool. If I try to describe a new curve with a starting point very close to an existing point is imposible draw the curve, because instead draw it you select the point and move it in its allowed range . Please, could I avoid this behaviour? maybe a button for show/hide the points, or maybe that pencil tool don’t select points, or maybe that if while you’re dragging with pencil tool a point you go out of its range and start to drag in the range of another one then the pencil write new points as usual.

April 30, 2009 at 06:21 #15024

LiquidProj3ct
Participant

Visual bug: Open a piano roll editor (not embedded) and close it, then double click in any curve sequence and instead curve editor you will see another piano roll editor (if you double click in the curve sequence again you’ll see the usual curve editor).

edit: Related to this bug you get this screen

but if you drag the small bottom bar you get this:

😯 something new you’re working?

April 30, 2009 at 06:36 #15025

druid
Participant

Can’t really test, but at least I tried it and I like the balance between separate events and a continuous envelope. This is how I wished it would work (from what I can tell so far)! Thank you!

April 30, 2009 at 09:52 #15026

LiquidProj3ct
Participant

Some automation recording problems:

1. The fader of the parameter record its movement even if track is unarmed and master record is off. This is an old behaviour (bug?) that I don’t like at all.

2. While I record, if I tweak a VSTi parameter the movement is recorded in the curve sequence (that I created before start recording with a certain curve). However if I stop of move the knob and keep it in a certain value the curve sequence isn’t updated (bug? bad behaviour?)

Thanks

April 30, 2009 at 10:50 #15027

pavouk100
Participant

Simple, powerful, awesome. Thank you Fritz, it is real improvement.

I understand that you have a lot of work finishing and polishing this change, but I’d like to suggest two following improvements for automation:

1. When automating VST parameter, would it be possible to see units of the current VST parameter (as e.g. in Podium’s generic VST effect ui), instead of number between 0 to 1?

2. When automating Level, would it be possible to have values from -Inf to +12dB (as mixer faders have) instead of -Inf..0 (in other words, allow also amplification, not only attenuation).

Thanks,
Pavel

April 30, 2009 at 11:02 #15028

LiquidProj3ct
Participant

@pavouk100 wrote:

1. When automating VST parameter, would it be possible to see units of the current VST parameter (as e.g. in Podium’s generic VST effect ui), instead of number between 0 to 1?

I think that’s imposible due to VST 2.4 specifications… sorry (but internal plugins do). Maybe he could use 0.0 to 100.0%.

2. When automating Level, would it be possible to have values from -Inf to +12dB (as mixer faders have) instead of -Inf..0 (in other words, allow also amplification, not only attenuation).

The level that you automate isn’t the mixer level, is another one relative to the first one… so as it’s relative it haven’t sense the amplification. If you need amplification do it with the main volume fader and reduce the level of the relative one 😉

best regards

April 30, 2009 at 12:49 #15029

pavouk100
Participant

@LiquidProj3ct wrote:

@pavouk100 wrote:

1. When automating VST parameter, would it be possible to see units of the current VST parameter (as e.g. in Podium’s generic VST effect ui), instead of number between 0 to 1?

I think that’s imposible due to VST 2.4 specifications… sorry (but internal plugins do). Maybe he could use 0.0 to 100.0%.

Ah, ok. But then, how can internal VST ui editor know about correct units? And, I’ve vague feeling, that when I was working with old Cubase, automation curves did appear with real units/ranges, even for 3rd party VSts, but my memory might fault me on this one.

@LiquidProj3ct wrote:

2. When automating Level, would it be possible to have values from -Inf to +12dB (as mixer faders have) instead of -Inf..0 (in other words, allow also amplification, not only attenuation).

The level that you automate isn’t the mixer level, is another one relative to the first one… so as it’s relative it haven’t sense the amplification. If you need amplification do it with the main volume fader and reduce the level of the relative one 😉

I know that it is relative level. and I know that I can increase main fader. Its just that it is incovnenient, if you need to raise volume for a small bit of time; you already have carefully adjusted volume for the rest of the track and you want one small piece louder – current system makes it a bit inconvenient. And I don’t see how the fact that automated volume is relative implies that it cannot go into +dB values 😕

regards,
Pavel

April 30, 2009 at 13:37 #15030

LiquidProj3ct
Participant

@pavouk100 wrote:

Ah, ok. But then, how can internal VST ui editor know about correct units?

Because those aren’t VST, they’re ‘z’ plugins 😉

@pavouk100 wrote:

I know that it is relative level. and I know that I can increase main fader. Its just that it is incovnenient, if you need to raise volume for a small bit of time; you already have carefully adjusted volume for the rest of the track and you want one small piece louder – current system makes it a bit inconvenient. And I don’t see how the fact that automated volume is relative implies that it cannot go into +dB values 😕

I’m gonna try to explain it with my clumsy english. Imagine that the range of relative volume fader is 0 to 200% instead actual 0 to 100%. That’s mean you can go from mute until double the volume of the absolut volume fader, right?

Imagine now that the value of absolut volumen is between 0 and 100, and is set in 30. With our new relative value fader you can tweak this value from zero to 60.

But what’s the drawback? In a future Podium will support MIDI CC (i hope), then if you assign that relative volume fader to a physical fader of your MIDI controller and you want to record complex real time gating is too easy that you overcome the 50% of the fader and you will have undesired peaks of volume that you’ll to manually verify.

Now let’s go back to Podium 2.15beta1, the relative volumen fader is between 0 and 100%. You have the absolute fader set in 30 and you want get a volume of 60 with relative fader. How do you do it? Easy, set the value of absolut volume fader at 60, and set the relative fader to 50%. 60 * 50% = 30… so it’s the same result that if you would have an 200% relative fader value.

In the same line, with a 200% relative volume fader, I could use the MIDI controller decreasing the absolute value to half and overcome the last problem, cann’t it? 200% * 15 = 30. Yes that’s true… but there is new drawbacks:
– Frits will have to program an independent new fader for automate volume (Since other parameter as cutoff don’t overcome 100% of its value)
– You will have tons of faders (those that you wanted to automate with midi controller) in a different scale that other, 2:1, so mixer would be confusing at mixing stage. Think in your own terms, how many times do you need raise the relative volume instead decrease it? I’m sure that one or two as max.

Maybe I’m wrong, but I think that it would be annoying for mixer & mixing stage workflow 😉

April 30, 2009 at 14:14 #15032

pavouk100
Participant

@LiquidProj3ct wrote:

@pavouk100 wrote:

Ah, ok. But then, how can internal VST ui editor know about correct units?

Because those aren’t VST, they’re ‘z’ plugins 😉

No, I mean really VST plugins , but using podium’s native UI – you can force podium to bypass plugin’s UI (by ‘Use generic editor instead of plugin editor’ checkbox in ‘Device mapping properties’ of any VST plugin). In this case, podium knows very well about proper ranges and units for every tweakable (automatable) parameter, so this leads me to believe that my original requested feature is feasible. 😉

April 30, 2009 at 14:20 #15033

pavouk100
Participant

@LiquidProj3ct wrote:

@pavouk100 wrote:

I know that it is relative level. and I know that I can increase main fader. Its just that it is incovnenient, if you need to raise volume for a small bit of time; you already have carefully adjusted volume for the rest of the track and you want one small piece louder – current system makes it a bit inconvenient. And I don’t see how the fact that automated volume is relative implies that it cannot go into +dB values 😕

I’m gonna try to explain it … explanation snipped

Ok, I didn’t think about consequences you wrote. Anyway, I can easily do what I want by inserting FreeG and automating its fader instead, so this is no big deal. Anyway, thanks for taking time to explain it.

April 30, 2009 at 16:07 #15035

LiquidProj3ct
Participant

@pavouk100 wrote:

No, I mean really VST plugins , but using podium’s native UI – you can force podium to bypass plugin’s UI (by ‘Use generic editor instead of plugin editor’ checkbox in ‘Device mapping properties’ of any VST plugin). In this case, podium knows very well about proper ranges and units for every tweakable (automatable) parameter, so this leads me to believe that my original requested feature is feasible. 😉

I understand now 🙂 Unfortunately I don’t think that Frits could do nothing here, except improve the interface of nongui plugins: those units come defined inside the vst. Check mda detune vs firebird:

May 1, 2009 at 02:40 #15040

druid
Participant

I believe I also recall Cubase being able to understand units from VST plugins. I don’t think it’s impossible. And I’d kind of like it, but I’m ok with it at the moment. I WOULD like to be able to enter exact values however, a nd if it’s not going to be exactly what’s inside the plugin, then I’d like at least three decimals of resolution!

May 1, 2009 at 02:42 #15041

Zynewave
Keymaster

@LiquidProj3ct wrote:

I’m testing it right now. Big effort Frits! rewritting an entire part of the code of a program is something that is rare in vst host [like Live with its (old?) 128 parameters limitation]. Thanks 😀

1. (see picture) It’s smudged, as if it’s trying show also the big event points.

2. (see picture) I like to draw my own automation curves with pencil tool. If I try to describe a new curve with a starting point very close to an existing point is imposible draw the curve, because instead draw it you select the point and move it in its allowed range . Please, could I avoid this behaviour? maybe a button for show/hide the points, or maybe that pencil tool don’t select points, or maybe that if while you’re dragging with pencil tool a point you go out of its range and start to drag in the range of another one then the pencil write new points as usual.

1. This is now optional in the new beta2. The tracks region properties has a “show points on parameter track curves” option.

2. Suggestion: Click on a blank spot above or below the curve points you want to edit, and then drag up/down to align your edited curve section with the existing curve.

Viewing 15 posts - 1 through 15 (of 56 total)

1 2 3 4 →

You must be logged in to reply to this topic.