Sim'n Tonic Forums

I haven't tried yet but I'll soon be connecting the TR1000 with my other studio gear. Anyone here have any success/experience with clocking it with the Nome2, which do you use for master clock etc? From what I'm reading the TR's midi sync is pretty lacking and loose when slaved. I've just been using it as master which has been working fine.

Thanks in advance!

Following this, as I have a Tr-1000 as well.

I would also be curious to know! Let us know if you try )

Interesting fact that the TR-1000 has 2 DIN Sync clock outputs, but the input seems to be MIDI only (the Nome can output a DIN Sync signal - and that works perfectly fine with the 303, 606, etc.)

But let me add that you could get the Nome to follow the TR-1000 from a trigger out (sent regularly every 4th, 8th notes, for example), especially from FW 5.0 (released as alpha for now).

I set up the TR1K with the Nome2 last night and maybe I'm doing something wrong, but I had to adjust the U-sync (with newest version of Ableton, Mac 15.6.1) to -64 samples to get the drum hits (hi hats and kick) to align with the grid.

It's been documented that the TR has 50 ms latency (really bad) when slaved to external sync using what's called "all tracks" mode, and 8 ms latency with in "layered gens" mode (basically layered gens is supposed to have tighter external sync while sacrificing sync of its internal tracks. I have Ableton latency compensation adjusted so that total latency is almost 0.

Any ideas why it would be -64 instead of -50?

Hi Simon, just seeing your message now as I was typing my response.

I would be curious to clock the Nome from the TR if possible. Can I do this with 4.6 or only the alpha 5? If so I would love to test 5 if you could send me the file (I could always revert to 4.6 if needed)

Thanks!

With the U-Sync latency set and the compensation set in Ableton, how is the transport behaving? Is there lag starting, or is your TR and the tracks in ableton just locked now?

sfdjeo wrote: ↑15 Oct 2025, 19:42 I would be curious to clock the Nome from the TR if possible. Can I do this with 4.6 or only the alpha 5? If so I would love to test 5 if you could send me the file (I could always revert to 4.6 if needed)

Awesome that you can try it out
What do you mean "64 samples"? You should not adjust any latency in Ableton, only in the U-SYNC plugin itself, using the "shift" slider, which is milliseconds (ms). For most devices, compensation of zero lands very close to the grid. Sometimes you need something between -10ms and +10ms depending on the machine but also your audio interface.
Based on what you said the TR will need a lot more.

Regarding the alpha firmware, all the info is in the alpha version of the manual on https://download.simntonic.com/docs section 8.3.

wuli wrote: ↑16 Oct 2025, 08:12 With the U-Sync latency set and the compensation set in Ableton, how is the transport behaving? Is there lag starting, or is your TR and the tracks in ableton just locked now?

Once the shift is set then Ableton and TR should be in perfect time with each other. But yes a very large negative value will induce a "delayed" start, i.e. you press the play button and Ableton transport itself starts a few milliseconds after that. It's the only way to go "back in time" Try setting a track delay to -1000ms (on any track in any session) and you will see that the Ableton transport starts about 1 second after you press the button.

Simon wrote: ↑16 Oct 2025, 10:44

wuli wrote: ↑16 Oct 2025, 08:12 With the U-Sync latency set and the compensation set in Ableton, how is the transport behaving? Is there lag starting, or is your TR and the tracks in ableton just locked now?

Once the shift is set then Ableton and TR should be in perfect time with each other. But yes a very large negative value will induce a "delayed" start, i.e. you press the play button and Ableton transport itself starts a few milliseconds after that. It's the only way to go "back in time" Try setting a track delay to -1000ms (on any track in any session) and you will see that the Ableton transport starts about 1 second after you press the button.

What effect does this have on latency internal to Ableton. If the track delay is -1000ms and I play a note on my Push 3 (controlling a VST), is there now -1000ms lag between when I hit the note and when I hear it, or is the -1000ms just effecting the transport?

Sorry to bomb everyone with newb questions... So, an issue I see currently is bpm drift in Ableton when I'm using the TR as a master clock. The Ableton transport fluctuates slightly. Not a huge amount, but generally around .5 to 1bpm. Is this something the Nome with U-sync would do better at as well?

Sorry I meant -64 ms set in the U-Sync plugin... I posted my settings to the elektron board which has a tr1000 user group and I think my mistake was that I had the Ableton buffer set to 256 when it should be 64 or 32 even. I'll go back and change that stuff tomorrow and report back on what the U-sync number is.

Thanks for the response as always! Still curious about clocking the Nome2 from the TR... is that only possible in the alpha 5 Nome2 build, or just better?

btw I only see 4.96 firmware for Nome2 on the downloads page, am I not seeing 5 or is it not posted yet?

sfdjeo wrote: ↑17 Oct 2025, 03:43 Sorry I meant -64 ms set in the U-Sync plugin... I posted my settings to the elektron board which has a tr1000 user group and I think my mistake was that I had the Ableton buffer set to 256 when it should be 64 or 32 even. I'll go back and change that stuff tomorrow and report back on what the U-sync number is.

Buffer size should make zero difference with U-SYNC. And to sync the Nome to the TR you need to send a regular audio signal from the TR.

sfdjeo wrote: ↑17 Oct 2025, 03:43 Still curious about clocking the Nome2 from the TR... is that only possible in the alpha 5 Nome2 build, or just better?

If that signal is at 24ppq, then yes you can do it with FW 4.6 (latest stable), set the "inP" setting to "24P" and send the signal to the "INPUT" plug on the Nome.
If that signal is less (for example 1ppq, i.e. every quarter note), you will need the "1P" value, which is only there from 5.0.

And yes the latest alpha is called "4.97-alpha", that's the one you want.

wuli wrote: ↑16 Oct 2025, 17:21 Sorry to bomb everyone with newb questions... So, an issue I see currently is bpm drift in Ableton when I'm using the TR as a master clock. The Ableton transport fluctuates slightly. Not a huge amount, but generally around .5 to 1bpm. Is this something the Nome with U-sync would do better at as well?

Yes definitely. U-SYNC will lock the Nome and Ableton tightly together, and then the Nome can send a precise and jitter-free clock to the TR. If there is any issue, it's the way the TR follows the MIDI clock (from the Nome or any other clock), which apparently induces a latency as pointed out by sfdjeo.

Send regular audio signal from the TR, meaning not the USB audio I assume? That's what I was doing...

Haven't tested again with lower buffer in Ableton but if you're saying it won't make a difference then I still don't understand why I need to set it to -64 ms in the U-sync plugin, as the TR supposedly is around 50 ms in terms of latency.

Moving some stuff around in my studio but once it's all put back together I'll do some more test and lyk. I'll try the TR as master as well!

Thanks!

wuli wrote: ↑16 Oct 2025, 17:13 What effect does this have on latency internal to Ableton. If the track delay is -1000ms and I play a note on my Push 3 (controlling a VST), is there now -1000ms lag between when I hit the note and when I hear it, or is the -1000ms just effecting the transport?

I'm using the old Midronome plugin which sends pulses to my Midronome (I'm a Windows user, so no u-Sync sadly) and I tested this using a negative track delay of -1000ms. This resulted not only in a shift of the clock, but also latency in the whole project.

