[Solved] Midronome not following DAW tempo w/ U-SYNC

[victorcampos]

[SOLVED - the issue was from another software interfering with the U-SYNC Daemon, SoundSource from Rogue Amoeba]
-------


Hey, all!

I have had my Midronome since one of the first batches, was using the old U-SYNC VST (think it was a beta version) w/ firmware 2.9 perfectly in sync, and noticed my Midronome at some point in the past weeks/month had stopped following tempo changes from my DAW.

I just updated both the Midronome to 3.0 as the U-SYNC VST to the latest version (1.0.0) but I still am not being able to make the Midronome follow a tempo change from the DAW, U-SYNC shows the "U-SYNC" light green, and the "Locked" orange but with my DAW set to 135 BPM the Midronome is stuck at 133 BPM which I set it manually to and the "Locked" light on the device is off.

Am I missing something? Some weeks ago it seemed to be working as intended, only noticed this now when I changed to a new project using a different tempo and noticed my recordings getting out of sync with the grid which made me realise the Midronome was stuck with the old BPM setting.

Rather odd it just stopped following my DAW, I hadn't changed any sync configuration in there

Edit:

My setup

• MacBook Pro M3 Pro 32 GiB
  macOS Sonoma 14.6.1
  Bitwig 5.2.4
  Midronome U-SYNC 1.0.0

[Simon]

Hi Victor - thanks for writing here

This does sound strange indeed. Are you sure you uninstalled the beta version correctly, including the Daemon? Using the beta daemon with the 1.0 VST would in fact give those kind of weird behaviors. The Locked LED on the plugin should always match the Locked LED on the device.
I'll suggest you uninstall and delete everything called Midronome or U-SYNC on your machine, then make a clean install and see if it helps.

If not, no worries, we can investigate - then it's probably a config issue somewhere

Simon

[victorcampos]

Hey, Simon!

Thanks for the quick reply

I had at first tried to install the latest .pkg before removal but then noticed I had duplicated daemons and VST since the names didn't match exactly and the installation didn't replace them, after noticing that I removed everything Midronome-related before re-installing the latest version, including the daemon but if possible validate if the steps are correct:

1. Remove "Midronome Daemon.app" from /Applications (I have the impression the old daemon was under /Applications/Midronome but nonetheless I removed everything I could find through "Finder" and on the terminal by running a "sudo find -i midronome* /"
2. Remove "Midronome.vst3" from /Library/Audio/Plug-Ins/VST3"
3. Install the .pkg for U-SYNC + Daemon
4. Start the daemon
5. Connect the Midronome via USB
6. Add the Midronome U-SYNC VST to my DAW

On the daemon it shows both "Midronome: connected" and "Plugin: connected" when my DAW is open with the plugin. The orange indicator in the VST turns on when I press Play but the Midronome device never gets the orange LED lit up.

Also, in my DAW I have the sync connections to send Play/Stop + MIDI clock to the Midronome "MIDI Commands" input, without that setting I don't get the Midronome to start/stop when playing from the DAW.

I've also just updated my macOS to 14.7 as a sanity check but after updating + restart it still isn't syncing.

I'm a software engineer so let me know if there is any more advanced troubleshooting I could do in case it's not something trivial.

I find it rather odd it has stopped working even with the old plugin + daemon, I had it running well since the beta came out to the point where I didn't even check the Midronome anymore for the "Locked" LED lit up, can't tell the exact timeline when it stopped working, only noticed it recently when working in multiple projects and realising some recorded stems sounded out of sync with my hardware

[victorcampos]

I noticed there's an audio device called "Midronome-do-not-use" on Audio MIDI Setup.app, coincidentally I have started getting corrupted audio recorded back from my Analog Heat which I always use to record the stereo output from my whole setup (the Analog Heat is last in the chain as an insert on my mixer's main outs).

Not entirely sure if it's related but just leaving another clue in case it's something to do with my USB audio setup, currently it is setup as an aggregate device with:
1. XONE 96 mixer
2. Analog Heat MKII
3. Expert Sleepers ES-9

They are combined to in an aggregate device so I can output CV and audio through the ES-9 from the DAW, record back all of my mixers channels, and record the main stereo out from the Analog Heat.

[Simon]

Ok, interesting!

Then I'd say there is nothing wrong with the installation, that part seems checked.

Clearly the problem is the communication between the Daemon and the Midronome, since the Daemon says it can find the Midronome, it probably "thinks" it is sending data to it but my guess is the data never reaches the actual hardware, or get scrambled up.
That data does go through this "Midronome-do-not-use" interface. If you send any other audio to that interface that would definitely mess things up.

Another point: we have not tested U-SYNC with aggregated audio devices. But I assume it would work fine, and I guess it worked before, with the aggregated devices.

A few ideas you could try:
* Try to select just one interface in Bitwig
* Create a new DAW session without anything, just the U-SYNC plugin
* Try to change the sample rate
* Try to disconnect everything on your USB ports except the Midronome

If any of these work, just add back one thing at a time and see at which point it breaks.

Let me know how it goes

Cheers
Simon

[victorcampos]

I did some tests and so far no success :/

Connected only the Midronome to the computer, no other USB devices connected, sound output set to my computer's speakers.

Tested through my desk's Thunderbolt dock (Belkin Thunderbolt 3 Dock Pro), a portable adapter (Satechi Type-C w/ HDMI + Ethernet), and a simple Apple USB-C to USB-A adapter.

In all cases the pattern repeats: U-SYNC shows a Locked orange icon while the Midronome never gets the Locked LED lit up.

Changed the sample rate from 44,1kHz to 48kHz on each device, so 6 tests in total.

Is there anything else I could do? Any setting I should double-check on the Midronome itself that I might have missed? I doubt it since I haven't touched the device since setting up with the beta VST + firmware 2.9.0 but might be a good sanity check

Or if there's any other debugging I could enable, grab logs from Console.app, a debugging sound I could play through the Midronome's "sound card" to check if it can turn on the "Locked" LED, etc.

[Simon]

I haven't touched the device since setting up with the beta VST + firmware 2.9.0 but might be a good sanity check

Well the FW should definitely be updated to 3.0 but you said you did that already? You'll need the Firmware Updater software + the FW 3.0 file - see https://simntonic.com/support/

Changed the sample rate from 44,1kHz to 48kHz on each device, so 6 tests in total.

What devices? I meant simply change the sample rate in your DAW (which would usually update automatically the sample rate in your audio interface)

Did you try a clean DAW session? And if you have another DAW installed on your machine maybe you could try that as well?


If none of this works there is not much you can investigate, the next step would be for me to make you a custom U-SYNC Daemon that will print a log so we can have a look at what's happening. But hopefully it does not come to that and there is something obvious that we missed.

[Simon]

Actually - just one simple test: on the device, press the "SETUP" button and the Locked LED should blink slowly
If this works at least we know the Locked LED does work and has not died or something.

[victorcampos]

I haven't touched the device since setting up with the beta VST + firmware 2.9.0 but might be a good sanity check

Well the FW should definitely be updated to 3.0 but you said you did that already? You'll need the Firmware Updater software + the FW 3.0 file - see https://simntonic.com/support/

Sorry, I think I was unclear: I have updated it to 3.0 and before that I had it running on 2.9.0 with the beta VST which worked, it stopped working while still on the 2.9.0 + beta VST which made me update to 3.0 + U-SYNC VST 1.0.0 to check if that would solve the issue, after some attempts to troubleshoot I created the post here.

Changed the sample rate from 44,1kHz to 48kHz on each device, so 6 tests in total.

What devices? I meant simply change the sample rate in your DAW (which would usually update automatically the sample rate in your audio interface)

