Re: [PD] Scheduling events, libpd, and sequencing
Hi Peter, On 15 Feb 2011, at 22:56, 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 Can't the caller just communicate with Pd by passing messages through the libPd API? I thought the whole point of libPd was that you have your code and Pd's code running in the same process, with a lightweight wrapper in between, so there should be virtually zero latency in passing messages from your code to a running Pd. Certainly it shouldn't require timestamping to de-jitter. Or maybe I'm missing the point of your question... Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
On Wed, Feb 16, 2011 at 5:23 AM, Jamie Bullock ja...@postlude.co.uk wrote: Can't the caller just communicate with Pd by passing messages through the libPd API? I thought the whole point of libPd was that you have your code and Pd's code running in the same process, with a lightweight wrapper in between, so there should be virtually zero latency in passing messages from your code to a running Pd. Certainly it shouldn't require timestamping to de-jitter. Or maybe I'm missing the point of your question... Yes, that's exactly correct. Honestly, what prompted this for me was a great deal simpler -- I was annoyed at the inability to process lists with qlist and textfile directly. ;) So, if I have my code logic calculating the sequence of events and then passing those into Pd as messages, I'd be inclined to do so through a list; I was just having to break up that list and add a bunch of 'set' commands at the beginning, and it makes for extra logic in the patch that looked ugly. Usually when that happens, I try to double-check that I'm not missing something. Frank wrote -- 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. And yeah, Frank, I agree with your points about syncing GUI / app time to Pd's clock. That's actually probably unnecessary for most applications, but for those in which you do need to verify precisely when an event happened (a game). I meant only that I was moving the sequencing *logic* outside Pd, which allows the use of Pd to be more generic. Then you let Pd simply be the event scheduler, and your UI and app logic do the work of deciding the sequence, but not the clock-specific scheduling of any of the events in that sequence. And hence I'm passing off lists back to Pd (not huge lists, but nonetheless) I think this conversation largely answers my questions. The difference between what I've been doing and what the Rj scene player we have included with libpd does was that I didn't necessarily want to patch the Pd sequencing logic, but instead leave that as generic as possible in order to allow myself (and others) to try out ideas in their code, in Java or C++ or whatever. Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Scheduling events, libpd, and sequencing
Hi everyone, Thanks for the feedback on the timing discussion; I do feel that was useful. At some point, it may even be worth writing up a canonical answer there, alongside some tests. This still leaves me puzzling over some questions, though, in terms of sequencing events in real time - forgetting, for a moment, even those timing implications. Let's imagine you have an interface scheduling events from another language, and Pd as an engine (increasingly common with libpd) processing those events. textfile and qlist each do this, qlist tending to be the more convenient. Then you can send messages to whatever apparatus you have for actually processing events and make sound. But what would be the most efficient way to send events to those objects for future scheduling? qlist seems to be built for the purpose, but two issues: 1. qlist seems confused when there's no text file - and in libpd (or really any real-time process), writing to a textfile seems meaningless. 2. qlist would require sending every event - not an entire sequence - one at a time, since it can't process lists. With textfile, I can add a list, but then the list gets stored entirely as one message - which means to iterate through the list, I have to again split it into individual items. Maybe that's okay, and that's really the most Pd-like way of doing things. But if you were using Pd as an interactive music engine, you'd be concerned about: 1. efficiency of messages 2. real-time performance Should I assume that this will likely deliver adequate timing and press on with this basic method? Is there any particular advantage beyond convenience of one or the other? Or is there another method that I'm missing? I'm particularly interested in this as I imagine I'll be answering this same question with others a lot, and I don't want to endorse anything less than a best-practices solution. Peter PETER KIRN http://createdigitalmusic.com | http://createdigitalmotion.com PhD Candidate, CUNY Graduate Center Adjunct Faculty, Parsons The New School for Design ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
On Tue, Feb 15, 2011 at 08:30:00AM -0500, Peter Kirn wrote: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN You accidently had html-mail switched on. :) Thanks for the feedback on the timing discussion; I do feel that was useful. At some point, it may even be worth writing up a canonical answer there, alongside some tests. This still leaves me puzzling over some questions, though, in terms of sequencing events in real time - forgetting, for a moment, even those timing implications. Let's imagine you have an interface scheduling events from another language, and Pd as an engine (increasingly common with libpd) processing those events. textfile and qlist each do this, qlist tending to be the more convenient. In this context qlist and textfile are eqivalent: qlist is just a textfile with a metro/delay and a sender already built in. Both objects do things inside of Pd and the metros work with subsample accuracy. I don't think, you can take them as a model for communication with external processes: Once the file is loaded into a textfile's or qlist's memory, there's no communication with the outside world (network, harddisk, other processes) happening anymore. I think, a better model for realtime interaction might by OSC with timetags. But what would be the most efficient way to send events to those objects for future scheduling? qlist seems to be built for the purpose, but two issues: 1. qlist seems confused when there's no text file - and in libpd (or really any real-time process), writing to a textfile seems meaningless. 2. qlist would require sending every event - not an entire sequence - one at a time, since it can't process lists. With textfile, I can add a list, but then the list gets stored entirely as one message - which means to iterate through the list, I have to again split it into individual items. qlist can send lists just fine. Both qlist and a textfile with sender/outlet and metro-timing simply send Pd messages like floats, symbols, lists, etc. It's up to the composer to define, what's describing an event and what describes a sequence. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
On 15/02/11 13:30, Peter Kirn wrote: But what would be the most efficient way to send events to those objects for future scheduling? I have some code that allows you to cache incoming events (eg: from [netreceive]) and dispatch them all at once in 0 logical time. I called it [bundle] because of the vague similarity to OSC bundles. Something like begin, foo, bar, baz, end /* with arbitrary time between messages */ | [bundle] | foo, bar, baz /* all in 0 logical time, when 'end' arrives */ There are some issues (like 'list' vs 'notlist' messages, 'begin' and 'end' won't be stored, negative nesting count (too many 'end'), ...) but it might be a useful starting point. qlist seems to be built for the purpose, but two issues: 3. sends to names instead of outlet, which makes it much less flexible Claude #N canvas 0 0 331 368 10; #X obj 19 20 inlet; #X obj 19 41 route begin end; #X obj 19 62 b; #X obj 92 62 b; #X obj 92 83 v \$0-depth; #X obj 92 104 - 1; #X obj 119 146 v \$0-depth; #X obj 19 83 v \$0-depth; #X obj 19 145 v \$0-depth; #X obj 19 104 + 1; #X obj 92 166 sel 0; #X obj 138 118 spigot; #X obj 190 114 spigot; #X obj 138 56 t a a b; #X obj 197 53 v \$0-depth; #X obj 197 93 == 0; #X obj 233 94 != 0; #X obj 197 73 t f f; #X obj 243 336 outlet; #X obj 92 280 textfile; #X obj 190 134 list prepend add; #X obj 190 155 list trim; #X msg 131 211 rewind; #X obj 92 187 t b b b; #X obj 111 231 until; #X msg 92 252 clear; #X obj 92 125 t f f; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 1 3 0; #X connect 1 2 13 0; #X connect 2 0 7 0; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 5 0 26 0; #X connect 7 0 9 0; #X connect 9 0 8 0; #X connect 10 0 23 0; #X connect 11 0 18 0; #X connect 12 0 20 0; #X connect 13 0 11 0; #X connect 13 1 12 0; #X connect 13 2 14 0; #X connect 14 0 17 0; #X connect 15 0 11 1; #X connect 16 0 12 1; #X connect 17 0 15 0; #X connect 17 1 16 0; #X connect 19 0 18 0; #X connect 19 1 24 1; #X connect 20 0 21 0; #X connect 21 0 19 0; #X connect 22 0 19 0; #X connect 23 0 25 0; #X connect 23 1 24 0; #X connect 23 2 22 0; #X connect 24 0 19 0; #X connect 25 0 19 0; #X connect 26 0 10 0; #X connect 26 1 6 0; #N canvas 0 0 450 300 10; #X obj 124 153 bundle; #X msg 31 27 begin; #X msg 32 116 end; #X msg 120 77 foo; #X msg 168 81 bar; #X msg 212 79 baz; #X obj 124 174 print bundle; #X connect 0 0 6 0; #X connect 1 0 0 0; #X connect 2 0 0 0; #X connect 3 0 0 0; #X connect 4 0 0 0; #X connect 5 0 0 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
You accidently had html-mail switched on. :) Argh. Stupid Thunderbird. In this context qlist and textfile are eqivalent: qlist is just a textfile with a metro/delay and a sender already built in. Both objects do things inside of Pd and the metros work with subsample accuracy. I don't think, you can take them as a model for communication with external processes: Once the file is loaded into a textfile's or qlist's memory, there's no communication with the outside world (network, harddisk, other processes) happening anymore. Ah, okay, that's good to know. I guess my main question was, what's the best way to send event lists from the language to either of these objects? I think, a better model for realtime interaction might by OSC with timetags. Right, but in an embedded context (i.e., pd embedded in another language), OSC seems to me to add unnecessary overhead. See above question. qlist can send lists just fine. Both qlist and a textfile with sender/outlet and metro-timing simply send Pd messages like floats, symbols, lists, etc. It's up to the composer to define, what's describing an event and what describes a sequence. Right, uh, but that's the *output* from those messages. (I don't think either can receive as flexibly as that.) 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 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.) Am I making a bit more sense? I was just unsure how best to handle (and recommend to others how to handle) the interface between Pd and the outside world, if Pd is acting in real-time but responding to changing sequences from code written elsewhere, outside the logic of the patch. Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
I have some code that allows you to cache incoming events (eg: from [netreceive]) and dispatch them all at once in 0 logical time. I called it [bundle] because of the vague similarity to OSC bundles. Something like begin, foo, bar, baz, end /* with arbitrary time between messages */ | [bundle] | foo, bar, baz /* all in 0 logical time, when 'end' arrives */ There are some issues (like 'list' vs 'notlist' messages, 'begin' and 'end' won't be stored, negative nesting count (too many 'end'), ...) but it might be a useful starting point. I'd love to see that. (Was it attached, sorry?) I was wondering about something along those lines; in fact, had a conversation with a friend about how this is done with LED arrays, which involves some similar message structure. 3. sends to names instead of outlet, which makes it much less flexible Yes, indeed. Peter ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Scheduling events, libpd, and sequencing
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 BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
