[2.0.28] Events placed in first bars/beats of the Automation Track

Hi team,

the Automation Track is expected to be active and therefore to automate even when a Song is not playing and you simply move in the timeline using the various possible methods.

This condition seems to be perfectly respected except when you move to position 0001.1.1: in this case, in fact, if an event is expected at that position, that event seems to be simply ignored if the track is not playing.

To verify the issue use the simple project

FirstMeasureOnAutomationTrack.vlprj (9.8 KB)

and follow the steps:

  1. Go to Song 1, then to position 0003.1.1 in the timeline
  2. The status of the Song1 mixer channel is with Mute enabled as correctly indicated in the Automation Track
  3. Go to position 0001.1.1 in the timeline
  4. The status of the Song1 mixer channel is still with Mute enabled, differently from what is indicated in the Automation Track
  5. If the Song is played at this point, the Mute of the Song1 mixer channel will be immediately and correctly disabled

As mentioned at the beginning of this post, the software seems to ignore events placed in the Automation Track at position 0001.1.1 and this has a significant negative impact when the Song is initially loaded.

Waiting for your feedback.

Thanks for the support.

… sorry for being late. The *.vlproj is not enough. Can you please create an archive? Use the “Menu / File / Save Archive…” function and story it to an empty folder. Zip it and drop it here.

Thank you,
Michael.

Hi @Spork,

below what was requested:

FirstMeasureOnAutomationTrack.zip (10.2 KB)

Thanks for the support for this bug that I believe, as stated in the original post, is particularly important because it determines the initial condition of what is automated immediately after loading Song.

Waiting for your feedback. :blush:

… sorry for our delay here. We are on it.
Michael.

1 Like

Hi @Spork,

thanks for the update, I’m eagerly awaiting the fix for this issue! :blush:

Hi @Spork,

unfortunately the issue seems to still be present even in the new version 2.1.1.

Just as a reminder, I don’t know if the issue is so difficult to solve that it will still take time to be fixed or it’s just a matter of priority.

I await your kind feedback. :blush:

Thank you.

Hi @Spork,

far be it from me to question the priorities that the team has set for itself, but just to understand: does the theme of this topic involve particularly complex changes to apply or is it considered (unlike what I may believe) not a particularly high priority?

I apologize for the question, but, as I was saying, just to understand the state of things :blush:

… thank you for the reminder. It’s fixed now. Please re-try it with the next version,
Michael.

1 Like

Hi @Spork,

I’m happy to confirm that the issue that is the subject of this post has been fixed with the 2.1.4 release. :slightly_smiling_face:

As always, thanks for the support! :blush: