I think this is actually intended behaviour. I was also confused as i didn’t remember if they are synced to the pattern (somewhat free running) or triggered by the notes.
Turns out, retriggered by the notes is the correct behaviour.
Went all the way back to the OG Tracker Firmware 1.2.2 to verify this.
Thanks. Actually none of my tracks that contain lfo like filter, pan and tune are working anymore. I assume that’s the case for other users as well.
So whatever happend to the lfo code, at least for the last 2 years it behaved differently than this beta. Means, if it was a bug introduced years ago, you now have to make it optional, otherwise you will break 100s of songs.
And to add, you take away lot of functionality. For every effect you will now have to sacrifice an effect slot with exact postion, before that you let just run the lfos. Also means, many patterns are not possible anymore. 2 effect slots but 5 lfo.
Then we mean different things. I am not the only one, at least 3 mentioned a different behaviour here and on discord.
I will close it for now because everything works as expected. You all seem to have tested it and came to the conclusion its the same as before in this beta.
Not tested, but in the instrument settings Lfo works per sequence, not per note. So Lfo 64 pans twice per 128 steps. Changes on a step basis also panned from that point till next pan command. I use a lot of lfo panning.
2 tracks, 2 instruments, each using their unique Square LFO for Volume.
Both set at 4 steps.
LFO Test 2:
Single pattern, 64 steps
3 tracks, 3 instruments, each using their unique Square LFO for Volume.
Set at 4, 8 and 12 steps.
Then i tested and recorded the results starting with
Firmware 1.8.0 up to the current 1.9.2 beta.
Below you find the results:
LFO Test 1
1.8.0
1.9.0
1.9.1
1.9.2 beta
LFO Test 2
1.8.0
1.9.0
1.9.1
1.9.2 beta
Am i doing something wrong? Does anyone have a clear example they can share that highlights the issue? Ideally please share a stripped down / bare minimum project that highlights the problem.
If anyone needs older firmware to tests against, let me know i’ll happily provide it.
But based on these examples, it seems that the LFOs have always reset when a new note is triggered, even way back in 1.8.0.
UPDATE:
Turns out because i tested only with volume LFO i wasn’t able to reproduce correctly.
Please disregard everything i said above
Is there any reason why you completely ignored my initial bug report? 1.2.0 1480b PT+, should also be the same for PT OG but i am not here for regression tests on all devices.
Then, i gave detailed reproduction steps. Well, nevermind, here’s a video. Use headphones to hear the stereo panning.
Enough waste of time. As there are no other complaints and posts are deleted, feel free to close this as resolved.
Daddy chill. No need to get all passive aggressive. I‘m just tryin‘ to help here.
The main reason i was testing on the OG was purely because this current „fix“ happened because of an older issue that this was supposed to fix.
But you are right, i should have taken your reproduction steps into account.
I didn‘t because i was asked to have a look at all of this half way through and didn‘t pay attention to what has already happened. Mea culpa.
I‘ll have another go with your example / steps tomorrow. I don‘t doubt the issues you are seeing. It‘s just always good to have that double confirmation
Just for clarity, the reason I deleted my post that I initially made because I saw that the firmware posted was not the same as mine because I use a mini. My plan was to submit a new bug report (or at least on this thread) for the 2.2 beta, but time is limited so I can only do so much to prepare a project for testing. I am currently not using this beta because I am experiencing the same issue that’s been posted here.
This is also occuring in the most recent Tracker Mini 2.2.0.1480b firmware. When compared to the latest stable firmware (2.1.0), the lfos restart on a per note basis and not per sequence, as mentioned earlier in this thread. The expected behavior, as 2.1.0 currently functions, is that the lfos modulate per sequence according to the speed set in the 2nd page of Instrument Automation.
In these examples, I have set instrument 1 to modulate its panning using a Triangle LFO, set at 32 steps, with the amount set to 100. The track is 32 steps, with each note occuring every 4 steps. The expected behavior is that with each note that passes, it’s placement in the stereo field will shift until beginning the cycle again at the start of each sequence.
Here is an example of this behavior using the stable 2.1.0 firmware:
Here is the exact same project, but with the 2.2.0.1480b firmware:
Notice that the panning does not change in the 2nd example. This is not the expected behavior that previous stable firmwares set precedent for, and can ruin songs made by users who rely heavily of lfo modulation .
Here is the project I used to create these clips if anyone would like to check it out for themselves:
Just reporting back and documenting all my findings as i went on a bit of a archeological dig .
I made sure to test all the automation destinations and noting their behaviours.
Because yes, i think that caused a lot of the confusion (for me and others).
In 1.6.0:
Volume, Wavetable Position → LFO appear to always reset on note
Cutoff, Panning, Finetune, Granular Position → LFO appears to reset on playback (semi free-running), does NOT reset on note.
Up until 1.9.1:
This behavour is the same
Tested 1.7.2, 1.8.0, 1.9.0 and 1.9.1
In the 1.9.2 beta:
All the automations are reset on note.
So yes, @Patrick is absolutely right. There is a slight in this beta i would say .
@dorofeev.eu mentioned that the volume LFO isn’t working correctly. But based on the Volume LFO behaviour, it would turn out that it was correct in the first place.
So on that part the reset on each note in 1.9.1 is correct.
Agreed. This definitely messes up a few projects where I depended on the lfo running the length of the pattern. I have to jump down firmwares to export them the way I remember them. Annoying!!
No need to get all passive aggressive. I‘m just tryin‘ to help here. 
.
in this beta i would say 