I like this idea of having storage available for extensions. Let me just throw out a couple thoughts as people consider what makes the most sense…
I’ve written a couple different control surface extensions, and there are a couple of broad types of data that they need to store:
-
global configuration data - e.g., which midi device to connect to, layout information (e.g. is your MCU an x-touch, an Icon M, a Presonus FaderPort), other user preference information
-
rackspace/variation specific data - e.g., for widgets grouped in banks, which banks should be active on the control surface when the variation/rackspace is engaged
-
widget specific data - e.g., what color should the knob appear on the control surface, what RGB on/off color for individual buttons, how should the controls be grouped for bank switching, etc.
The “global” stuff seems suited to this XML stream approach, but I’m not sure it works for the Rackspace and widget specific stuff.
As it is now, I store all of this information in text widgets. Nice things about this are that it’s easy for users to access, edit, and troubleshoot, you can hide the configuration widgets, it’s all automatically copied when you duplicate a rackspace, and it’s all automatically gone when you delete a rackspace.
The two downsides are that you have to create a lot of extra widgets, and I end up using things like widget fill color, outline color, and caption to cram information in that isn’t intuitively obvious. e.g., for RGB buttons I use fill color for “button on” color, outline color for the “off” color.
In my long-term dream for extension data storage I’d be able to link those directly to the “thing” they should relate to. e.g., for button on and off colors it would be great if I could attach “tags” to button widgets something like “SLMK3 off color: #454500”. I’d really love it if those would appear on the “Advanced” tab when editing widgets, or perhaps a new tab called “Tags”. It could just be an XML text box where users could edit things, or maybe just force it to “tag” and “value” pairs so users don’t accidentally butcher XML formats.
I imagine something similar could be done at the Rackspace or Song level if appropriate.
While it’s certainly possible to stick all this information into one global XML stream I think it would be cumbersome and error prone for the extensions to handle it that way. e.g., the extensions typically only “see” the current rackspace, so when it builds a widgetlist and configuration data for them it would have to store them in the XML using those widget names. But other rackspaces may use those same widget names, so the extension would need to store data using both the rackspace name and the widgetname. But now suppose you change the name of a rackspace while the extension isn’t active? When the extension is active again it’s looking for the data under the old rackspace name and it’s not there, so all your configuration data is effectively lost. I regularly share networks stored gigs across three machines.
There is also an unaddressed “need” right now to have a way for multiple extensions to share control access to the same widgets. e.g., suppose I wanted to use the Radio Buttons extension while using an MCU control surface extension? Both extensions require the widgets to be named a certain way (using the OSC/GPScript name) to be able to use them. Widgets can’t have two names, so only one can access them at a time.
If we were able to create and store “tags” on a per widget basis then multiple extensions could share the same widgets.
I like the idea of an XML stream for storing “global” data, but just want to note that it’s probably has some limitations. To the extent the ambitions for extensions are ambitious, it may be worth thinking about whether that should guide the initial steps.