sc to scd engines

Commands

Commands are registered in engines to handle command invocations from matron via OSC message /command/[commandname] [arg1] [arg2] ... [argn]. Commands have a format tag.

Commands are optional.

This will be easy to implement in other backends (ie. Pd).

Polls

Polls are registered in SC engines to handle polling of values from engine to matron. Polls are either periodic or aperiodic. Periodic polls are scheduled to recurringly send back values given a particular time period. By default, polls are periodic.

Matron (scripts) explicitly has to start polls by issuing OSC message /poll/start [pollindex]. (TODO: what about aperiodic polls? they're not started this way)

Matron (scripts) stop polls by issuing OSC message /poll/stop [pollindex]. (TODO: aperiodic polls)

Matron (scripts) can change poll time via OSC message /poll/time [pollindex] [timeperiod].

Matron (scripts) can explicitly request the current value of a poll via OSC message /poll/request/value [pollindex].

Polls are optional.

Implementation details: Poll values are currently cached SC-side.

TODO: going forward I would suggest to use poll names rather than indexes in the interface (like commands).

This will be reasonably easy to implement in other backends (ie. Pd).

Crone* source files

Crone.sc

Crone

*initClass

*runShellCommand - probably remove, i don't think shell commands will be executed

*startBoot

*finishBoot

*setEngine

*startPoll - "start a thread to continuously send a named report with a given interval"

*stopPoll

*setPollTime

*requestPollValue

*reportEngines - replace with metadata in lua files

*reportCommands - replace with metadata in lua files

*reportPolls - replace with metadata in lua files

*initOscRx

OSC rx address can be set with sclang -u command line arg.

Hard code matron response address?

CroneAudioContext.sc

CroneAudioContext can probably be removed altogether, since a lot of dsp done in sc today (amp, pitch) is moved elsewhere, and there will IMO be no core requirements for groups. Input/output busses for SC to become the busses to read/write signals to.

initPolls

cpu_peak and cpu_avg - are these polls used?

amp_* and pitch_* polls can be ignored, since amp and pitch will not be part of engine

CroneDefs.sc

"utility class to load synthdefs required by crone engines. engines could of course define their own defs, this is for shared functionality."

not sure if there is any motivation to keep these.

CroneEffects.sc

to be removed.

CroneEngine.sc

CroneEngine - refactor relevant stuff to new framework code

guts: passes (already spawned) audiocontext, holds dicts for commands and polls, handlers for allocating and freeing resources.

Engine_None - can be removed (?)

CronePoll.sc

CronePoll

		if(type == \value, {
			oscPath = '/poll/value';
		}, {
			oscPath = '/poll/data';
		});
		
		callback = {
			var val = function.value;
			//postln(val);
			this.value = val; 
			this.sendValue();
		};
		
		if(periodic, {
			task = Task { inf.do {
				//postln("poll task callback...");
				callback.value;
				period.wait;
			}};

		});

CronePollRegistry

might be possible to remove

CroneTester.sc

remove

Commands and polls, going forward (3.0)

Alternative 1

Instead of addCommand and addPoll, I'd suggest to approach this with sending back funcs and metadata from scd files as arrays (if possible).

Each command to be returned as associations of name -> (format: str, handler: func) associations, possibly extended with an optional descriptive name, and an array of controlspecs(?). the latter can be used in lua engine metadata generation. Polls also to be returned as associations of name -> (handler: func)

These events are good injection points for other stuff like docstrings...

Alternative 2

Introduce NornsCmddef and NornsPolldef for registering commands and polls, respectively, akin to how OSCdef and MIDIdef works in vanilla SC. This is probably my preferred alternative.

Behind the scenes a NornsCmddef would setup an OSC handler as necessary, and could also unpack OSC messages for a nicer callback func argument list.

Behind the scenes a NornsPolldef would setup OSC handlers for /poll/start, /poll/stop, /poll/request/value, /poll/time as necessary, and handle caching of values.

I've done something similar in https://github.com/antonhornquist/SerialOSCClient-sc