rjungemann

The last topic I could find related to mine is 5 years old. Is it yet possible to send clock information to a vst~ object for beat-dependent delays, etc.? The vst~ documentation does not say.

vst-clock-sync

You have to include a transport object in your patch, and turn the transport on. That will automagically make your plugins hosted within vst~ sync to the same tempo specified by the transport object.

You have to include a transport object in your patch, and turn the transport on.  That will automagically make your plugins hosted within vst~ sync to the same tempo specified by the transport object.


What about named [transport] object. As I know Max may have more 'timing streams' at once. Is any option to relate timing from named [transport] to particular [vst~] object. 

 in just a patch with unnamed instance of [transport]. Any clues?

What about named [transport] object. As I know Max may have more 'timing streams' at once. Is any option to relate timing from named [transport] to particular [vst~] object. Global transport extra in just a patch with unnamed instance of [transport]. Any clues?


That's an interesting question. It would be cool if [vst~] had an @transport argument.

I don't have access to multiple tempo-sensitive vst plugins now but I guess that [vst~] will not reliably synchronize to any particular [transport] if there's more than one active.

One workaround might be to not use [transport] but instead send MIDI ticks direct into [vst~]. I am also not sure how [vst~] parses time--is it at the standard MIDI 24 ticks/beat or the Max 480 ppq or something else?

The patch here takes a BPM, translates it to MS per tick @ 24 ticks/beat, then sends "248" (the MIDI "tick" 11111000) at that rate. I don't know if that will work though.

That's an interesting question. It would be cool if [vst~] had an @transport argument.
I don't have access to multiple tempo-sensitive vst plugins now but I guess that [vst~] will not reliably synchronize to any particular [transport] if there's more than one active.
One workaround might be to not use [transport] but instead send MIDI ticks direct into [vst~]. I am also not sure how [vst~] parses time--is it at the standard MIDI 24 ticks/beat or the Max 480 ppq or something else?
The patch here takes a BPM, translates it to MS per tick @ 24 ticks/beat, then sends "248" (the MIDI "tick" 11111000) at that rate. I don't know if that will work though.

Oops. put the Real-Time stop message in the wrong place. Should be here:

I've tried this before and the main problem is that [vst~] need 

 arguments. RealTime MIDI Msgs are without arguments. It does not working neither if I send 

 with 2 args (the second 0 or whatever). Timing in [vst~] is a little out of control. The good plugin to test is TAL-FilterII (Togu Audio Line) its envelope driven filter and is free.

Adding @transport to [vst~] will be nice :)

I've tried this before and the main problem is that [vst~] need midievent with at last two arguments. RealTime MIDI Msgs are without arguments. It does not working neither if I send midievent with 2 args (the second 0 or whatever). Timing in [vst~] is a little out of control. The good plugin to test is TAL-FilterII (Togu Audio Line) its envelope driven filter and is free.
Adding @transport to [vst~] will be nice :)


> Timing in [vst~] is a little out of control.

What exactly do you mean, inaccuracy (jitter) or latency?

Neither. Just that I can't use MIDI Real Time messages and rely on 

 transport. I did not tested time synced [vst~] for phase/jitter/latency problems since I'm interested in being "out of sync" :-).

BTW: 32Bit's question about the internal timing resolution of plugin and it's host [vst~] is important too. Does [vst~] take tempo value from [transport] and send it to plugin or just send real time msgs in right intervals?

Neither. Just that I can't use MIDI Real Time messages and rely on global transport. I did not tested time synced [vst~] for phase/jitter/latency problems since I'm interested in being "out of sync" :-).

BTW: 32Bit's question about the internal timing resolution of plugin and it's host [vst~] is important too. Does [vst~] take tempo value from [transport] and send it to plugin or just send real time msgs in right intervals?


I'm trying to use this with Native Instruments Battery but I don't seem to be able to get Battery to see the clock.

I've tried putting a transport in my top level patch and (just in case) I tried putting one in the same patch where the actual vst~ is defined.

I then activated the Global Transport and tried changing the tempo but Battery doesn't seem to be seeing anything.

VST clock sync