[3.0.44/2.2.120] Incorrectly saved triggers and FlexLoop issue

VST Live
1

Hi team,

when saving and reopening projects, I noticed that triggers aren’t always restored to the exact position they were saved in.

The issue seems to be somehow related to Tempo scaling, meaning that the issue occurs for some Tempo values, while others don’t.

I extracted a piece of my project, based on a single tempo of 91 BPM 4/4, preserving the structure of the Parts but reducing the tracks to just the Tempo track and an Audio track.

Before saving and reopening the project, the triggers appear correctly:

image
image302×820 28.1 KB

Once the project is saved, when reopening it, I get:

image
image299×820 28.3 KB

With these “altered” triggers, I also occasionally notice a malfunction of the FlexLoop.

In these cases, in fact, when using FlexLoop, a completely audible silence sometimes occurs when the beginning of the loop is played again.

Referring to the project:

TriggerOnTempo.zip (972.6 KB)

the issue occurs, I repeat occasionally, on FlexLoop at measure 0088.1.1 (the beginning of Outro B - FlexLoop) after a first or even several correctly executed loops.

I hope I’ve provided all the information necessary to resolve the issue.

Looking forward to your feedback, thank you.

2

Can you try this? - when open project, do Preload operation. Can set “On” for Always preload. Make changes to your triggers, save and reopen, then write here if it did make any difference.

3

Hi @ArthurNeeman,

I followed exactly the steps you suggested:

  1. Opening the project
  2. Preloading with Always preload enabled
  3. Editing the triggers with the correct values
  4. Saving the project
  5. Reopening the project (with Preload performed automatically)

The triggers are again incorrectly displayed and the random FlexLoop issue (audible silence at the beginning of Outro B - FlexLoop) still occurred.

In short, applying the procedure you indicated doesn’t seem to have changed the software’s behavior.

Looking forward to further feedback, thanks.

4

We are looking into this, it’s a rounding error (4.1.1 becomes 3.4.4).

The loop is running for 10 minutes now w/o ever “missing a beat” (3.0.44). Also retriggered and restarted several times.

What else can we do to reproduce it?

5

…we did find something…see Missing audio at beginning of Cycle/Flex Loop - #12 by musicullum

6

If you manually jump to another Part with FlexLoops, it could create a “hiccup” (or short silence, “missing a beat”), that will be fixed with the next version.

7

Great, thank you @musicullum.

With my small sample project, it doesn’t do much.

Usually, I open the project and go to the beginning of the audio click (at position 0084.1.1.000), then press play and, after two or three loops, at position 0088.1.1.000 (the beginning of Outro B - FlexLoop), I experience a silence of about a second.

Below is a video demonstrating what I just described:

The silence in the audio is audible at second 33 of the video.

Looking forward to further feedback, thanks.

8

Great, I’m waiting for the new version, I’ll check it out and let you know the results.

Thanks as always for all your hard work! :blush:

9

Hi @musicullum,

just to clarify that the issue related to the rounding error (for example, 0004.1.1 becomes 0003.4.4) is still present in version 3.0.45.

Regarding the FlexLoop issue, I haven’t been able to reproduce the issue on version 3.0.45, but I’m waiting for the new version of VL 2 to perform a new test.

10

… it has been fixed and pushed to the next Pre-Release 3.0.46.

See you,
Michael.

11

Thanks @Spork for the good news. :slightly_smiling_face:

I’d like to ask you for one more question, if you can: will VL 2 be fixed with less frequent updates than VL 3 or will it no longer be updated? :thinking:

Thanks again for all the support. :blush:

12

Please see here:

Spork:

… there are currently no plans to continue the weekly VST Live 2 Pre-Releases.

13

Thank you @Kai_Schwirzke! :blush:

14

Hi @Spork,

I tested release 3.0.46, but even with my test project provided at the beginning of this topic, the incorrectly rounded triggers issue still appears to be present. :roll_eyes:

Looking forward to further feedback, thanks.

15

You are correct, we’re checking again.

16

Thank you. @musicullum.

Despite a resolved issue Trigger/Duration Display wrong reported in the history, which had given me hope, release 3.0.47 is also affected by the issue related to the correct storage/display of trigger values.

Hopeful for the next release. :blush:

17

… you are right, it’s still not tight enough. Another improvement has been added to 3.0.48,
Michael.

18

I’m happy to report that, with version 3.0.48, the issue appears to be definitively resolved.

As always, thanks for all your hard work! :blush: