idea.md

See examples in the following order (gist files are ordered alphabetically rather than by relevance/how i entered them):

• testsine - simplest possible engine
• passersby and glut - real engines with both commands and polls, the latter with polls defined in code
• r - my modular engine
• ack - ack, including the support library inline (see below)
• testsine_pd - possible way to expose a testsine pd engine
• co - imaginary external jack client compressor example

Engine list is retreived by scanning lua files in ~/dust/code recursively instead of receiving a list via OSC. Engine command and poll metadata is also read solely from each engine's lua file. All lua files having "engine_" prefix (ie. "engine_r.lua", "engine_passersby.lua") are considered engine metadata files and should consist of Lua code returning tables which can be required or "dofile()d" into a list of engines in memory (as any other lib). The metadata is used for setup and teardown of engines of different kinds, uniquely identified for each engine by the kind keyword of the table (examples are given for sc, pd and custom_jack_client).

Common to all engine kinds is engine name, commands and polls, the latter two of which each are specified in collections of tables ie. {name="command_name", format="if"} (describing a command) and {name="poll_name"} (describing a poll). Commands and polls are optional.

The config table supplied contains custom settings required for setup/teardown of engine for the given engine kind. In example sc engines only refer to an sc class (these act as current sc engines), the pd one refer to a patch and the custom_jack_client includes reference to an executable and some settings to route the client correctly (for sc and pd I believe this could be implicit).

Other things to note:

• since it's just lua files one may programmatically define the metadata (as for polls in engine_glut.lua)
• current engine lua libs could potentially be incorporated in a section of the metadata file (see engine_ack.lua example). so with proper scaffolding it might be possible to get away from the awkward require 'ack/lib/ack' path and simply inject the lib - i believe the engine.name = 'ack' selection part might be enough?
• this metadata would be enough to include only assets when setting up an engine for use (example: only include the SC class that is actually used for the engine instead of all, which would alleviate SC class duplication breakage)

On the examples:

• passersby, r, glut and ack metadata is taken from current engines
• ack includes the current Ack lib
• the co engine is an imaginary jack client compressor engine
• the testsine_pd engine is an imaginary pd engine equivalent to TestSine
• i'd like to refactor out the params usage from the Ack lua lib, just supply Param instances and implement future core framework support for managing the global params store.