Make automation read back to the last automation's clip last value

[unfa]

In Ardour, no matter where you play your track, it's always updating all automated values according to what was the last value in the automation track.

I know Ardour doens't use "clips" and each track has only one assigned parameter, but I think this still could be implemented in LMMS, to some nice effect, and less work needed for extending the clips manually just to get a consistent output.

(Real Life) Example:

My track has a HighPass filter on the Master bus.
In the very beginning the filter is automated to sweep from 500 Hz to 0 Hz.
If you however play the begginning of the track (and the filter's knob is set to 500 Hz) and jump to the middle of the track (a few bars after the automation clip ends), the filter won't update to the last value of automation clip, it'll stay where the pleayhead has last read.

I'd like LMMS' automation to "look back" to the last value of the previeos clip, avery time the playhad is manually moved by the user, this way the automated values would be in sync to what you'd get when you render the track from start to finish.

[mikobuntu]

this is especially annoying when you have a peak controller set on a track, until it is triggered later in the track it always will for example if you are using a kick to trigger a ducking of a fader knob in the mixer for another track/sample etc, the fader knob will always be at 0%

thanks Mikobuntu ;)

[diizy]

On 04/30/2014 04:31 PM, unfa wrote:

In Ardour, no matter where you play your track, it's always updating
all automated values according to what was the last value in the
automation track.

I know Ardour doens't use "clips" and each track has only one assigned
parameter, but I think this still could be implemented in LMMS, to
some nice effect, and less work needed for extending the clips
manually just to get a consistent output.

(Real Life) Example:

My track has a HighPass filter on the Master bus.
In the very beginning the filter is automated to sweep from 500 Hz to
0 Hz.
If you however play the begginning of the track (and the filter's knob
is set to 500 Hz) and jump to the middle of the track (a few bars
after the automation clip ends), the filter won't update to the last
value of automation clip, it'll stay where the pleayhead has last read.

I'd like LMMS' automation to "look back" to the last value of the
previeos clip, avery time the playhad is manually moved by the user,
this way the automated values would be in sync to what you'd get when
you render the track from start to finish.

This might be something that would be possible to implement once the
mechanism for reading the global value of a model by miditime is in
place. After all we need similar functionality to be able to keep track
of tempo reliably, so why not use it for other automations as well.

[mikobuntu]

I should maybe elaborate more on my example...
A prime example of what happens (1) i have a synth playing for 16bars on FX mixer channel 2, on the 17th bar in fx mixer channel 1, i have a kicker instrument and in its fx i have peak controller. both synth and kicker are playin now from bar 17 until bar 32...So now the peak controller is set that each time a kick triggers , the synths on channel 2 will have its FX mixers fader lower volume from 100% to 0%, bars 1 through to end of 32 are in a loop now.this will play fine as long as i am in this session i can loop continuously.Ok now i close and reopen my project, the loop maker obviously defaults to bar 1 ( start of song ),but i look at my FX mixer channel 2 fader and it will be set to 0% and this makes the synth silent until it gets triggered at bar 17 again by the kick.expected behaviour is that the FX mixer channel 2 starts at 100% or whatever max value i have set in my song

thanks Mikobuntu ;)

Reply to this email directly or view it on GitHub.

[unfa]

On 30 Apr 2014 15:50, "Vesa V" [email protected] wrote:

On 04/30/2014 04:31 PM, unfa wrote:

In Ardour, no matter where you play your track, it's always updating
all automated values according to what was the last value in the
automation track.

I know Ardour doens't use "clips" and each track has only one assigned
parameter, but I think this still could be implemented in LMMS, to
some nice effect, and less work needed for extending the clips
manually just to get a consistent output.

(Real Life) Example:

My track has a HighPass filter on the Master bus.
In the very beginning the filter is automated to sweep from 500 Hz to
0 Hz.
If you however play the begginning of the track (and the filter's knob
is set to 500 Hz) and jump to the middle of the track (a few bars
after the automation clip ends), the filter won't update to the last
value of automation clip, it'll stay where the pleayhead has last read.

I'd like LMMS' automation to "look back" to the last value of the
previeos clip, avery time the playhad is manually moved by the user,
this way the automated values would be in sync to what you'd get when
you render the track from start to finish.

