Syncing Rack 2 in a Daw (Reason 11 for example)

Great stuff. I was missing the ‘P24’ setting and couldn’t work out why it wasn’t synching. All fixed. I can carry on now. Thanks. J

1 Like

Excellent tip. Thank you!

Hey! is it possible with the free version as well? Thanks

Is there any way that Clocked could realize that it’s in this situation and an least show a warning? This question is asked so often…

VCV free version doesn‘t run as VST inside your DAW; nevertheless you can still sinc it via midi or audio in standalone mode.

Cheers, dDom

Yes - you would need some method of generating an audio clock pulse in the DAW (such as the Silent Way Sync plugin) and a way of sending audio back and forth between your DAW and Rack. It’s a bit of a PITA but it can be done. Rack Pro makes all this much simpler.

It can also be done with midi but due to jitter the sync is not very tight.

After chatting with Steve about the idea, we decided it could actually just automatically switch to P24 if, when in BPM CV mode it detects two rapid pulses on the BPM input. This can be tested, if you (or anyone that builds plugins) can pull Impromptu and try this latest version, any testing will be much appreciated! If this works well, it will definitely reduce the number of times newer users get stuck on this :slight_smile:

5 Likes

With the latest commit Marc has made, if you just connect the CLK out from Midi > CV to the BPM input of Clocked, it will detect the fact it is receiving a clock pulse rather than BPM CV and will change mode automatically to P24 - which should hopefully put an end to most of the “how do I sync the Rack VST” issues. Now it should ‘just work’.

To be clear, this automatic change to P24 will only happen when the module detects clock pulses at the BPM input when it is in the default BPM CV mode. If the mode has already been changed to another P value like P12 for example, no change will happen.

It seems to behave well with my initial testing but given how widely used this module is we could definitely do with some more testers throwing it some curve balls to see if there are any potential issues before releasing it.

6 Likes

Nice!

1 Like

Thank you for the change!

1 Like

Awesome to about recent update.

Related question, what’s the best way to fix the sync issue when a sequence starts up? I use Impromptu Clocked as primary but whenever a sequence starts, the first three notes or so are out of sync. You can hear this if you are clocking VST FX using Host. But after this, the sync is fine.

I think one trick might be to just temporarily expose Clocked to the correct external clock before you start the performance, such that it learns the intended BPM, and then when you restart it, it will assume the same BPM until the next pulses arrive, so in theory that should help.

1 Like

FX with a sync input take some time of their own to figure out the tempo - and given the clock you are sending them is often just 1ppqn, they will take significantly longer to figure out the correct tempo than Clocked does with a 24ppqn input. This is because tempo is calculated by measuring the time between pulses - the lower the ppqn, the fewer pulses there are (for a given time) and the longer it will therefore take to calculate the tempo.

Also, unlike Clocked, those FX may not ‘remember’ the previous tempo when you stop then run again.

1 Like

This is of course why in the (now ancient) MIDI spec the clock ran all the time, and did not shut off when a device “stopped”. In these VST applications is it also easy to accomplish this, or does it need to be done as a kind of “hack” by the user?

Unrelated - can you “tell” Clocked what the expected tempo is to it can start immediately, and stay in sync if, in fact, the MIDI clock tempo is close to the one you tell Clocked?

Unrelated - have you ever used the “nord” protocol for reset, as an alternative to the “send it at the same time as the clock but ignore clocks for a millisecond afterwards” protocol? In my (unreleased) Arpeggiator I gave a choice of both, but the default was the Nord reset, since that protocol (to me) is unambiguous and always works.

It would be great it you (or someone) would write up a guide to syncing in VST, since there is so much confusion about this. I’d even say that VCV should link to such an article, but afaik they never link to external info.

Also, glad you got some thanks for the change,

1 Like

Yes, and this is what I meant by just temporarily running clocked at the BPM we want it to start with, so that it can be primed with that BPM. Then when you start it again, it will implicitly use this BPM until it can establish the new BPM (and if the new one is the same as the old BPM, then it should potentially sync faster)

No, since I didn’t get the impression that this protocol was popular in Rack. In know Antonio offered the Nord reset option also, but with the lack of a general concensus on this approach, I went with the 1ms-ignore approah and that eventually made it into the second paragraph of this section (after having discussed it with Andrew in that infamous issue 938 in the Rack github issues):

And another related link w.r.t. the 1ms thing:

Agreed, but seeing how often the P24 thing comes up all the while the Clocked manual available literally two clicks away (in the right-click menu), with a dedicated section on external sync, I’m not too motivated to write about this since I doubt it would be read much. I think Omri and Latif’s existing youtube videos on the topic are probably the best for this.

1 Like

Another option would be a host sync module that is always listening to Host BPM, similar to what’s mentioned above. There is a module like this in miRack and Clocked slaves to BPM without delay there and I haven’t encountered a similar sync issue. It’s not super intrusive issue but would be great to have perfect sync in the VST mode.

I mentioned somewhere else that this would be the best option for syncing frame-perfectly to the host, since the host typically already has a timeline with all the time / sync related details and gives it to plugins, they can just make use of it.

on the plugin version/variant I made this was one of the very first things to do. It just makes sense (to me at least) to grab the info from the host.

As extra, this also allows smooth ramps for beat phase and bar phase, in case you want a signal to be modulated by how far the timeline is on the current beat or bar. In theory it might even be possible for some plugin formats and DAWs to have a full-song ramp phase too, but I did not try this yet.

The timer shows song time in 1st row, bar-beat-tick in 2nd row, so it is easier to understand what is going on in the module

1 Like

Yes, exactly. I was going to mention Cardinal as well. Would you consider porting this to VCV?

core modules cannot be ported. besides this info is only available when Rack runs in plugin form on a host, which means Rack Pro, and that one is not opensource and possible for us to change.

1 Like

Got it, that makes sense. Hopefully, something that will get considered for VCV.