Hi everyone,
Here's the first part of this discussion. Basically we're discussing
how to handle MIDI devices that have some degree of state machine in a
manageable way. Specifically in this case Stanton stuff.
Adam
---------- Forwarded message ----------
From: Adam Davison <[EMAIL PROTECTED]>
Date: 2008/11/10
Subject: [Fwd: Re: Mixxx MIDI device mode switching]
To: Adam Davison <[EMAIL PROTECTED]>
So what I had in mind was something like this:
<controls>
<control>
// Traditional control guy, just maps onto controlobject
<options or whatever...>
</control>
<control>
// Untraditional guy
<type>Ctrl</type>
<channel>1<... all the usual stuff
<handler>StevesModule::handleThisGuy</handler>
So for the untraditional guys you don't connect them normally, you
just do them entirely in script, so you write something like:
selecteddeck = 0
function getrightvolume():
if (selecteddeck == 0):
return getControlObject("[Channel1]", "volume")
else:
return getControlObject("[Channel2]", "volume")
function handleDeckSwitchButton(...some values from midi message...):
selecteddeck = buttonstate
function handleChangeVolumeKnob(...more values from midi message...):
getrightvolume().set(knobstate)
midiledhelper.set(volumeledhere, somevalue)
If that makes any sense. So you manage all your own state in your own
little module and add no code to mixxx basically.
For something as complicated as the SCS stuff, it may be that you
basically can't connect anything directly to a control object because
you want everything to be remappable and so on. If this is the case
you're basically going to end up writing an xml file which maps every
control onto one function which then does lots of magic. If this is
the case it may be better to allow something like:
<controls>
<globalhandler>SeansCode::superCoolSCSMapper</globalhandler>
</controls>
EOF
and something like:
function superCoolSCSMapper(stuff...):
switch(code):
case '0x04': // Crossfader
do stuff
It would also be really nice if we could replace the current <options>
thing with calls to some of these function, so you can also write
something like
<control>
<blah..>
<option>myspecialscalingfunction</option>
But this <option> and <handler> concept are very close together so
maybe it's just sensible to do away with option altogether and just
come up with some rule like, if it's connected then the return value
of handler goes to the control object. This means you don't have to
deal with control objects in every handler. But then handler is a
really bad name. Or maybe we pass a controlobject pointer to handlers
if an appropriate one exists.
Anyway. I said a lot of stuff there :) Does it answer any of your
questions? I hope so...
Adam
Sean M. Pappalardo wrote:
>
> Hi again.
>
> Adam Davison wrote:
>
>>
>> Once that's done, you can implement your entire state machine as some
>> pluggable bit of code which just comes with the midi mapping for the
>> controller.
>>
>
> That's exactly what I was envisioning. My only question is how would
> groups of inputs/outputs work? Let me explain:
>
> When I said:
>
>>>>
>>>> So as far as Mixxx is concerned, a mode change (B1-B5) goes like
>>>> this:
>>>>
>>>> 1) Receive data that B2 (EQ) was touched
>>>> 2) Set EQ mode internally (in some "device mode" variable that affects the
>>>> MIDI input and output groups below)
>>>> 3) Send MIDI command to unit to configure the surface for EQ mode (3
>>>> sliders)
>>>> 4) Switch MIDI input "group" to EQ (listen for slider touches
>>>> tied to filterLow/filterMid/filterHigh.)
>>>> 5) Switch MIDI output "group" to EQ (3 LED columns in boost/cut
>>>> mode tied to filterLow/filterMid/filterHigh.)
>>>>
>
> Obviously step 1 is handled by the XML as currently, steps 2 & 3 by the
> script code, but steps 4 & 5 I imagine would be defined in the XML but
> activated by the script code, if that's possible. E.g. Could the XML
> look like below?
>
> <controls>
> <control>
> ... (EQ mode button)
> <options>
> (Script to activate controlgroup2 & outputgroup3,
> deactivate others)
> </options>
> </control>
> <control>
> ... (Deck button)
> <options>
> (Script to change channel # on all control <group>
> mappings)
> </options>
> </control>
> ...
> <controlgroup1>
> <control>
> ... (Trigger pad 1, no script needed)
> </control>
> <control>
> ... (Trigger pad 2)
> </control>
> ...
> </controlgroup1>
> <controlgroup2>
> <control>
> ... (EQ slider 1)
> </control>
> <control>
> ... (EQ slider 2)
> </control>
> <control>
> ... (EQ slider 3)
> </control>
> </controlgroup2>
> ...
> </controls>
> <outputs> (formerly "lights")
> <output>
> ... (Deck LEDs)
> <options>
> ... (Script to check the variable & light the
> correct LEDs)
> </options>
> </output>
> <output>
> ... (Track name display)
> <options>
> ...
> </options>
> </output>
> ...
> <outputgroup1>
> <output>
> ... (Trigger pad 1 LED, no script needed)
> </output>
> <output>
> ... (Trigger pad 2 LED)
> </output>
> ...
> </outputgroup1>
> ...
> </outputs>
>
>
> Adam Davison wrote:
>
>>
>> Also, we could even introduce some Qt binding and encourage scripts to
>> create device-specific configuration windows and error messages for
>> debugging and so on.
>>
>
> That's perfect. I was going to ask about that too, since for example the
> SCS.3d's MIDI channel can only be set via a SYSEX message. (Would we
> need new XML tags for these dialog scripts?)
>
>
> Sean
>
> <<--------------------------------------------------------------------------------->>
> This E-Mail message has been scanned for viruses
> and cleared by >>SmartMail<< from Smarter Technology, Inc.
> <<--------------------------------------------------------------------------------->>
>
-------------------------------------------------------------------------
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
