sc to scd engines

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

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...

(TODO: write new examples to exemplify this)

CroneGenEngine

How will a genengine in 3.0 look like?

CroneGenEngine to be rewritten as a core class for scd style engines - this is already in the works as I’m rewriting it.

Or I'll just make a .scd library of this and have it non-core.

SC->SCD Examples for discussion (initial idea from a while back)

Glut https://gist.github.com/antonhornquist/7f4bb521e0eafa5ee4a180d07afe5db6

Ack https://gist.github.com/antonhornquist/342acda2c9eae9ff5bf6dfb3d8bc0f39

SC->SCD Examples (new, using arrays instead of method invocations for registering commands and polls)