That's correct - two Pds connected with netsend (etc) don't run in sync. They migth drift slowly in time, and if one of them runs late they might get far off sync.
the pd~ object is hard-synced - if one of the Pds runs late the other one waits for it. BUT you can specify the fifo length between them so that one can run ahead of the other by a fixed amount. There should be an option to od~ to allowsofter syncing strategies, but I haven't figured out a good design yet (as with several other things I'm afraid :) M On Mon, Mar 04, 2019 at 07:00:01PM +0100, Peter P. wrote: > * oliver <[email protected]> [2019-03-04 18:19]: > > Peter P. wrote: > > > * michael strohmann <[email protected]> [2019-03-04 16:20]: > > > > is there any contraindication to use separate instances of puredata: > > > > one for audio file playback and the other for control/communication ? > > > There is no contraindication to do so and in fact many of my performance > > > patches are two instances of Pd, one doing DSP the other one doing GUI > > > and both communicating via Netsend/receive. > > > > just out of curiosity: > > > > would that be the same as using a [pd~] (to do the DSP stuff) in an > > otherwise GUI-focused "master-instance" ? > Not an expert on this but I think two separate Pd's are more independent > than one instance with possibly multiple [pd~]. > Someone more expert will comment on this for sure. > > You might be interested in running one instance for Gem and the other > for low-latency audio eventually :) > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