This might be something that would be possible to implement once the
mechanism for reading the global value of a model by miditime is in
place. After all we need similar functionality to be able to keep track
of tempo reliably, so why not use it for other automations as well.
Sounds promising :)

—
Reply to this email directly or view it on GitHub.

[musikBear]

Good idea! -would it be even better if the automation value was 'pickable' form any auto-clip.
This would work just as 'last-note' behavior, and hence intuitive. -eg
find the auto-clip you want to 'extend-from'
left-click it once -> 'last-value' kept in a var
move to spot where you like to continue
create auto-clip
This new clip is initiated with the 'last-value' read from the var
This behavior would let the user mess around with other auto-clips, before he continue the 'flow', and also still alows for the other behavior
In the same task -Perhaps re-instate the quite usefull feature from <0.9 where a dragged knobs set value automatically was set in the new auto-clip? I liked that quite a lot, and it was serious usefull for setting max-levels in automation.

[diizy]

On 04/30/2014 06:00 PM, musikBear wrote:

In the same task -Perhaps re-instate the quite usefull feature from
<0.9 where a dragged knobs set value automatically was set in the new
auto-clip? I liked that quite a lot, and it was serious usefull for
setting max-levels in automation.

That feature should still be there.

[Sti2nd]

This feature is just the same as actually dragging out the automation track. If the knob is set to another value, it will automatically jump to the last automation value before play head, but we haven't talked about how the user can see that this is what happens?
I propose to automatically drag automation tracks until the next automation tracks,. Or make some kind of graphical horizontal line (until next automation track) which is drawn from the last point in the previous automation track.

[musikBear]

diizy

That feature should still be there.

• the feature is not in win32 any more. Any diel dragged in, will set the value to maximum -eg 1. point in the auto-track is in its logical maximum posistion. Raise new ticket?

Sit2nd

Or make some kind of graphical horizontal line (until next automation track) which is drawn from the last point in the previous automation track.

do you mean like http://snag.gy/4Q4sd.jpg
i dumped 2 'unrelated' auto-tracks in between the 'related' (those that should merge in value) ones. I did that because i have seen persons that uses one auto-track for one -instrument-. eg more than one controller could be in the -same- track :/ -i dont like that idea, but its used..
I fear that having 'line-links' like that could be quite confusing (even drawn nicely..)
But -Is it nessesary at all to -alert- the user about the 'relatedness' of the clips? Why is that needed? I think of this feture more like a neat way to be able to continue one value directly over in a new clip -A tool! -not a logical thing.

[unfa]

On 30 Apr 2014 20:15, "Vesa V" [email protected] wrote:

On 04/30/2014 06:00 PM, musikBear wrote:

In the same task -Perhaps re-instate the quite usefull feature from
<0.9 where a dragged knobs set value automatically was set in the new
auto-clip? I liked that quite a lot, and it was serious usefull for
setting max-levels in automation.

That feature should still be there.
It is! I'm using it all the time
Very handy.

—
Reply to this email directly or view it on GitHub.

[Sti2nd]

@musikBear The feature is there for all of us. What version of LMMS or Windows are you on?

Well, a hidden logic is not very user friendly, so I would say yes, it is needed. And auto expand automation tracks to the next couldn't be that hard to implement? If there is an automation track to the right, expand until the start point of the next automation.

[diizy]

On 05/03/2014 02:44 AM, Stian Jørgensrud wrote:

And auto expand automation tracks to the next couldn't be that hard
to implement? If there is an automation track to the right, expand
until the start point of the next automation.

Somewhat problematic, because our automation tracks are "generic", ie.
you can have any automations of any controls on the same track. So it
may necessarily not make sense, conceptually, to extend the tracks to
the next one. What if the next pattern is for a different control? Then
you'd have sort of like inconsistent behaviour.

If we had controls assigned per-track instead of per-pattern, it would
make sense, but as it is now, doesn't really make sense to auto-extend...

[Sti2nd]

@diizy If it doesn't make sense to auto extend this whole enhancement doesn't make sense, as auto extend is just a way to graphically show the logic this feature will implement.

[diizy]

On 05/03/2014 02:57 AM, Stian Jørgensrud wrote:

