[MOD] Moving on with Control Chain

[Gianfranco Ceccolini]

Hi everyone
Sorry for the time gap. There’s a lot going on here and we’re slipping a bit with organization. But things are getting in tracks finally.
I sent a previous email inviting everyone for the discussion about the Control Chain and we gladly received many answers and considerations. I’ve tried to compile them here and added explanation where I could.
First of all, I humbly ask you to take a look at the documentation we did on what we expect the Control Chain to be. Karl pointed out the “half-duplex” term found in the Arduino Shiled documentation but that is kind of “obsolete”. The Arduino Shield already works with the former protocol which is still half-duplex and, as I explained in the Invitation, we’re going for full-duplex and we want to add features to it that you developers shall find desirable. Once we set this new protocol we shall update the Arduino Shield documentation.
Sorry for the mess :-)
The desired protocol documentation is at http://wiki.portalmod.com/wiki/Control_Chain <http://wiki.portalmod.com/wiki/Control_Chain>
As I stated before, the Control Chain was initially thought on with Input ControlPorts in mind. Very simple: tell the hardware controller about the parameter he is controlling (we call this step addressing) and read the values it sends. 
I’ve attached a diagram with our desired software structure. The big cyan rectangle is the mod-ui, the “center” of the software and “owner”of the MOD's state. All messages are routed by the mod-ui.
These ControlChain messages today just make sense to the external controllers. We hope to model the entire IHM (man machine interface - the MOD built in controller) using the Control Chain protocol. We would also like to use the same protocol for the Javascript UI that is rendered in the browser. 
Also, with the focus on Input ControlPorts we lacked the ability to have monitors, like peak meters and so. Thus, the upgrade for full duplex.
Harry mentioned the will to make volume meters (on the JX-10 example) and also to have complex controllers like http://m-audio.com/assets/microsites/tfp/img/tfp_ortho.jpg <http://m-audio.com/assets/microsites/tfp/img/tfp_ortho.jpg> for Fabla or other similar plugin.
I think that having a good implementation for the Output ports (to indicate to the controller’s monitors what they should display)  shall solve these requirements, but I might be missing something here.
Hanspeter asked:
Is there a reason why the different behaviours need to be implemented
in the footswitch firmware directly?
And both Hanspeter as Harry mentioned the use of LV2:Atom but I don’t think we got the grip here of it yet. Is it possible to exemplify this better?
Hope to hear form you guys soon and thank you for the collaboration
Regards
Gianfranco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://portalmod.com/pipermail/developers/attachments/20141111/fc9dbe15/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MOD desired SW Structure.jpg
Type: image/jpeg
Size: 47221 bytes
Desc: not available
URL: <http://portalmod.com/pipermail/developers/attachments/20141111/fc9dbe15/attachment-0001.jpg>