I'm trying to create a PD application that'll be sync'ed to jack transport as a sort of master clock.
I found the jack_transport object, loaded it, and it runs. If I bang it regularly with a metro, I can see the current sample in jack transport. So far so good.
My question is about what'd be the most efficient/effective way to sync up a tabplay~ or tabread4~ object to the sample clock in jack transport. So far I've considered the following approaches:
Bang jack_transport with the output of a sig~ or phasor~ object, getting the clock from jack, and use that to hit tabread4~ (I don't know how I'd do this with tabplay~ though, and performance is an issue so if tabplay~ is cheaper I want to use it).
Bang jack_transport with the output of a metro every n milliseconds, and calculate what sample I'm supposed to be at in the tabread4~ or tabplay~ object, and just "re-sync" periodically if they drift. If they aren't ever going to drift (i.e. if PD's internal sample clock is sync'ed to JACK), then perhaps this "resyncing" will only happen at the start of playing, or perhaps I only need to do it then.
Or, maybe, let's say if I have a loop, I just need to bang the tabplay~ whenever the sample clock in jack_transport divided the number of samples in the loop is modulo 0. That'd be simplest and probably cheapest, but I don't know if the clocks will drift. Will they?
I dunno. I'm asking you guys when probably I should be asking the software instead, by just trying it out and determining empirically what works. But before I get too deep into it I'd like to get a second opinion on whether any of the above approaches will work or if there's some other technique I should be looking at. For some reason I suspect that this'll go really easily, but I want to make sure I'm not overlooking anything important.
Thanks.
-ken
Hi Ken.
I haven't used the jack_transport object, and I don't know what its format is; but, assuming you can translate it into audio samples, one very simple way would be:
[bang~] | [jack_transport] | ([expr] or whatever format conversion you need) | [$1 64( | [tabplay~]
If you change [block~] size, then the second number in the message box would have to change too. 64 is the default number of samples per block, and [block~] outputs one bang per block. I don't know if this is necessary or not; perhaps it wouldn't stray anyway. On the other hand it might work better to make the number 72 or something higher than the block size, so you don't have gaps if it does stray...
-Chuckk
On Thu, Apr 10, 2008 at 4:18 AM, Ken Restivo ken@restivo.org wrote:
I'm trying to create a PD application that'll be sync'ed to jack transport as a sort of master clock.
I found the jack_transport object, loaded it, and it runs. If I bang it regularly with a metro, I can see the current sample in jack transport. So far so good.
My question is about what'd be the most efficient/effective way to sync up a tabplay~ or tabread4~ object to the sample clock in jack transport. So far I've considered the following approaches:
Bang jack_transport with the output of a sig~ or phasor~ object, getting the clock from jack, and use that to hit tabread4~ (I don't know how I'd do this with tabplay~ though, and performance is an issue so if tabplay~ is cheaper I want to use it).
Bang jack_transport with the output of a metro every n milliseconds, and calculate what sample I'm supposed to be at in the tabread4~ or tabplay~ object, and just "re-sync" periodically if they drift. If they aren't ever going to drift (i.e. if PD's internal sample clock is sync'ed to JACK), then perhaps this "resyncing" will only happen at the start of playing, or perhaps I only need to do it then.
Or, maybe, let's say if I have a loop, I just need to bang the tabplay~ whenever the sample clock in jack_transport divided the number of samples in the loop is modulo 0. That'd be simplest and probably cheapest, but I don't know if the clocks will drift. Will they?
I dunno. I'm asking you guys when probably I should be asking the software instead, by just trying it out and determining empirically what works. But before I get too deep into it I'd like to get a second opinion on whether any of the above approaches will work or if there's some other technique I should be looking at. For some reason I suspect that this'll go really easily, but I want to make sure I'm not overlooking anything important.
Thanks.
-ken
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Ken Restivo hat gesagt: // Ken Restivo wrote:
I'm trying to create a PD application that'll be sync'ed to jack transport as a sort of master clock.
I found the jack_transport object, loaded it, and it runs. If I bang it regularly with a metro, I can see the current sample in jack transport. So far so good.
My question is about what'd be the most efficient/effective way to sync up a tabplay~ or tabread4~ object to the sample clock in jack transport. So far I've considered the following approaches:
- Bang jack_transport with the output of a sig~ or phasor~ object,
getting the clock from jack, and use that to hit tabread4~ (I don't know how I'd do this with tabplay~ though, and performance is an issue so if tabplay~ is cheaper I want to use it).
If you want to play samples with a different samplerate than the one Pd and jack are using you have to to use tabread4~. tabplay~ doesn't do any interpolation or transposition. I normally never use tabplay~ except for some quick prototyping.
- Bang jack_transport with the output of a metro every n
milliseconds, and calculate what sample I'm supposed to be at in the tabread4~ or tabplay~ object, and just "re-sync" periodically if they drift. If they aren't ever going to drift (i.e. if PD's internal sample clock is sync'ed to JACK), then perhaps this "resyncing" will only happen at the start of playing, or perhaps I only need to do it then.
I've never used jack_transport, but the samplerates of Jack and Pd should never get out of sync unless something really bad happens (xruns etc), and then you have other problems.
However what can get out of sync is the notion of: "What time is it?" Pd itself doesn't have a timeline built in, so how to deal with a global clock very much depends on what your patch looks like.
Example: Jack transport can do a "rewind to the beginning of a piece". A Pd patch however may not have a beginning, it might just run a process which gets modified. What should such a patch do with a "rewind" order?
Assuming you have a Pd patch which has a beginning and which at the beginning plays a sample of 2 seconds length with tabread4~ and vline~. Now jack_transport moves the system to a time 1 second after the start of the piece. Then you either can ignore this and not play the sample at all, or you restart the sample, but with the vline~ at the position it would have 1 second after the beginning. This of course requires a slighty different patching style than if you would just ignore it - as you'd have to patch your sample player in a way that it can always start playing samples at every possible time.
Ciao
Frank Barknecht _ ______footils.org__
-
Chuckk Hubbard -
Frank Barknecht -
Ken Restivo