OSC support should be added to `render` framework

[jonathanhogg]

The OSC stuff that's currently in there to support the separate Ableton Push process should be moved into the render package and turned into a general-purpose mechanism for interfacing the language with external things via OSC.

The obvious thing to do is to support an OSC listener that can update the state. Maybe something like:

!osc_listen host='127.0.0.1' port=12345
    !endpoint address='/a/b/c' state=:abc

With whatever values are sent to the /a/b/c address being saved as a vector against the :abc state key. This will obviously work fine for ints, floats, bools and strings. Could consider the idea of grouping up the address path into a node/vector hierarchy, like:

!osc_listen host='127.0.0.1' port=12345
    !group prefix=:a;:b
        !endpoint address=:c state=:abc

This may be unnecessarily wordy though. There's probably no harm in it and in allowing addresses to be vectors that get joined using / characters.

Trickier is figuring out how to send OSC values. Perhaps something like:

!osc_send host='127.0.0.1' port=11000
    !group prefix=:live
        !endpoint address=:track;:set;:volume values=track_id;volume

This should presumably keep a cache of the last sent addresses/values and only send changes, with perhaps some kind of (per-endpoint) confgurable timeout to resend the current value if it doesn't change.

[jonathanhogg]

I'm not certain of the vectors-joined-with-slashes idea. More in-keeping with the way that other string processing things work would be to directly concatenate and explicitly include the slashes in the strings. This either means using quoted strings instead of symbols, or allowing slash to be a part of a symbol in the lexer (e.g., :/live).

[jonathanhogg]

Thinking again about OSC configuration.

The terminology used in the OSC specification:

• address/address pattern: a /-prefixed/separated set of strings or glob patterns
• argument: a typed value
• message: an address pattern and a series of arguments representing a call
• bundle: a grouped set of messages with an optional time code representing when these messages should be acted on
• packet: a data packet containing a message or a bundle
• client: a sending network port that send packets
• server: a listening network port that can receive packets
• method: a specific address endpoint at the server to which messages can be dispatched
• container: a grouping of methods with a common prefix

I am leaning towards grouping-up all OSC stuff into a single !osc node. The obvious nodes under this would be !client and !server. It seems sensible for !server to contain !container and !method nodes, and I think it makes sense for both to take an address= attribute.

I'm also thinking that it might be a good idea to extend address out to also encompass the hostname and port to listen/send a message on/to. So an example might be:

!osc
    !server address='127.0.0.1:12345'
        !container address='/a/b'
            !method address='/c' state=:ab;:c
            !method address='/d' state=:ab;:d

and:

!osc
    !client address='127.0.0.1:12345'
        !container address='/a/b'
            !method address='/*' arguments='Hello';10

but perhaps also supporting:

!osc
    !server
        !method address='127.0.0.1:12345/a/b/c' state=:abc
    !client
        !method address='127.0.0.1:12346/a/b/c' arguments='Hello';10