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.
Just a bit of nay-saying, sorry :(
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 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">
<!-- 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>
<control mapping="fx">
<!-- stuff to apply to the button '1' when the mapping mode is 'fx' -->
</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.
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.
--
Robin <[EMAIL PROTECTED]> JabberID: <[EMAIL PROTECTED]>
http://www.kallisti.net.nz/blog ||| http://identi.ca/eythian
PGP Key 0xA99CEB6D = 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- 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
