[PD] A slightly more substantial question

[Chuckk Hubbard]

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 at 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:
>
>  1) 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).
>
>  2) 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.
>
>  3) 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 at iem.at mailing list
>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>



-- 
http://www.badmuthahubbard.com