I changed the sample rate both on the DAW as well as the setting for the "Midronome-do-not-use" device in "Audio MIDI Setup.app" manually to test every combination possible.

Did you try a clean DAW session? And if you have another DAW installed on your machine maybe you could try that as well?

Yup, tried it with a clean session, only 1 track with the U-SYNC VST in it.

I will give it a try on Ableton Live since I also have it installed

Actually - just one simple test: on the device, press the "SETUP" button and the Locked LED should blink slowly
If this works at least we know the Locked LED does work and has not died or something.

While in "Setup" mode the "Locked" LED on the device blinks so the light itself is working!

I also want to try it with another Mac to check if it could be something in my macOS audio setup which could be creating issues, right now most of my friends who own a Mac are traveling, as soon as I get access to one I will give it spin.

[Simon]

Alright very strange, never seen an issue like this except during conflicts after upgrading from beta to final 1.0 - but then a cleanup always solved it.
Sorry you have to experience this, but I am sure we will get to the bottom of it!

I changed the sample rate both on the DAW as well as the setting for the "Midronome-do-not-use" device in "Audio MIDI Setup.app" manually to test every combination possible.

I see. I don't think it would make any damage, but you should not touch the "do-not-use" device at all. Just let it be. Ideally I would want it completely hidden but that was not possible - we might make it this way in a future implementation of U-SYNC but this is still a work in progress (and related to the Windows U-SYNC actually).

Let me know how it goes with Ableton, and please keep an eye on the Daemon status - does it say "Midronome connected" all the time?

Simon

[victorcampos]

Reporting back here with findings!

Over the weekend I got another MacBook which isn't used at all for audio-related tasks (so as fresh as an audio stack can get ), I installed only Ableton Live on it, the Midronome Daemon, and the U-SYNC VST.

The Midronome worked flawlessly, start/stop, following the tempo, etc.

I then started to fiddle a bit with other audio stuff that aren't VSTs I have installed on my computer, I went through some things I have running all the time on my computer: "Rewind" from MonkeyC Audio, "Overbridge" from Elektron, which I didn't believe could be causing the issue but since it does communicate audio in some other way from Elektron machines I thought it was a sensible one to try at first, and... The culprit: SoundSource from Rogue Amoeba.

Somehow the Audio Routing Kit from Rogue Amoeba is causing issues for my computer to communicate with the Midronome, before ARK they used to have another component called "ACE" (Audio Capture Engine) which used to be a Core Audio driver. I don't know the specifics of how ARK does it magic since it's not a system extension, somehow it's an always listening capture device that routes the audio from sources I select to different outputs.

Since I don't need SoundSource running when making music it's a simple fix to simply close the app.

Just wanted to let you know in case someone else with a similar weird audio setup such as I have encounters some issue not sure if there's anything you could do from the Daemon side to avoid this, ARK is proprietary so pretty hard to look the innards of what it's actually doing to my audio stack.

[Simon]

Hi Victor!
Well that's amazing news, thanks for sharing, that will definitely be useful for anyone who has the issue

As to why this is happening, well the only way another software can interfere with U-SYNC is by sending some audio to the "Midronome-do-not-use" audio interface. Maybe that software somehow had the wrong interface selected?

Simon

[victorcampos]

As to why this is happening, well the only way another software can interfere with U-SYNC is by sending some audio to the "Midronome-do-not-use" audio interface. Maybe that software somehow had the wrong interface selected?

I checked all the settings and it wasn't routing any audio to the "Midronome-do-not-use" interface, my best educated guess would be there's some mechanism for its routing to work which sets itself between macOS's audio output and the interfaces, probably adding some "passthrough" interfaces (so the application can capture all sounds and re-route them) which should be 100% transparent but in practice is interfering with the Daemon's output.

I will report it to Rogue Amoeba, might be useful for them to know this edge case.

Anyway, thanks a lot for the support, I love the Nome!

Cheers from up here in Sweden