However, if you have the option "reduced latency when monitoring" set to ON, you can still play and hear your instruments without the extra latency.

This does come with some tradeoffs though: turning knobs is still affected by the latency. Also, you can get audible clicks when you select different tracks with auto-arm enabled (when you're using a Push or some midi keyboards, or with the setting in options.txt) or just when you switch on/off monitoring while playback is running. Also, it may screw up latency compensation in general, especially when you're using return tracks.

I assume the u-Sync plugin will do the same when setting a high negative delay, but maybe Simon can confirm this?

The upside of using the regular midi sync output of Ableton is that you can set a shift in the clock and if it is a negative one, Ableton will just delay the transport, but not add any latency to the project. Sadly, the Ableton midi clock output is not nearly as tight as that of the Midronome / Nome 2..

MPrinsen wrote: ↑20 Oct 2025, 09:54 I assume the u-Sync plugin will do the same when setting a high negative delay, but maybe Simon can confirm this?

Yes correct

So I've been messing around for hours with this issue and there isn't really a good solution unless I'm missing something. When the TR is what's called "All Tracks" mode (supposedly the tightest internal sync between all the tracks, which would be the preferred setting to use if possible) I set the U-Sync to -50 ms to get it to sync with the the metronome in Ableton and line up on the grid correctly. In "Layered Gens" mode the latency is much less (around -8 ms) but samples are supposedly going to be out of time in that scenario. Haven't done much testing of that, was hoping a clock device could make All Tracks mode usable.

I have the Nome connected via USB to the DAW, then a Midi Solutions Quad Thru with one midi cable going to the TR and one to the MachineDrum, both set to external Midi slave mode.

I'm sequencing two synths from the MachineDrum, and they are much earlier than the TR... probably 50 ms or so. The TR is in time with Ableton but everything else is way off. So I'm back at square one!

I know the Nome can't send shifted clocks from the two different Midi outs (can it?) so I guess I could use the Nome to only clock the TR and then send clock from other midi outs to the other gear, but that defeats the purpose of having a dedicated clock source for everything... Any chance there's a plan in future firmware to be able to shift clock signal from Midi Out 1 and Midi Out 2 for this kind of situation?

What I'm starting to grasp is that the TR just has so much lag that it can't be integrated into a setup as a slave at this point (at least not in All Tracks mode), which Roland suggests in the manual themselves, that being to use it as the master clock. I thought a Nome could get around the latency issue but doesn't seem to be possible while keeping other gear in sync. I'm going to try to slave the Nome to the TR and then Ableton to the Nome but from my experience slaving Ableton to external clock without a clock device constantly updating the sync won't yield good results.

Ok rant over, still wondering if I'm just doing something wrong but I'm pretty sure it's just bad code in the TR that us beta testers have to deal with until they (hopefully) clean up the midi implementation.

Thanks for the feedback. From what I read you are not doing anything wrong, and you're right, this is kinda one of the limits of the Nome's abilities: if you have a device with a huge latency compared to all other machines (50ms in this case), then yes you'll have either that machine or the others in time, but not both.

We are perfectly aware of that limitation and currently developping a solution for it: an add-on module probably. There is no ETA for it though, a wild guess would be early 2026 but nothing is sure at this point. See this topic about it: https://forum.simntonic.com/viewtopic.php?t=207