Automation / Editing Bug

MattiasNYC · November 30, 2022, 7:23pm

I’ll try to track this down later. This is a brand new take on what I have suspected to be a problem for a while - sometimes when editing automation parameters won’t follow correctly or logically. This however is very different from what I’ve seen before:

Each instance of Frequency has a default dialog preset applied in my templates where all parameters of that preset have been written as automation, so the default behavior when I open a new project using a template is that if I grab any of the parameters and move it the parameter will snap back to the preset levels when I release, because of the automation. And the preset has gain all at unity, with frequency and Q set normally, spread out over the range.

If you look at the values you can see that all of them are as low as is possible, with band 8 also turned off. Obviously this is not a setting I would ever get to in normal operation. Instead I’ve now seen this twice in one project as a result of only moving an event from one track to another. The automation seems to be written in and I can’t even undo it.

It should also be obvious how dangerous this bug is. If I get a note to change something at only one place on the timeline it is possible that an events track change could cause it get those settings, and if I don’t play back over that spot I won’t know since there are no visual indicators that something changed without opening the plugin.

This is really worrisome.

Nuendo 12.0.51 - build 391
Other specs in sig.

Has anyone seen this???

MattiasNYC · November 30, 2022, 7:25pm

I’ve seen similar things happen with on/off or bypass automation as well as with sends.

MattiasNYC · January 31, 2023, 2:32pm

I’m bumping my own topic. Here’s a new error I just ran into. I’ve had a suspicion that something isn’t right with how automation is punched from the preview buffer under certain conditions which I have yet to find.

As you can see there’s a loop selected for the second event. I went into preview and punch to loop and selected bypass on the plugin. I then punched to loop and as you can see in the first event automation was punched there as well:

Anyone?

MattiasNYC · January 31, 2023, 2:51pm

Ok, I think I found a repro of this and I guess this is a design choice by the programmers. I think I hate it but it’s for a separate thread.

allklier · January 31, 2023, 3:39pm

Trying to follow the description. When you punched to loop on the second event, was your playhead sitting on the first event, where it also punched in just the area that was played between hitting bypass and hitting punch?

I rely on preview loop and punch a lot. But every once in a while I’ve found myself not having hit ‘p’ to update the loop and suddenly automation is written somewhere else and then I have to undo that. It’s a great way of working, but has a few trap doors.

Also at times I trip over hitting punch, but playback isn’t stopped yet and then it doesn’t write until you stop playback. Or one of the area selects getting stuck in locked. There are a few ways to get a surprise automation result. You kind of have to sanity check it every time.

Lately I’ve taken more to locking ‘To Punch’ or ‘Loop’ and then just writing automation that way for the many simple things, skipping preview. And using preview only if I need to dial in EQ or reverb on a shorter event. It avoids some of these issues and actually ends up faster.

MattiasNYC · January 31, 2023, 7:47pm

The difference is when you press punch if you’re outside of the loop range when playing back. In other words, if you are outside of the range and make a change that ends up in the preview buffer.

The preview buffer is actually not written to automation lanes until playback is stopped.

If you’re playing however then if you hit “punch” it sort of ‘leaves’ preview mode and therefore the parameter you touched ends up being written wherever you are on the timeline (while still playing), I suppose because the parameter itself isn’t ‘released’ from the state you put it in when you touched it until playback stops.

Then when you stop automation is written to loop.

I was in the process of writing a new thread so here’s what I wrote so far for repro:

A:

set loop range to later in the timeline (in my case second event in picture)
set auto to preview and fill to loop
press play
press bypass on plugin
5. stop playback
6. execute the punch to loop

result: loop range gets automation correctly

B:

set loop range to later in the timeline (in my case second event in picture)
set auto to preview and fill to loop
press play
press bypass on plugin
5. execute the punch to loop
6. stop playback

result:
1: automation now writing in “latch” under playback location until stop!
2: automation correctly written to loop range once playback stops

If the parameter was “released” or “returned” to it’s previous written value wherever you are when playing back once you press “punch” then this wouldn’t happen, then, to me, it would be more intuitive.

allklier · February 1, 2023, 12:08am

Yes, know exactly what you found…

I understand why punch doesn’t stop playback, because there are good reasons to punch out and keep playing. I use that when I use the ‘to punch’ w/o preview.

