Boolean Controls in CLAM
After a long refactoring to get typed controls into clam without breaking anything, we already have them. Kudos for this achievement go also to Francisco (who started the whole thing as its GSoC project), Hernan, Nael and Pau.
Now controls are defined just like ports with a type. So for example, you can define an out control being the type OutControl<MyType>. As a side effect, control callbacks came in natural way. Instead of using a different class (formerly InControlCallback<MyType, HostProcessingType>), now you just have to pass a processing method to the control constructor. Templates do the magic too, but that is hidden from the processing programmer API which is cool. See, some example bellow.
So, once we enabled typed controls working, now is time to have more than just float controls. The main problem now is that in order to get some useful new control type you have to modify the network editor and the prototyper to make them useful.
Although the most demanding needs are for enum and integer controls, I started with simpler bool controls. My goal is you don’t have to modify the NetworkEditor or the Prototyper to introduce a new control type. That is, a plugin could add new control senders, control displays, default connected processings (double clicking on a control) and binders for the prototyper (to locate ui elements to link to processing controls). So i wanted a new simple use case not being float to explore a feasible API.
Below you can see a network with a BoolControlSender
(widget hxx /
cxx,
processing hxx,
cxx) and
a BinaryCounter
(hxx,
cxx)
outputing into two BoolControlDisplay
(widget hxx /
cxx,
processing hxx,
cxx).
Maybe is a little late for using CLAM for your Christmas lights, i guess ;-)
Currently, instead of bools we use floats considering a threshold for being true or false.
A new ControlGate processing provides a transition by doing such translation:
So now is time to look to the code I had to add and see what can be enhanced to ease adding new control types:
- One of the things I didn’t liked during the implementation is having to add an entry into a long list of ‘if’ statements in ProcessingBoxEmbededWidget.cxx. This is clamming for a refactoring into a Factory.
- Also the menu entry filling (to connect to new processing) and the default create-and-connect action become a list of if clauses with the type as parameter.
- Both, prototyper binders and embedded widgets had to duplicate the control sending code. That could be generalized into a binder object that both use.
So, it is clear that there is room for a lot of enhancement and it looks like those enhancements could also be applied to ports as well :-)