Yes, your post is good stuff... now I need to explain the motivations for
the approach I propose and its laziness...
Some counter-objectives:
1. do as little work as possible within the internals of Mixxx, yet be as
flexible as possible (for all controllers, the first real controller will be
something like the Stanton SCS.3d)
2. avoid anything that would break the midi learning stuff or make it or
tool-based another mapping approach significantly more complicated
First let me say, we may end up with something like you propose eventually,
I don't know, but for right now we are looking to extend what we have.
So... now it's my turn to ask some questions and explain how the current
proposal dodges them... :D
On Sun, Nov 23, 2008 at 7:32 AM, Robin Sheat <[EMAIL PROTECTED]> wrote:
> On Monday 24 November 2008 00:19:25 Garth Dahlstrom wrote:
> > I've thrown together some of my thoughts into a proposal document, using
> > the Herc Mk2 FX/Cue/Loop as the primary use case (it's a relatively
> simple
> > controller)... It covers mostly how things work from a configuration
> > perspective (hooking xml -> script), it briefly mentions where changes
> will
> > need to be made to make it go, but doesn't give much detail.
>
> I don't know I like the idea of requiring scripting for this kind of
> thing.
> It's doing the mapping equivalent of mixing content and presentation. For
> example, you have MIDI codes in both script and XML.
>
I understand mixing content and presentation, but I don't follow how it
applies here.
We aren't mixing mapping with behaviour, the two are still very much
seperated. Mapping is done in XML, with a reference to behaviour... Just
as it has always been done. The only difference is we are proposing
mapping out some of the controls to a dynamically loaded behaviour found in
a different .js file rather then statically compiled-in functions such as
"play", "cue", "nextTrack", etc.
I prefer a more declarative structure, with the option to fall back to
> scripts
> for more complex stuff. Done right, you could have all your different codes
> and behaviours in the XML, with either some standard hooks to let the
> mapping
> change in common ways (like cycling through options), and put some script
> calls in only where necessary.
>
> I've done a bit of work with OpenLaszlo and Ant, it's that kind of thing I
> have in the back of my mind.
>
> For example (this is ignoring the script stuff, because I need to go to bed
> soon):
>
> <control>
> <group>[Channel1]</group>
> <miditype>Ctrl</miditype>
> <midino>7</midino>
> <midichan>1</midichan>
> <controltype type="mappingchange">
Where does the behaviour that powers "mappingschange" get defined? Has to
either be an internal compiled-in behaviour or a script of some kind...
What if company XYZ comes out with a new device that uses a slider to change
mapping modes based on different ranges (0..31 = fx, 32..63 = bankswitch,
64.. 97 = loop, 98 .. 127 = cue point)?
Say its compile-in, that means you need to create a new hook
"mappingschange_slider" and add all kinds of range values to your mapping
names, it also means that users will have to wait for another version of
Mixxx before they can use this function or compile their own, and if it
doesn't work the way they want it to they will have to submit a patch to the
C++ code to have it changed.
The proposed extension handles this by dumping the raw midi event to a
script, the script is still equally messy, maybe more so, but there is no
trace of that mess in the XML file.
<control>
<group>[Channel1]</group>
<key>Xyz.mode_slider</key>
<miditype>Ctrl</miditype>
<midino>7</midino>
<midichan>1</midichan>
<option>
<script/>
</option>
</control>
When presenting this to a user to create a mapping, all of the existing
complied-in methods would be presented along with all of those functions in
the library as "key" values, after being parsed from the library .js (equiv
of $(egrep -e "=.*function \(msg\)" library.js | cut -d"=" -f1 | sort) --
but done properly using Qt's script engine).
So this would be available as mappable combo box of keys for a control in
the learning dialog:
play
cue
nextTrack
...
Generic.stop_and_recue_button
HerculesMk2.fx_cue_loop_button
HerculesMk2.fx_cue_loop_mode
Xyz.mode_slider
> <!-- when this button is pressed, the mapping for channel one cycles
> through
> these. It starts on 'cue', otherwise it would start on the first listed -->
> <mapping name="fx" />
> <mapping name="cue" default="true" />
> <mapping name="loop" />
> </controltype>
> </control>
>
Where would the state for this get stored in Mixxx? How will control
mapping XML know what state its in?
Proposal would dump the state into a variable in the QtScript name space.
Save the mode toggle:
>> HerculesMk2.mode_store[msg.channel] = mode;
Retrieve in the fx button execute:
>> if (mode == 0) { HerculesMk2.fx_cue_loop_mode(msg); mode =
HerculesMk2.mode_store[msg.channel]; }
<control mapping="fx">
> <!-- stuff to apply to the button '1' when the mapping mode is 'fx'
> -->
> </control>
>
The guts of this are _extremely important_ for the implications of the
functions need to be compiled-in to support them...
Would their be some kind of reference to a compiled-in function?
Inflexible, needs recompile to change/extend...
Would their be some <IF> type tags in there defining what to do? (mixing
mapping and behaviour? reusable across different controllers?)
If so, we'd have to write some kind of interpreter to compile this to script
for execution or we'd have to represent this in some kind of logical tree
thingy I'm guessing. We could present the user some kind of
excel-like-function-wizard...
Proposal dodges putting logic in there
<control>
<group>[Channel1]</group>
<key>HerculesMk2.fx_cue_loop_button</key>
<miditype>Ctrl</miditype>
<midino>15</midino>
<midichan>1</midichan>
<options>
<script/>
</options>
</control>
<light mapping="fx">
> <group>[Channel1]</group>
> <type>indicator</type>
> <!-- midi details -->
> <!-- this light is turned on when the 'fx' mapping is activated, and
> turned
> off when it's deactivated -->
> </light>
>
> Alternately, you could wrap all the controls in a 'map' element, so that
> each
> control and light doesn't have to know its own mapping. That makes some
> sense.
>
Where would the logic live? What would it look like?
> Ideally, we'd also have definitions for button and LED names so we didn't
> have
> to reproduce all the MIDI codes every time, and then we'd just call them by
> name, but that can come later ;) Actually, if you could end up breaking
> down
> the controls to be more semantic, you could do:
> <control>
> <group>[Channel1]</group>
> <button>playKillHighs</button>
> <command name="play" />
> <command name="filterHighKill">
> <option>fadeout</option>
> </command>
> </control>
>
> <button>
> <name>playKillHighs</name>
> <!-- midi and other low-level details -->
> </button>
>
> for those times where you just need a button to play and fade out highs :)
> But, my point is that this would give you more flexibility, and a better
> designed file (which in turn could make learning functions more powerful).
>
> I think that code snippets should be avoided as much as possible. They
> spread
> out where information is, they are hard to autogenerate for MIDI learning,
> they create a higher entry barrier for people creating definitions, they
> require another language to be learnt, and, in general, they're
> unnecessary,
> especially for common functions.
>
There is no avoiding having people learn to program in order to program midi
state... The question is, do they learn C++, excel-function-wizard, XML
script, or QtScript/EMCAScript/Javascript?
As usual the devil's in the details.
-G
-------------------------------------------------------------------------
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
