U-SYNC - Strange behavior when using 1024 or 2048 buffer

Report any bug you find here!
Topics ar marked as: [R]=Rejected, [A]=Approved, [WIP]=Work in Progress, [F]=Fixed
Post Reply
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

Issue taken from this post: https://www.facebook.com/groups/simnton ... 0385753676

Setup: Ableton Live 12.1 on MacOS BigSur 11.7.10

Steps to Reproduce: set buffer size to 1024 or 2048 on Ableton and try syncing with U-SYNC

Expected Behavior: start/stop is working fine and no unexpected resets

Actual Behavior: stop does not stop, clock and devices keep running

Nome generation (I or II) and Firmware version: Midronome (Nome I), FW 4.0
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

As written on the FB post, I could not reproduce this at all.

Waiting for get more info from Nektarios.
nektarios
Posts: 8
Joined: 01 Dec 2023, 23:38

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by nektarios »

Hi Simon, hope you're enjoying SB2025.

I bet you're busy so take your time answering.

Things have gotten even weirder. My Midronome does not respond to the audio click from the old VST3 Midronome plug in.
I made sure the audio cable that I use to connect my UAD Apollo's individual Audio output, is working by plugging it in to an external mixer and listening to the pulses firing away. So there is audio going down the cable, but my Midronome does not want to listen to it.

Tried both balanced and unbalanced cables, no joy.

I have resorted to using U-Sync again.

I am currently working in Reaper.
Pre roll of 1 measure needs to be enabled otherwise measure 1 on the DAW is 1 Bar late on the Octatrack
Measure 1 on my DAW is step 1 on my Octatrack with a SHIFT parameter of 90msec on the U-Sync plug in.

But the problem is that U-Sync is generally loose timing....it drifts, especially upon reaching the end of a 16 bar loop point and going back to the bar 1 of the loop. So its annoying to have go and correct the timing of recordings where Midronome was drifting for about of 4 beats and then it was syncing up properly again.
I just want to use the old Midronome VST3i again to be honest but that is not triggering my Midronome any more.

Any suggestions, please send them my way.

Enjoy Berlin!
nektarios
Posts: 8
Joined: 01 Dec 2023, 23:38

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by nektarios »

Updated my MacOS to 14.7.5
Same problems.
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

nektarios wrote: 10 May 2025, 16:06 Any suggestions, please send them my way.

Enjoy Berlin!
Hi Nektarios

I am on the way back from Berlin - Superbooth was really awesome, met lots of people and did really good networking - great stuff coming in the future that's for sure!

Sorry to hear about all of this. The issue with the older plugin is even stranger, especially since it was working before.
Would you be willing to do a video call so we can investigate this together?

If not, no worries, here are my thoughts about the Midronome plugin:
  1. Try flipping the phase Ø of the audio output (using a plugin in the DAW right after the Midronome plugin for example)
  2. Try increasing the audio volume
  3. On the Nome, make sure "inP" is set to "24P"
  4. Test if the hardware is actually damaged by plugging something else in the INPUT plug, either a pedal or a drum pad if you have one
Regarding the issues wiht U-SYNC, this is a bit more intricate. A delay of 90ms sounds pretty excessive (I assume it's minus 90ms), why do you need such a large delay? The plugin is designed to give you "almost" on the grid when the setting is at zero, but depending on your audio interface you usually have to adjust by +/- 10ms.
Do you have any other DAW you can test with?

Drifting with U-SYNC is close to impossible, even after 3 hours of recording it should be exactly where it started. So something must be interfering with U-SYNC, my guess is that the "Do-not-use" audio interface (used by U-SYNC) is receiving some audio data from another software on your Mac somehow. Maybe overbridge or ACE/SoundSource?

As I said I'm happy to investigate all of this with you over a video call, otherwise feel free to try by yourself!

Simon
nektarios
Posts: 8
Joined: 01 Dec 2023, 23:38

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by nektarios »

Hi Simon,

I am happy to do a call but let me go over things again tomorrow with a bit less frustration than yesterday…which led me to also update in the end and everything (regarding my Mac and plug ins, not Midronome) worked, so something good came out of all this nightmare. I am positive a solution will present it self.

I’ll post back here,

Cheers!
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

nektarios wrote: 11 May 2025, 14:51 Hi Simon,

I am happy to do a call but let me go over things again tomorrow with a bit less frustration than yesterday…which led me to also update in the end and everything (regarding my Mac and plug ins, not Midronome) worked, so something good came out of all this nightmare. I am positive a solution will present it self.

I’ll post back here,

Cheers!
No worries at all - let me know :)
And if you haven't already, please make sure you upgrade your Midronome's bootloader before you upgrade to MacOS 15 Sequoia ;)

Simon
nektarios
Posts: 8
Joined: 01 Dec 2023, 23:38

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by nektarios »

