A new RFC (request for comment) has been opened here:
supercollider:main ← muellmusik:master
opened 12:26PM - 12 Jan 21 UTC
- Title: Add an /n_status Message and equivalent lang methods
- Date proposed: … 2021-01-12
- RFC PR: https://github.com/supercollider/rfcs/pull/0013
# Summary
Add an /n_status message to the OSC command interface, to allow you to check on whether a node currently exists and if it is running or paused.
# Motivation
Given the complications of asynchronous communication, it can be useful to check whether a node already or still exists. (A recent case arose in the VST interface). Currently there is no straightforward way to do this. One can send an /n_query but if the node does not exist this will cause a FAILURE message to be posted (in this case the node not existing is not a failure, just info that we need). This seems like a basic thing that we should be able to query. It would also be useful in multi-client situations, where another client may have created a node.
The existing NodeWatcher approach does not suffice here, since there is no way to reliably register a node that may not exists. Enabling this would require such a message.
As we're doing this we may as well include info on whether the node is running or paused. Anything else?
Additional context moved here by request:
The specific context this arose from was using the VST plugin extensions with NodeProxies. It's complicated, but you can see the discussion here:
https://www.listarc.bham.ac.uk/lists/sc-users/msg69122.html
tldr: NodeProxies defer node creation to a scheduled event on their internal clock (I assume for quantisation purposes, but there may be other reasons). This makes the usual approach of wrapping code in a bundle with /sync messages impossible.
A NodeWatcher would seem to be the obvious goto for that problem, but since nodes are not watched by default, and server state is not necessarily tracked, it's not currently possible to use NodeWatcher with a node whose state cannot be inferred. This would also solve that problem more general problem.
Multi-client situations, which could include varying and/or not known client communities would also have uses for being able to query the existence of a node. A direct to server query would be faster, more reliable and less cumbersome than client to client queries. This functionality could help with some discovery applications, and with querying state of individual nodes after a crash, when language state is lost.
Finally, AFAIK there is no way to query a node's run state, which this RFC would also support, so perhaps further weight for an addition. I am fairly sure there would be other applications which I've not thought of.
# Specification
/n_status - Check whether a node exists and its run status.
N * int node ID
The server sends an /n_status.reply message for each node to registered clients.
/n_status.reply has the following arguments:
int node ID
int status flag, 1 if running, 0 if paused, -1 if node was not found
In addition we will add a corresponding message to the Node class, and optionally a checkNodeStatus method to the Server class. (Thoughts on this welcome!) Other places in the class lib?
# Drawbacks
Adds another command to the interface.
# Unresolved Questions
Whether to add a method to Server. My instinct is no, as it's a bit odd style, and Server is already huge.
Please visit the above link for discussion.
Summary: Add an /n_status message to the OSC command interface, to allow you to check on whether a node currently exists and if it is running or paused.
1 Like