[MOD] [LAD] Invitation - Control Chain interface and communication protocol

[Hanspeter Portner]

On 03.11.2014 15:07, Gianfranco Ceccolini wrote:
> The Control Chain interface was conceived with the LV2 control
> ports properties in mind. It tries to dis-abstract the LV2 Control
> structure in tangible (and material) form.

I write from the perspective of someone that would mainly be
interested in the controllers themselves and the system to daisy chain
them. If they could be used without the MOD and LV2, too, this would
be a plus.
> The first purpose of the Control Chain was to connect the MOD and
> its external peripherals. The MIDI system is very generalistic and
> we didn’t want to design a “MIDI Clone”.

MIDI is just too static for a lot of things, I strongly agree...
> A good example is the footswitch.  The Control Chain footswitch
> has built in its firmware different behaviours depending on port
> properties. It alternates the state of toggles controls, it can
> trigger an event, it can run the items of an enumeration list and
> it can also measure time and offer TapTempo for time based units.

Is there a reason why the different behaviours need to be implemented
in the footswitch firmware directly?
I am asking from the perspective of someone that often belongs to a
part of the user base that would like to have access to the raw event
data of a controller and use it for something the designers did not
think of (one of the main reasons I advocate OSHW).
Couldn't the different behaviours be implemented in software on the
host side, e.g. as a LV2 plugin itself? The host/user then would just
load up the behaviour he/she needs.
                        plugin behaviour 1 <=> effects plugin a
controller <=> host <=> plugin behaviour 2 <=> effects plugin b
                        plugin behaviour 3 <=> effects plugin c
'plugin behaviour x' would have an Atom In/Out port for communication
with the controller with the raw event data that suits best the type
of controller in question. Depending on the behaviour, the plugin
would have an arbitrary number of Control/CV/MIDI/... output ports to
connect to downstream plugins.
If someone would be in need of a different behaviour, it would be
simpler/faster to come up with a software solution instead of a
tedious firmware rewrite/flashing of the controller.
> The physical interface of the Control Chain devices is an RS-485 
> full-duplex serial line running at 1Mbit/sec.  Currently up to
> eight devices can be daisy chained and by use of the RJ-45 cable we
> also power the devices ( 1 pair for input,1 for output and 1 for
> power supply).
> 
> After some development we came to the conclusion that such a
> protocol could be extended for virtual devices in the GUI as well
> and this would make the development of plugins interfaces much
> easier.

I like OSC a lot. It is widely implemented. It can be sent/received
via UDP, TCP, serial (raw, USB, your RS-485), Jack MIDI and LV2 atoms.
Does your system have specific prerequisites that could not be handled
by OSC? Could it e.g. be used for 'controller <=> plugin behaviour x'
communication?
Is there a specification of your current implementation (even if it's
only a piece of source code)? I searched the webpage and github repo,
but couldn't find any.
hp