Why does clearing an 'unargumented' TempoClock stop a Routine?

Questions
1

Hello!

Why does the first t.clear stop the Routine and the second one not? Does the Routine in the first instance run on the ‘unargumented’ TempoClock?

t=TempoClock; //'unargumented'

(
r= Routine(
	{inf.do{ |i|
		i.postln;
		1.wait}});
)

r.play;
t.clear; //stops Routine

t=TempoClock(4,16);

(
r= Routine(
	{inf.do{ |i|
		i.postln;
		1.wait}});
)

r.play;
t.clear; //doesn't stop Routine

cheers! k

2

You’re seeing two somewhat subtle, implicit things here:

  1. Some methods on the TempClock class are meant to affect the global tempo clock - including clear. In the first class, you assign the class TempoClock to t, and the clear affects the global clock. In the second case, you create a new TempoClock and clear that.
  2. When you play a Routine, it’s implicitly getting played on the global TempoClock if you don’t specify a clock as an argument to play. So, in your first case, clear affects the routine - in the second case, you’re clearing a different clock than the one your Routine is running on.
1 Like
3

Great! I didn’t know there is a global `TempoClock’ running in the back :slight_smile:

Many thanks for clarifying this. k

4

Generally you only need to create new clocks if you need to control scheduling on them separately from everything else, or in the case of TempoClock if you want tempo settings different than the global ones.

1 Like
5

To be precise, Scott is referring to the default TempoClock.

r = Routine { loop { "abcde".scramble.postln; 1.0.wait } }.play;

r.clock === TempoClock.default;
-> true

r.stop;

There’s nothing special about this clock, except that it’s assigned to TempoClock.default (meaning that it’s used when you play something without specifying a clock).

You can switch the default to a different clock by TempoClock.default = myOtherClock.

hjh

1 Like
6

great, many thanks James!