HelpSource/Classes/Task.schelp

   1 CLASS::Task
   2 categories::Scheduling
   3 summary::a pauseable process
   4 related::Classes/Routine
   5
   6 DESCRIPTION::
   7 Task is a pauseable process. It is implemented by wrapping a link::Classes/PauseStream:: around a link::Classes/Routine::. Most of its methods (start, stop, reset) are inherited from PauseStream.
   8
   9 Tasks are not 100% interchangeable with Routines.
  10
  11 list::
  12 ## Condition does not work properly inside of a Task.
  13 ## Stopping a task and restarting it quickly may yield surprising results (see example below), but this is necessary to prevent tasks from becoming unstable if they are started and/or stopped in rapid succession.
  14 ::
  15
  16 CLASSMETHODS::
  17
  18 method::new
  19 argument::func
  20 A Function to be evaluated.
  21 argument::clock
  22 A Clock in which to play the link::Classes/Routine::. If you do not provide a Clock the default is an instance of link::Classes/TempoClock::. Remember that methods which call Cocoa primitives (i.e. GUI functions) must be played in link::Classes/AppClock::.
  23
  24 INSTANCEMETHODS::
  25
  26 method::play
  27 argument::argClock
  28 (optional) Override the clock assigned in Task.new.
  29 argument::doReset
  30 If true, the task will start over from the beginning. Default is false (task will resume where it was when it was last stopped).
  31 argument::quant
  32 See the link::Classes/Quant:: helpfile.
  33
  34
  35 subsection::Other control methods
  36
  37 method::start
  38 Restart the task from the beginning.
  39
  40 method::resume
  41 Resume the task where it left off.
  42
  43 method::pause
  44 Stop playing now.
  45
  46 method::stop
  47 Stop playing now. (Pause and stop have the same implementation.)
  48
  49 method::reset
  50 Set the stream to restart from the beginning the next time it's played.
  51
  52 subsection::Notifications
  53
  54 Other objects might need to be aware of changes in the state of a task. The following notifications are broadcast to dependents registered with the Task object.
  55
  56 list::
  57 ## strong::\userPlayed:: - Sent at the time the user calls play, start or resume.
  58 ## strong::\playing:: - Sent at the time the task begins playing on the clock (corresponding to quant).
  59 ## strong::\userStopped:: - Sent at the time the user calls pause or stop.
  60 ## strong::\stopped:: - Sent at the time the task is finally removed from the clock (this is the time when the next event would have occurred if the task had not been stopped). If the task function completes on its own, this notification is sent without 'userStopped' being sent previously.
  61 ::
  62
  63 EXAMPLES::
  64
  65 subsection::What happens if you stop and start the task too quickly?
  66 code::
  67 (
  68 t = Task({
  69         50.do({ arg i;
  70                 i.squared.postln;
  71                 0.5.wait;
  72         });
  73 });
  74 )
  75
  76 t.start;
  77 t.pause;
  78 t.resume;
  79 t.reset;
  80 t.stop;
  81
  82 // unexpected behavior here
  83 (
  84 t = Task({
  85         ["go", thisThread.clock.beats].postln;
  86         inf.do({ arg i;
  87                 2.wait;
  88                 [ "wake up", i ].postln;
  89         });
  90 });
  91
  92 fork {
  93         t.start;
  94         0.1.wait;
  95         t.stop;
  96         0.1.wait;
  97         t.start;
  98         6.wait;
  99         t.stop;
 100 };
 101 )
 102
 103 [ go, 1702.114411906 ]
 104 [ go, 1704.114411906 ]
 105 ::
 106
 107 Based on the forked thread, you would expect the second "go" line of output to occur 0.2 seconds after the first, but in fact it happens two seconds later (the same amount of time the task waits between iterations). This is because the task must not schedule itself on the clock more than once. When the task is stopped, it remains scheduled until it wakes up again (based on its wait time). If, during this interval, the task were restarted, there would be two references to the task in the scheduler queue -- a situation that is irrecoverable short of stopping everything with command-period.
 108
 109 As a result, Task should be used for processes that need to start and stop relatively infrequently, but for which maximum stability is required. If you need fine-grained control over when and how the process stops and resumes (as is the case, for instance, with condition), link::Classes/Routine:: is preferred.