Finally, when doing batch processing, does Pd create a "list" of all the events that will take place before doing them?
there's nothing special with batch mode. Pd will just tick the scheduler as fast as possible (instead of waiting for the soundcard), so every rule of realtime mode also applies to batch mode. blocking operations are totally fine, Pd will just wait for it to complete, it is fully deterministic. one should be careful with [realtime], though. the difference to [timer] will become very apparent :-)
Christof
Gesendet: Dienstag, 29. Januar 2019 um 11:45 Uhr Von: "Federico Camara Halac" camarafede@gmail.com An: "pd list" pd-list@iem.at Betreff: [PD] batch processing and event execution
Hello, I have three part question regarding -batch processing and (non-DSP) event execution. Say I have a [t b b b] with time-consuming events such as [text], [array], [soundfiler] reading, array normalizing, analyzing, etc. Since each stage of the [trigger] depends on the last, is it a fact that every stage would be executed until completion? I have been using Pd for a while now, and I know this should be true (I have no evidence against it), so I guess what I am asking is How can I really be sure that it is indeed a fact? Is there another flag I can use? This question extends to those objects that write to disk using [write( messages like [text], [array], or even [writesf~]... and also when saving stuff with Gem's [pix_write], [pix_buffer]... When you send a write message of this sort, am I correct in assuming that Pd will stop doing anything else but writing-to-disk until the writing-to-disk is done, and then resume its next task once the file is completely written? Finally, when doing batch processing, does Pd create a "list" of all the events that will take place before doing them? Is there anything of that sort? Thanks! Fede _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list