From abc9dadbcefcbda263625ca65a9db3d9b1d863d3 Mon Sep 17 00:00:00 2001 From: Owen Green Date: Wed, 2 Oct 2019 13:29:19 +0100 Subject: [PATCH] release-packaging/HelpSource/Guides/FluidBufMultiThreading.schelp; Add documentation of job completion mechanisms. --- .../Guides/FluidBufMultiThreading.schelp | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/release-packaging/HelpSource/Guides/FluidBufMultiThreading.schelp b/release-packaging/HelpSource/Guides/FluidBufMultiThreading.schelp index 8b02a95..c4000b0 100644 --- a/release-packaging/HelpSource/Guides/FluidBufMultiThreading.schelp +++ b/release-packaging/HelpSource/Guides/FluidBufMultiThreading.schelp @@ -101,6 +101,23 @@ f.free //to appreciate the multithreading, use your favourite CPU monitoring application. scsynth will be very, very high, despite the peakCPU and avgCPU being very low. :: +subsection:: Ding, Fries are Done + + There are a couple of options for dealing with the end of a job. First, the FluidBuf* objects support done actions, so you can use things like LINK::Classes/FreeSelfWhenDone:: or LINK::Classes/Done::, or set a doneAction in the call to .kr (see LINK::Classes/Done:: for details). Note that the UGen's done status only becomes true in the event of successful completion, so it will not catch cancellation. However, the doneAction will run whatever, so you can rely on the synth freeing itself. + + Alternatively, the synth will send a /done reply to the node, which also carries information about whether it completed normally or was cancelled. You can use LINK::Classes/OSCFunc:: to listen for this message, targetted to your nodeID. + +CODE:: +a = {FluidBufThreadDemo.kr(b,1000,doneAction: 2).poll}.play; + +OSCFunc({|msg| //args are message symbol (/done), nodeID and replyID (which gives status) + if(msg[2]==0){"Completed Normally".postln}{"Cancelled".postln}; + },"/done",argTemplate:[a.nodeID]).oneShot; //only listen to things sent for this node + +a.free; //optionally cancel +:: + + section:: Opting Out Whilst using a worker thread makes sense for long running jobs, the overhead of creating the thread may outweigh any advantages for very small tasks. This is because a certain amount of pre- and post-task work needs to be done before doing a job, particularly copying the buffers involved to temporary memory to avoid working on scsynth's memory outside of scsynth's official threads.