My spidey sense tingles a little when I hear talk of dropping XML configuration in favour of a scripting approach, particularly because of the accessibility and maintainability aspects...
I think a scripting only or scripting primarily approach would take us in a direction away from being able to drive configuration through the use of tooling (i.e. MIDI training or mapping controls through diagramming). I do however see merit in having scripting a part of the configuration process particularly for handling mode changes in controller hardware, where buttons are dynamically mapped from one set of functions to another... Earlier this week I started reading up on some stuff that trolltech put out about SCXML (http://labs.trolltech.com/blogs/2008/11/08/entangling-the-signal-slot-spaghetti-with-scxml/). That implementation makes use of Qt scripting to hook both signals and slots, I'm intrigued by the potential to represent controller state (button mode) through use of a UML state chart and then transform it into a scxml mapping file (http://www.kotikone.fi/00/SCXML/ ArgoUML -> SCXML) that could be used directly by an application, I'm convinced that such an approach is possible, however I'm not sure yet to what extent pursuing it would be like using a nuclear bomb to kill a fly. It would depend on how complicated it would be to do and whether a diagramming approach would be well received by users and hardware vendors. Anyway, my thoughts on the matter are far from complete at this stage... -G On 11/13/08, Adam Davison <[EMAIL PROTECTED]> wrote: > Hi, > > So I promised I would think about this and now I have a bit. So here > is where I got to in my head. Feel free to shout and complain about > all of this since it's just ideas so far. > > The more I think about this combined XML/script mapping concept, the > more I think the XML part is kind of redundant. > > This is not to say you'll have to code a function for every message > you want to handle. In fact the whole design of the script stuff will > be geared to avoid executing script where possible. > > Basically I think we should have some script API something like this: > > midiConnect(Source, Processor, Destination) > > Where processor can be null, source is a filter of some kind that > returns events you're interested in and destination does whatever you > like but generally it's going to write the value to a controlobject > you specify in the constructor. > > Then for guys doing basically static mappings we provide some > convenience functions like: > > midiConnect(midi1, midi2, processor, group, value) > > which then creates some defaulty things and makes life really easy for > porting. We provide all the existing option constructs as processors. > Source is there as a generalisation in case you want to handle SYSEX > messages or something else crazy. > > Also it occurs to me that because Qt has nice support for connecting > signals and slots across the interpreter/C++ interface we can probably > generalise this stuff to some extent so that it's easy to use C++ > objects as as processors and sources and then when you want more > customisability you write your own in script and stick them in > instead. This way 99% of midi events can be handled without ever > invoking the interpreter hopefully. It probably helps if we ever want > to change language or support multiple ones also. > > So all current static XML mappings would become basically just a list > of midiConnect functions in a script to be executed. We need to be a > little careful when changing mappings to destroy all the current > stuff. > > Then a more complex one would look something like this: > > def fancymaths(float input, float old, ...): > return sqrt(input); > > midiConnect(0x80, 0x23, FunctionProcessor(fancymaths), "[Master]", > "crossfader"); // Custom processing > midiConnect(0x80, 0x24, null, "[Channel1]", "gain"); // No processing > required > midiConnect(0x80, 0x25, Namespace?::Invert, "[Channel1]", "..."); // > Processing using builtin C++ object > > Then midiConnect just does something like connect a load of QObjects > together and let the signals make the magic happen. > > So, the important question is does this sound insane? Or like > something people would be happy working with? Do you have a different > proposal which you think would work better? Or perhaps you have some > ideas for improving this one. Whatever your thoughts please express > them :) > > Overall I think a model like this gives up enormous flexibility and > probably makes us pretty much ultimately future proof for control via > the CoolTech MIDI Exercise Bike 2015 or whatever. > > Adam > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > -- Sent from Gmail for mobile | mobile.google.com __ --- == __/ t.O ==-- http://stacktrace.org/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
