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
