[Fluxus] osc-related core dump, and other things

[Artem Baguinski]

On 12/22/07, Dave Griffiths <dave at pawfal.org> wrote:
> On Tue, 2007-12-18 at 16:39 +0100, Martin Ahnelöv wrote:
> > Hi! I've gotten a couple of core dumps by playing around with osc. Turns
> > out that if you use "(osc 1)" on a message with only one value, fluxus
> > crashes. Not so nice =)
>
> The fluxus osc interface is rubbish.
>
> I'm interested in switching to a more standard version written in
> Scheme, but lacking that, I'll put a spring clean on the todo list (and
> make it do bounds checking)

may i suggest the one from VGE?

it is independent of the rest of VGE but might need some clean up
before getting shared with fluxus.

the latest version isn't online yet, it's all over our personal git
repositories.

I'm attaching a test code that illustrates how we use the OSC now. i
normally test this against liblo and embedded osc that our hardware
team uses, at the moment there is one problem between us and liblo
which is i haven't figured out yet whose fault: the blobs (like
strings but with bytecount) get padded with zeros differently by our
code and liblo so if the blob isn't the last argument of a message the
rest of arguments gets hosed.

the code illustrates sending, receiving and replying with explicit
transport layer (udp).

also we do nothing with timestamped bundles yet - as we never use that
facility - all our code so far needed to react asap. but i suspect
we'll start using timestamped bundles eventually for some of the
tracking hardware, so eventually that part will get tested as well.

basically the API is as follows:

client
~~~~~~

(osc:make-message osc-addr types-string . args)

this one returns a byte-string ready to  be sent using e.g. plt
scheme's udp support.

(osc:make-method osc-addr types-string)

this might be a misnomer: it creates a function that accepts as many
arguments as types-string implies and makes a byte-string from them.
this is a helper procedure to avoid typing address and types-string
multiple types. i usually assign the returned function to a symbol
that looks like an osc address (see attachment).

I intentionally haven't integrated the transport layer into OSC, as
OSC itself doesn't specify how messages are delivered. I can imagine a
higher level api that binds together osc and, say, udp to implement a
simpler API.

(osc:bundle time-tag . rest)

this one allows building time-stamped bundles. rest is a list of
messages and bundles. time tag is a cons of two 32 bit integers, as
defined by NTP RFC, as i said we haven't actually used them yet.

server
~~~~~~

(osc:parse-packet byte-str length schedule-proc)

the parser is implemented with "continuation passing style" - you give
it a byte string and length (length argument seems superfluous - if so
it'll disappear in the next refactoring) and a "continuation"
procedure that knows what to do with individual messages. the idea is
that transport layer receives chunks of bytes which are either one
message or a time-stamped bundle. parser unwraps bundles and calls
schedule-proc for each message. schedule-proc also accepts a
time-stamp which can be used to actually *schedule* the message if the
time-stamp is in the future.

either the schedule-proc, or the code that executes scheduled messages
may use the following:

(osc:apply-to-matching namespace msg time-tag action-match action-no-match)

here namespace is a tree that looks like:

'(("foo" ("bar" . /foo/bar-handler-proc) ("baz" . /foo/baz-handler-proc) ...)

and msg is a decoded OSC message (a scheme list of decoded parameters)

action-match and action-no-match are additional procedures that are
executed when a match was found or not. in the next refactoring these
will be made optional keyword arguments.

osc:apply-to-matching supports address globs (/foo/*) in the incoming
messages and globs in namespace are planned. (the difference is:
incoming globs allow to send a message to a number of destinations,
namespace globs allow to receive messages with matching addresses).

there is also a function for somewhat easier creation of namespaces:

(osc:append-namespace  namespace addr proc)

this should be renamed to osc:namespace-append!

it makes namespace creation easier to read as you add addresses that
look like "/foo/bar" instead of ("foo" ("bar" ...))

-- 
cheers,
artm

http://lab.v2.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osc-cont.ss
Type: application/octet-stream
Size: 4604 bytes
Desc: not available
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20071222/6c48f492/attachment-0002.obj>