This is very typical of SuperCollider. It relies very (too?) much on implicit defaults. That was tricky for me as a newcomer to SuperCollider.
For instance, for Events you can do this and get a sound (of course assuming server is booted).
().play;
Adding some other supported property to the event will override the default for that property, but use defaults for other stuff.
(degree: 3).play;
The same applies to Pbinds. Without arguments you still get a sequence - it uses the default synthdef, note, duration:
Pbind().play // press Cmd-. to stop the sequence
Override one argument, otherwise use defaults:
Pbind(*[degree: Pseq([0, 3, 7, 10], inf)]).play
Override two arguments, otherwise use defaults:
Pbind(*[
degree: Pseq([0, 3, 7, 10], inf),
dur: Pseq([0.15, 0.1], inf)
]).play
)```
Another default: All Pbinds are by default also played using the default TempoClock for tempo, so changing its tempo will affect the pattern:
```TempoClock.default.tempo*60; // post current tempo in bpm
TempoClock.default.tempo = 80/60; // change pattern tempo to 80 bpm
TempoClock.default.tempo = 100/60; // ... 100 bpm
TempoClock.default.tempo = 120/60; // ... 120 bpm```
[quote="zebra, post:27, topic:3185"]
i'm trying to think of a scenario where it's better to explicitly schedule something on the SystemClock
[/quote]
SystemClocks and TempoClocks have the same priority so I believe it's mostly a matter of whether you want to be able to determine / change tempo dynamically (use a TempoClock) or just schedule by regular time.
AppClock, a third option, is of lower priority and typically used for UI updates. That's why you as a newcomer also run into errors that mean having to ```{}.defer``` stuff that's scheduled on a SystemClock or TempoClock that is supposed to update GUI widgets.
Since SystemClock has no variable tempo I believe only one exists and is used but with TempoClocks you can create as many as you want if you need multiple apps with differing tempos.
How nice we got SuperCollider discussions going on here...