@diizy https:/diizy If it doesn't make sense to auto
extend this whole enhancement doesn't make sense, as auto extend is
just a way to graphically show the logic this feature will implement.

Not really. The value of a control at any given time still exists,
whether there is automation for that control at that time or not.

It helps if you think of the value of any control as, instead of a
single value, a one-dimensional vector that extends accross the
timeline. At any given time, we can sample that vector and get a value.
Automation patterns can be sprinkled accross that vector, and they're
subsets (or sub-vectors) of the full vector, which each define a piece
of the full vector, or, the set of values at that particular stretch of
time.

However there's a bit of a conceptual mismatch between this and the way
our UI for automations currently works. Since we allow patterns to be
mixed-and-matched accross any automation track, that means that the
automation tracks themselves are not tied to any control, rather they're
just containers for the patterns. So the actual automation track for a
given control is actually invisible to the user, except for the visible
parts, which are the patterns.

So again, autoextending the patterns is problematic, because there may
be patterns for other controls in the way. Will the extension overlap
with them, or simply dodge them and continue on the other side? But the
other pattern would also have their extension. Then the extensions
overlap... and where will it end? We don't have a clearly defined
song-end point, so they'd have to extend ad-infinitum...

But that doesn't mean that we can't extend them "in spirit", in that
invisible, conceptual automation track which exists for each control. It
makes sense there, because that's how they behave anyway, if you play
the song from start to finish. So in that sense this change would only
bring consistency in how the automation works, the value of the
automation or control at any given time would be reliable and constant,
no matter if you play from the start or jump to the spot from somewhere
else (past/future). There would be true state-awareness, which could
only be a good thing.

Now if you want to argue that we should instead of the current
automation system have one automation-track per control, then that's a
whole other discussion with its own set of problems to figure out...

[Sti2nd]

I think I got it. Two knobs are connected to one automation pattern in automation track 1. Then bars after that pattern one of the knobs is connected to another pattern in auto track 2. The logic will let the visible pattern in automation track 2 override. If the pattern in the first automation track had been extended it would be hard to figure out what of the two patterns would override the other.

And the logic is preserved as you say Vesa, it will be like playing from start to beginning.

[diizy]

On 05/03/2014 03:45 AM, Stian Jørgensrud wrote:

I think I got it. Two knobs are connected to one automation pattern in
automation track 1. Then bars after that pattern one of the knobs is
connected to another pattern in auto track 2. The logic will let the
visible pattern in automation track 2 override. If the pattern in the
first automation track had been extended it would be hard to figure
out what of the two patterns would override the other.

Well yeah, that's another thing...

And if that isn't enough, here's yet another thing: if patterns are
autoextended, then what happens if I want to cut a pattern short? Now I
can just drag the right edge of the pattern to resize the automation
pattern, and leave the unwanted part of it out - but if they're
autoextended, the right edge goes always to the next pattern, and I'll
be forced to edit the pattern in the automation editor, causing more work...

And the logic is preserved as you say Vesa, it will be like playing
from start to beginning.

Yep. That's the idea...

[unfa]

On 3 May 2014 01:49, "Vesa V" [email protected] wrote:

On 05/03/2014 02:44 AM, Stian Jørgensrud wrote:

And auto expand automation tracks to the next couldn't be that hard
to implement? If there is an automation track to the right, expand
until the start point of the next automation.

Somewhat problematic, because our automation tracks are "generic", ie.
you can have any automations of any controls on the same track. So it
may necessarily not make sense, conceptually, to extend the tracks to
the next one. What if the next pattern is for a different control? Then
you'd have sort of like inconsistent behaviour.

If we had controls assigned per-track instead of per-pattern, it would
make sense, but as it is now, doesn't really make sense to auto-extend...

This is true. Maybe the "silent lookback" tactic using a global per-control
automation map would be better. It would just give consistent results, with
no extra visual changes or requiring any user attention.

—
Reply to this email directly or view it on GitHub.

[tresf]

If I'm reading this correctly, this is really a 2.0 type initiative which be changed by certain design decisions. Bumping to 1.3 milestone for now. Will likely bump again as this is isn't an easy fix.

[lukas-w]

Fixed: #3382