Automation not read (FIXED)

[Gass n Klang]

Hey guys,
I found the following problem:

1) Create a track
2) Show panning automation (should be buggy with every other parameter, too)
3) Set two automation points: One at lets say exactly 5.1.00 with point shape "Square" and another automation point at exactly 5.1.00
4) If there is a playback running, stop it
5) Jump exactly to 5.1.00: the automation will not be read, just a short time after the automation point

In mixing audio this is not relevant at all, since the you won't recognize that problem (automation is read right after the point)

But I want to use reaper for as a live mixer and create markerpoints with different automation setups to recall by jumping through some markers. So I have to set all markers a little bit behind the automation points.

Would be really nice to have the automation read exactly at the point where it's written.

PS: I'm in the "read" automation mode

[DarkStar]

Seems OK here (using AlphaCM as the sound source) and recording the output.

Can you attach a test project that shows the problem?

[Gass n Klang]

here it is. Jump to marker 3 (Pre-Chorus). Channel 2 should panned center and Channel 1 30% right but both values stay where they were in the previous song part.
Jump to Marker 4 (Chorus) and values change to what I expected before loading marker 3.


This is for live FOH sound as I said. I just need the automation-information at marker position to be able to jump to the differend sound settings.

[DarkStar]

That was saved with the cursor at Marker 3 so I changed it to Marker 5, saved it and re-opened it. Pressing 3 to go to marker 3 changed the pans exactly as expected.

So it seems OK here.

[Gass n Klang]

mh I tried it again: Wierd! The TCP shows the automation, but the MCP does not! And the audio stream(that project is just an excerpt of the original project where these channels are receive channels) behaves as the MCP shows.

[DarkStar]

OK I now see that the pan controls in the MCP sometimes do not change.

Jumping backwards and forwards between markers 3 and 4 is OK
Jumping backwards and forwards between markers 3 and 5 is not

[Gass n Klang]

no, its the other way round: 3 to 4 is not ok. track 1: On marker 3 it should be +30%, on 4 center. Jumping to 5 it shows center.
So the automation is read just direct BEFORE the marker but not on marker position!

Please guys, solve that bug. It's really essential for my needs! I'm still using the evaluation license to check out if everything works as I want it to. So if you want me to buy reaper, please make that possible. I first need to program a whole song and do a check in a rehearsal before I can say that reaper is the software to go for live FOH sound!

[DarkStar]

?

[Gass n Klang]

yeah just have a look at Track "1". the automation point shows 30% R and so does the TCP but MCP says "center".

Track 2 should be "center" as TCP shows, but MCP says 30% R.

TCP is right!

[Gass n Klang]

I just joined this forum. How do we recognize if the REAPER team did read that?

[DarkStar]

We live in hope.

As this thread is posted in the Bug Reports forum they almost certainly have. But that does not say anything about the fix date.

[Gass n Klang]

hey devs. would be very nice to have this fixed!

[Dstruct]

Confirmed (5.18 x64).

FIXED (5.20pre34)

[Justin]

This is a little tricky, because in the project:

The marker #3 is stored as: "MARKER 3 30.96774193548387".
The automation change at the relevant time is stored with reduced precision (unfortunately) as "PT 30.96774194", which is rounded to *after* the marker position. I'll see if we can add some epsilon check to this, but it's always difficult to know what will break when doing these things. If you can move the marker *slightly* later that'd be a good workaround...

[Gass n Klang]

Hi Justin, many thanks for your reply. This at least is an explanation what's of going on there. I don't understand exactly, why moving the marker would help. I think I snapped it right to the bar. So my problem is not to jump to the bar and getting wrong automation data but to jump to the marker and not getting the right ones. I don't think this will change by moving the marker.

The idea behind: I use markers to store automated settings for live-use. I jump to those markers to load the settings. At the moment as a workaround I created custom actions to jump to the marker and one bar further so everything is loaded. Now I want to do some changes in my system so that this workaround won't work any longer and the topic gets relevant again. So I'd be glad if there was an option.

[Justin]

I've got a possible fix coming soon.

[DarkStar]

Originally Posted by Justin

This is a little tricky, because in the project:

The marker #3 is stored as: "MARKER 3 30.96774193548387".
The automation change at the relevant time is stored with reduced precision (unfortunately) as "PT 30.96774194", which is rounded to *after* the marker position. I'll see if we can add some epsilon check to this, but it's always difficult to know what will break when doing these things. If you can move the marker *slightly* later that'd be a good workaround...

Just wonderin' - how much precision is needed? Wouldn't 8 digits be sufficient for both markers and env points and ...?

[Gass n Klang]

Originally Posted by Justin

I've got a possible fix coming soon.

perfect, you're the man!

[Gass n Klang]

Well, I'm sorry but it's not fixed completely (5.20 beta 1)

Just open the project. There is a noise generator to send signal from ch1 to ch2. In bar 1 the send is muted, so no audio is sent to ch2. jump to measure 2, the mixer will now show that the send isn't muted any longer (fixed! previous versions haven't shown that) but no audio will arrive ch2!
Audio will be sent as soon as about 2.1.0097 is reached.

[Justin]

Originally Posted by Gass n Klang

Well, I'm sorry but it's not fixed completely (5.20 beta 1)

Just open the project. There is a noise generator to send signal from ch1 to ch2. In bar 1 the send is muted, so no audio is sent to ch2. jump to measure 2, the mixer will now show that the send isn't muted any longer (fixed! previous versions haven't shown that) but no audio will arrive ch2!
Audio will be sent as soon as about 2.1.0097 is reached.

Ah, only for mute envelopes right? I see why.

[Gass n Klang]

yes, it seems so. If I find another buggy parameter I'll post it here.