>
> When you use their own latching mode you can set values for lights that
> are on the inactive page. When you switch to that page, they'll already
> be on. It's a really nice system because it means the host app doesn't
> need to know anything about the latching system.
>
yep, that is quite cool, but i still wish they had allowed colours to be
changed by value/velocity. it means you can define a single name for each
button (like i did in my novation launchpad mixx mapping) and a set of
colours and then just do something like:
led("button1", "yellow")
which then works out the values for those and calls midi.sendShortMsg()
if we had a generic led() function like that to send data back to the
controller by name then a controller like the k2 would need to overload
that with it's own one, as "button1" would be different values depending on
what colour was to be sent, as opposed to being static and the colour value
changing.
> > my midimasher app supports multi layers/pages with full led recall for
> > page switching and i implemented a dumbed down version of that in my
> > launchpad mapping since it only had to deal with the one controller.
> > it would be quite nice to have that functionality in the engine. my
> > midimasher code just stores the last value sent out for any note/cc/pc
> > for each midi channel and when you select a new page returns just the
> > list of values that are different between those two pages. the
> > launchpad also needs it's own custom function to send out those values
> > due to it's internal bank switching that implements flashing colours
> > and is also used to make the page switching *appear* instant
>
> Very cool. Generalizable stuff like this really does sound like it
> shouldn't need to be reimplemented by every controller configuration.
>
cool, sure. if it might be of use to other controllers i could work that
code into the engine if people thought it would be useful.
> > condition="modifier1 eq 1 && modifier2 gt 2 && modifier3 ne 3"
>
> This makes me physically cringe. I appreciate the hack, but barf.
>
i do see your point :) from an xml pov it's pretty nasty... vdj and djdecks
allows code to be embedded within CDATA blocks tho, as well as referring to
external javascript files. mixxx already has it's own mechanism for mapping
javascript functions to the <key> element so maybe just do the same kind of
thing for conditions?
> Maybe the solution is to do something a little different:
> <options>
> <condition="somejavascript.function">
> </options>
>
> When the button is pressed, the event is only activated if the specified
> javascript function returns true. And no, you wouldn't be able to write
> arbitrary javascript statements inside those quote marks :). That might
> even be too much, though. It might make more sense to just do the whole
> thing in scripting.
>
i should have read further before my last comment :) would make sense in
your example i guess for condition="name" to be the same style as <key>
where it maps to a function within the defined prefix for the controller.
that would work pretty nicely...
so the user can either go the full hog and map <key> to a function, the
simple route of <key> to an engine control, or the half way house of
mapping <key> to an engine control and also <condition> to a function?
i guess the only gotcha would be how/where to store these condition
functions if they were entered via some pulldowns in the controller config
gui? i.e: we wouldn't want to go automatically editing the same JS file
that the user is editing.
maybe add an extra javascript file into the mapping like this?
<scriptfiles>
<file filename="Novation-Launchpad-scripts.js"
functionprefix="NovationLaunchpad"/>
<file filename="Novation-Launchpad-conditions.js"
functionprefix="NovationLaunchpadCond"/>
</scriptfiles>
still can't guarantee that the user won't manually edit it and break
something though.
most of the time people just need some simple "if this and this and that"
type expressions. so long as they can be entered via pulldowns or something
in the gui then maybe it doesnt matter too much how they are
implemented/stored internally? they could/should be stored and evaluated in
the engine per controller?
scripting could get hold of the actual modifier values and set them like
described in the wiki, but not the actual conditional expressions defined
via the gui, and they probably wouldn't need to anyway?
By the way, what's an example of a command that needs that amount of
> logic? I don't quite understand the use-case for testing ranges and
> such.
>
ranges are probably less common than "not equal to" expressions. i remember
i really needed ranges a few times when mapping directly in traktor, but i
haven't done that in a long time. the reason for needing ranges was
probably due to only being able to depend on two modifiers per expression
and only being able to say "cond1 AND cond1". if we could say "value is X
OR value is Y" then we wouldn't need ranges anyway though probably.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