That said, I think when you use ‘preview’ the behavior of punch should change and stop playback. That would mean you’re committing the preview, and would then also make sure that all automation is written right upon ‘punch preview’. That way we could avoid the somewhat obscure ‘releasing’ of the parameter.

The one corner case to look at: What if you setup a loop, but your playhead isn’t inside the loop at all (e.g. you set range manually w/o playhead position, or you set range and then moved playhead). Now if you preview it would set values that aren’t even in the range that you’ll eventually write. Should a preview in loop mode (or other modes) not pickup any value changes that occur outside of the preview range? Or is there a valid use case, where you would preview a setting in location A, but then write those into a totally separate region B?

To me the purpose of preview is to test and then write. What happens if you punch out of preview without stopping playback, and then change parameters further? Does it write the value at the end of playback or the value at punch? It just gets muddy pretty fast.

If you want to dial in values to test and then keep playback, I think you should just write with ‘to punch’ locked keep dialing in your values, then punch out and playback continues and it writes your final values between the punch in and the punch out. Clean and simple.

MattiasNYC · February 1, 2023, 1:15am

I didn’t mean that it should stop playback.

Anything that’s touched when in “preview” should go into the buffer, and all of that should be written when “punch” is activated, and it should “fill” “to loop” if that’s set. If the parameter is touched outside of the loop doesn’t matter in my opinion.

Really the actual issue is what happens when punch is pressed as far as the touched parameters are concerned. All I’m saying is that it would be intuitive to me that once I’m pressing “punch” I’m telling the software “I’m done previewing and the changes I’ve made I want to be written according to what I selected”.

Imagine that you have your loop, you’re working quickly, you have parameters touched and set the way you want, you disengage the actual loop function while it’s still playing and pass the loop ‘end’ point and press “punch” after few seconds without stopping playback - then you get the behavior I mentioned. You get what’s in my picture but with the loop to the left and the ‘extra’ immediately to the right of it.

To me that’s not an entirely unlikely scenario when working quickly. And I don’t think it’s intuitive necessarily. I mean, I understand the logic in that I pressed a parameter, so it’s “engaged”, but I think I’d prefer it if it “disengaged” when I press “punch”, rather than having to wait for playback to stop. Or at least have an option for it.

If you punch out of preview and have automation set so that the functions deselect when you punch out then any new automation should be written where you are on the timeline. So unless “to loop” is “locked” as a fill function automation should write where you are, and when you are there.

allklier · February 1, 2023, 3:02am

I looked through the manual to get a sense of how it’s meant to work. Here are some relevant points, which may be insightful but not entirely conclusive:

When you are happy with the values found, click Punch to start the new automation pass.
The new value setting is recorded from the point where you punched in to your punch out
position as defined by the automation mode setting.

Notable that punch out (regardless of playback status) starts a new automation pass. That would support what you said, that the buffer of the preview should be taken as is at punch out and committed, regardless of what happens between punch out and playback stop.

Touch the required parameter, start playback, find the value, and activate Punch to start the
new automation pass.

Another reference to a ‘new automation pass’

The current automation pass punches out as soon as one of the following conditions is fulfilled,
independent of which automation mode is selected:
[…]
● The project cursor reaches the right locator in Cycle mode.

Passing the right cycle marker should trigger a punch out. Presumably not so if cycle gets disabled.

Auto Punch allows you to begin and end the automation pass at defined positions.
● Activate Preview mode and set the left and right locators at the positions where you want to
automatically punch in and out.
Auto Punch allows you to set up a safe zone for previously written automation data.
● Place the right locator at the beginning of an area that you want to protect and enable cycle
mode.
This ensures that a running automation pass always punches out before reaching this
section of your project.

Seems to indicate that punch out is guaranteed regardless of cycle mode.

All these combined indicate that through various events coming out of preview a new automation pass gets started and the buffer values should be committed.

It feels like a bug that these values aren’t written upon punch out, but only after playback stop. Either way a new automation pass should have been started, and the bypass value in your example would have had to be re-touched in order to be included in the new pass (or as you indicated should have been released/returned to existing values rather than previewed values).

Maybe worth filing a support case to get this looked at.

Maybe the intended behavior that is consistent with all of the above is that upon punch-out (even when still in playback mode), the buffered new automation should be written immediately, a new automation pass is created that continues until playback is stopped, and is entirely independent of what happened during preview, including all parameters to be re-touched to be written as part of the new pass.