mattias petersson

I want to sync a patch that uses the transport system to a friends computer. He is running an OSC-based sequencer that he wrote. Previously we've used a signal based solution where he was sending me a phasor ramp via SPDIF. That worked fine, but now i'm making more and more transport-based patches.

So what do you think would be the best way to do this? Should he send ticks for the transports right inlet? Or is network sync to unstable? Or keep the phasor and let me convert it to ticks on my side?

And what about MIDI beat clock? Could we send that to the transport directly? Or do we have to use rtin or something still? It would be nice if one could select "MIDI" as a clocksource for a transport. Could we?

I want to sync a patch that uses the transport system to a friends computer. He is running an OSC-based sequencer that he wrote. Previously we've used a signal based solution where he was sending me a phasor ramp via SPDIF. That worked fine, but now i'm making more and more transport-based patches.
So what do you think would be the best way to do this? Should he send ticks for the transports right inlet? Or is network sync to unstable? Or keep the phasor and let me convert it to ticks on my side?

And what about MIDI beat clock? Could we send that to the transport directly? Or do we have to use rtin or something still? It would be nice if one could select "MIDI" as a clocksource for a transport. Could we?


syncing-transport-from-outside-world

So, this one week total silence means that no one ever wanted to synchronize a Max transport object with something else? :)

I'm not sure if a MIDI beat clock receiver exists already somewhere but you could try to implement it yourself. The basics are quite simple.

From [rtin] you get the following bytes/numbers:

The sender delivers 24 ticks per beat. So you can measure the time interval T of arriving ticks using [timer] and calculate the BPM tempo from it.

BPM = 60000/(24*T), with T in milliseconds.

Yes, thank you! I actually tried this technique already, but i am not really satisfied with the timing. And this system will drift a lot. Not very groovy.. ;)

Before the transport system i used to do everything with signal objects. Then it's easy to switch to a phasor~ coming from another computer via SPDIF. I guess this is still the only way if you want decent timing.

Too bad because i think transport is really good if you don't have to sync it to something else though. It would be really nice with some more sync options for us who don't use Live or Rewire.

But is it possible to have the transport in a "passive" mode where you can drive it with the tick value only? I tried this, but since it seems impossible to set the tempo to 0, this conflicts with the incoming ticks. Or maybe i'm doing something wrong? I would like it to be started, but not running. Something like this:

Yes, thank you! I actually tried this technique already, but i am not really satisfied with the timing. And this system will drift a lot. Not very groovy.. ;)
Before the transport system i used to do everything with signal objects. Then it's easy to switch to a phasor~ coming from another computer via SPDIF. I guess this is still the only way if you want decent timing.
Too bad because i think transport is really good if you don't have to sync it to something else though. It would be really nice with some more sync options for us who don't use Live or Rewire.

But is it possible to have the transport in a "passive" mode where you can drive it with the tick value only? I tried this, but since it seems impossible to set the tempo to 0, this conflicts with the incoming ticks. Or maybe i'm doing something wrong? I would like it to be started, but not running. Something like this:


I've been wondering for a while about slaving transport to an MSP master of some sort, your patch and question prompted this response:

not a whole lot of use as it is, but the idea is to let transport know what tempo we are at (in this patch it's more the other way round), and then let transport run on its own with just occasional updates from the phasor~ side (once per bar in this patch) - or something like that . . . this is just a quick sketch, and I'm not sure if it will ever be of any use to you, or me, or any one

this actually seems pretty decent here just trying with a trigged cycle~/line~ combo. probably better not to update snapshot~ too often. thanks!

one question about your use of the delta~ before the 

this actually seems pretty decent here just trying with a trigged cycle~/line~ combo. probably better not to update snapshot~ too often. thanks!
one question about your use of the delta~ before the 


to get the bang at the start, not the middle, of the phase loop.

https://cycling74.com/forums/master-transport-to-phasors-or-master-phasor-to-rates-for-global-clock

 ) has brought to my attention that phasor~ now has a lock attribute which might be useful for many things in this area. I think it's time to go through all the help patches of the objects I use again - so many hidden gems to find!

also, cudnylon (in https://cycling74.com/forums/master-transport-to-phasors-or-master-phasor-to-rates-for-global-clock ) has brought to my attention that phasor~ now has a lock attribute which might be useful for many things in this area. I think it's time to go through all the help patches of the objects I use again - so many hidden gems to find!


yes, i too discover new hidden attributes all the time.. part of the fun i guess. good to know about the lock attribute to phasor~.

about the delta~ thing: actually the bang will happen at the start of the loop with both solutions since egde~ triggers only on the zero to non zero transition. see proof below.

syncing transport from outside world