[PD] Scheduling events, libpd, and sequencing

[Frank Barknecht]

On Tue, Feb 15, 2011 at 05:56:36PM -0500, Peter Kirn wrote:
> The notion is that the language side of things - Java, C++,
> Objective-C, Python, whatever -- will have the logic that determines
> how events are scheduled, and would handle user input that might alter
> the sequence of those events. The question is how best to have the
> *language* communicate with Pd.
> 
> So, the structure would be:
> external logic > message to Pd >  qlist/textfile scheduling inside Pd
> > sound source in Pd > audio callback in the embedded instance

As you probably know, in RjDj/libpd the usual way to communicate between the
App and the Pd instance is to send messages between both via some kind of
socket (network or RPC or so). The main issue is one of synchronizing different
"clocks": Pd has a clock inside, usually synchronized with the soundcard (which
may be a virtual "dummy" card in libpd), but events from the App may not be
synchronized to that, but instead to some GUI loop, network polling mechanism etc. 

A GUI event may happen at a certain time compared to the GUI loop clock, but
what would be the time, it should happen in Pd's "soundcard clock"? You have to
find a some mechanism to reliably compare the different clocks, then it's easy
to translate times between both time scales.

OSC with timetags would provide a way out, but even if the OSC overhead seems
to be too much (which I doubt), you still need some kind of timetag for messages.

> We'd continue to use libpd, but rather than assuming the Pd patch
> contains logic for how the events are scheduled, those would be
> integrated with the logic and interface contained in the code. (So, on
> iOS, for instance, in Objective-C or something.)

Actually I think, Pd is great for scheduling (musical) events, so I'd not put
that into the interface code. The Pd side is probably, where the musicians and
composers work and they are the ones who need to deal with sequences, timing,
rhythms etc. 

I'd figure that most graphical interfaces don't need such a tight subsample
timing as Pd can provide, the eye is much less timing sensible than the ear.

It becomes slightly different when you deal with inputs, for example tapping in
Tap-Tap-style games where timing and latency become more important. Any midi
capable realtime audio software has to synchronize external midi events to
their own, much faster clocks, so these apps may be worth a look (or Pd's midi
objects).

Ciao
-- 
 Frank Barknecht            Do You RjDj.me?          _ ______footils.org__