Node.isPlaying, Node.isRunning (n_go, n_end, n_on, n_off) --- differences?

1

Just looking into this, as the docs aren’t super clear as to what playing and running exactly mean. (also wasn’t able to find much on this here forum, it seems only Calling run(true) on a Group is tangentially related)
So one creates a NodeWatcher for the client to pick up on server side messages from Nodes that have been registered. Ok so far… but I just haven’t been able to figure out what these messages do in fact mean…
Here’s my best guess, please correct me if I got it wrong, and confirm if I got something right. I might add this clarification to my gigantic list of pending doc edits.

server client what’s it mean
n_go, n_end node starts/stops “playing” presumably, creation and freeing of node on server
n_on, n_off node starts/stops “running” ??? I guess maybe takes nodes out of dsp loop???

So this would mean that a node can be “playing” but not be “running”, but the inverse is not possible. Also, I figure that “pausing” nodes means they’re “off”, i.e. not “running”.

I assume one turns notes “off” (pauses them) because a) that saves on processing (would be cool to know in what way exactly) and b) one doesn’t want to have rebuild the respective synths or groups, as one would have to when simply freeing them.

Thanks oh you wise people for the generous sharing of your wisdom

2

This is (mostly) covered in the Server Command Reference, under Node Notifications from Server.

http://docs.supercollider.online/Reference/Server-Command-Reference.html#Node%20Notifications%20from%20Server

However, for /n_on and /n_off, it doesn’t state explicitly what “turning on/off” means (that would be a good easy pull request for someone to put in). Your guess is correct – it has to do with the node’s paused status. node.run(false) triggers a /n_off message to be sent, and the opposite for true triggers /n_on.

A doneAction that frees a node causes /n_end; one that pauses the node (or a UGen such as Pause) causes /n_off.

I don’t recall using paused nodes very much, except if I’ve loaded a bunch of mixer channels and a couple of reverbs and I need to step away from the computer for awhile. Then I might do s.defaultGroup.run(false) temporarily. Otherwise I’ve had little use for paused nodes.

hjh

1 Like
3

thanks!
Now on looking at the command reference more closely it seems like I failed to notice that the go/end,on/off commands are not sent to the nodes in question but are strictly notification.

Whereas n_run [nodeID, 0] is the thing to send to a node to pause it… the command reference states that the node “is not executed” when paused.
Pedantic follow up question: Can nodes be paused/unpaused in a sample accurate way (E.g., when using Done.pauseSelf), or is this quantized to control rate?
What happens to possible downstream nodes that aren’t paused - I suppose they just get a bunch of zeros in the respective busses?

4

No. As I understand it, nodes can start/stop/pause/unpause only on a control block boundary.

The server doesn’t maintain any dependencies between nodes – it’s your responsibility to know what you’re doing with your node/bus arrangement.

If there’s an In.ar unit that evaluates before anything does Out.ar to that bus, it will get zeroes. Whether this is because of earlier nodes being issued or earlier nodes being non-existent doesn’t matter.

hjh