Version 2 (modified by shahn, 7 years ago) (diff)


There is a version of the protocol here:, but I suggest, we work on it on this page. So I'll start by writing down what works (or should work). This table should be updated, once Loops supports the respective messages. Proposals for future enhancements are further below.

OSC-path signature argument description description
SC -> Loops
/fsloops/register s{s}* (ClientName, Sonifikationsmethoden) Handshake
/fsloops/reconnect s (ClientName) Handshake ohne resetting
/fsloops/gamecontroller/scalar/selectNext selects the next scalar
/fsloops/gamecontroller/scalar/selectPrevious selects the previous scalar
/fsloops/gamecontroller/scalar/manipulateX f value sets the real part of the selected scalar
/fsloops/gamecontroller/scalar/manipulateY f value sets the imaginary part of the selected scalar
/fsloops/gamecontroller/loop/selectNext selects the next loop
/fsloops/gamecontroller/loop/selectPrevious selects the previous scalar
Loops -> SC (deprecated)
/fsloops/reset Loescht alle Loops und mutet instantan
/fsloops/updateLoop s{ff}* (LoopName, abwechselnd magnitude und phase) Legt eine neue Loop an
/fsloops/muteOn ss (LoopName, Sonifikationsmethode)
/fsloops/muteOff ss (LoopName, Sonifikationsmethode)
/fsloops/onSet si (LoopName, SkalarIndex ab 0)
/fsloops/offSet si (LoopName, SkalarIndex ab 0)

The messages that are sent from Loops to SuperCollider are all deprecated, because Loops is going to be a perfect slave. We don't even need a message to acknoledge receiving, because we are using tcp.

Future Changes

Remove name of sonifications

Loops doesn't need to know these.

OSC-path signature argument description description
/fsloops/register s (ClientName) Handshake

Remove deprecated messages from Loops to SC

Yes. Loops should be totally silent.

Allow creation of Loops from SC

Well, yeah, that's probably the most basic thing we need. Here's a proposal:

/fsloops/loops/add s LoopName Adds a new empty Loop
/fsloops/scalars/add sff (LoopName, magnitude, phase) Adds a scalar

Another option is this:

/fsloops/loops/update s{ff}* (LoopName, magnitude and phase, alternating) If a Loop by that name does not exist, a new one will be created. The scalars will be reset. If a pre-existing Loop contained more Scalars than are transmitted during an update, they will be removed from the Loop.

I would prefer the second option. Martin?

Implement at this ticket

Tidy up gamecontroller messages

The protocol does not need to reflect that a modification is triggered by a gamecontroller (this is probably misused already anyway ;). So we need similar messages to manipulate single scalars that are a bit cleaner.