[MOD] Invitation - Control Chain interface and communication protocol
Spencer Jackson
ssjackson71 at gmail.com
Mon Nov 3 22:38:07 BRST 2014
I agree would be good if output to devices was also supported. This would
open possibility of feedback to devices, enabling a footswitch with a nice
large LED tuner display, or complex IO devices like Harry has linked to.
OSC has a nice model which might actually be a little better suited for
inter-device comm than atoms as atoms are expected to go over a dedicated
channel directly to a port (I think) rather than the shared channel here.
OSC could carry whatever data is necessary to specify the device, plugin,
port, etc. and even have a raw LV2 atom as a blob in the OSC message.
Perhaps a requirement would be each device has a unique ID that is
incorporated into its address. This could be done in software or with a DIP
switch or something and potentially remove the 8 device limit on the
current control chain gameplan (I haven't done my homework on the control
chain protocol so I could be totally off). This does probably raise the
complexity requirement for control chain devices.
Just my 2 bits (if it is actually applicable).
_Spencer
p.s. 485 is a good choice I say, though I've never seen a device run it at
1Mbps. A slower speed could have more robustness with still unnoticeable
latency. I'm sure you have more data to back up your choice though than I
have to question it.
On Mon, Nov 3, 2014 at 4:55 PM, Harry van Haaren <harryhaaren at gmail.com>
wrote:
> On Mon, Nov 3, 2014 at 2:06 PM, Gianfranco Ceccolini <
> franconassis at gmail.com> wrote:
>
>> Hi LADs
>>
> Hey!
>
>
>> 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.
>>
> Sounds good!
>
>
>> The first purpose of the Control Chain was to connect the MOD and its
>> external peripherals.
>>
> Cool, is there any scope you'd like to discuss currently? Or is this a
> "brainstorming welcomed" discussion too?
>
> In future, I'd love to see a hardware "Fabla" sampler, which integrates
> the DSP into the MOD, and uses Control-Chain to communicate. That would
> require a pretty heavy-duty communication protocol; think mapping all of
> the controls on a device such as this (yes I'm aware this isn't
> ControlChain... yet ;)
> http://m-audio.com/assets/microsites/tfp/img/tfp_ortho.jpg
>
>
>> The physical interface of the Control Chain devices is an RS-485
>> full-duplex serial line running at 1Mbit/sec.
>>
> I don't feel qualified to discuss the techie implementation stuff about
> the actual protocol itself. In terms of how it can be used, feel free to
> quiz / query my intended use-cases :D
>
> At this current state, the Control Chain supports only Input ControlPorts.
>> People have been asking about the Tuner and other plugins that have Control
>> Outputs.
>>
> In theory, if Lv2:Atom-s are supported (which implies URID map), then the
> necessary parts for arbitrary LV2 DSP -> UI communication (and vice-versa)
> is covered.
>
> This would imply that the "official" URID map is on the MOD device, and a
> CC capable controler can query a URID, and its returned an integer that is
> mapped.
>
>
>> So we’re opening up the discussion to set the requirements and
>> possibilities that shall be implemented.
>>
> I would see Atom support as being difficult to engineer - but a huge
> achievement for forward-compatibility if it can be achieved given the
> constraints / time.
>
> Cheers, -Harry
>
> --
>
> http://www.openavproductions.com
>
> _______________________________________________
> Developers mailing list
> Developers at lists.portalmod.com
> http://portalmod.com/cgi-bin/mailman/listinfo/developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://portalmod.com/pipermail/developers/attachments/20141103/35789cc5/attachment.html>
More information about the Developers
mailing list