After a quick fiddle last night, Ableton seems to be working just fine, not drifting on loop points or in general. I didn't have time to test this on a 100+ channel project where things usually start getting messy, but on a 40 channel project, it was fine with this setting. This was on a 1024 buffer setting.
Note: the plug in in Ableton has the extra parameter for plug ins that exceed the 20msec latency. This does not exist in the GUI when I open the VST3 in Reaper
Screenshot 2025-05-11 at 23.13.40.png


The problem with Reaper is that the plug in needs about 90msec of +ve (yes positive) offset for the Octatrack to line up with the first beat of the first measure. I am using a pre roll of 1 measure because otherwise Midronome will send another reset message to the Octatrack at measure 2, so the Octatrack will be 1 measure late, with regards to Reaper. Timing is still loose in Reaper...not just at loop points but at random place. The timing was similarly loose at 128, 256, 512, 1024 and 2048 buffer sizes.

Mind you this was a project with 121 channels so the same might happen with Ableton Live. Something I will test when I have some free time.
Screenshot 2025-05-11 at 23.02.55.png
All of the above is with U-Sync and no plug ins that add latency above 20ms, as the old Midronome plug in, although it sends the audio pulses down the audio output, the Midronome hardware is unable to listen (24P selected as input mode). I messed with phase reverse, different output levels but no joy.
The "INPUT" on the hardware Midronome is working as I managed to clock it with a eurorack LFO pulse (PED/P.E.D. as input mode), so it ain't the hardware.

The good news that Ableton Live seems to be working. Now Reaper is the thing I need to sort out, but ideally I want the old Midronome plug in to work...I wish I never messed with it in the first place to be honest.

P.S. I won't update to Sequoia. Sonoma seems to work so I will stay with that for as long as possible.
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

Ok interesting progress - thanks for the info! :)

If you see any issues in Ableton with a large session I would love to look at this with you.
Yes the extra setting in Ableton is normal, Ableton is the only DAW that required extra compensation when using plugins with large latencies. Other DAWs including Reaper do not have that problem, no matter what plugins you use (as long as you have plugin delay compensation enabled).
nektarios wrote: 12 May 2025, 11:05 The problem with Reaper is that the plug in needs about 90msec of +ve (yes positive) offset for the Octatrack to line up with the first beat of the first measure. I am using a pre roll of 1 measure because otherwise Midronome will send another reset message to the Octatrack at measure 2, so the Octatrack will be 1 measure late, with regards to Reaper. Timing is still loose in Reaper...not just at loop points but at random place. The timing was similarly loose at 128, 256, 512, 1024 and 2048 buffer sizes.
That is very strange and nothing I have seen before. But Reaper is not massively used so there could be a setting or peculiarity that we missed somewhere. The Nome will only send a restart/reset at Measure 2 if it "missed" the beginning of measure 1. Have you tried in a clean Reaper session?

nektarios wrote: 12 May 2025, 11:05 as the old Midronome plug in, although it sends the audio pulses down the audio output, the Midronome hardware is unable to listen (24P selected as input mode). I messed with phase reverse, different output levels but no joy.
The "INPUT" on the hardware Midronome is working as I managed to clock it with a eurorack LFO pulse (PED/P.E.D. as input mode), so it ain't the hardware.
Unlike the U-Sync stuff this should be easy to solve, and I'm pretty confident if we can have a call we will sort it out easily.

Simon
nektarios
Posts: 8
Joined: 01 Dec 2023, 23:38

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by nektarios »

Simon wrote: 12 May 2025, 15:09
nektarios wrote: 12 May 2025, 11:05 The problem with Reaper is that the plug in needs about 90msec of +ve (yes positive) offset for the Octatrack to line up with the first beat of the first measure. I am using a pre roll of 1 measure because otherwise Midronome will send another reset message to the Octatrack at measure 2, so the Octatrack will be 1 measure late, with regards to Reaper. Timing is still loose in Reaper...not just at loop points but at random place. The timing was similarly loose at 128, 256, 512, 1024 and 2048 buffer sizes.
That is very strange and nothing I have seen before. But Reaper is not massively used so there could be a setting or peculiarity that we missed somewhere. The Nome will only send a restart/reset at Measure 2 if it "missed" the beginning of measure 1. Have you tried in a clean Reaper session?
Just tried my clean template and disabling the pre roll of 1 measure, lines up fine with the Octatrack. So on a clean project, pressing transport Start on Reaper and having 0 pre roll, so instant play (like Ableton Live) and everything lines up just fine. But on my previous 120+ channel project, pre roll needs to be enabled....don't know what the channel "threshold" count, is before pre roll needs to be enabled.

I still need the 90ms of positive "Shift" for the Octatrack to line up with the DAW though.
Simon
Posts: 1145
Joined: 09 Jan 2022, 22:08

Re: U-SYNC - Strange behavior when using 1024 or 2048 buffer

Post by Simon »

Ok interesting! We'll do some more testing of heavy Reaper sessions and let you know.

It could also be the Reaper pre-roll - have you tried disabling it on your 120+ channel project?
Post Reply