>
> >
> > it might also be nice to have a builtin layer system with led recall.
>
> I definitely think this would be useful. I'm working with the Xone K2
> right now and although it has its own latching system there is also a
> mode where the lights and buttons are completely driven by software. If
> we had layers inside mixxx, basically any 2-deck controller could become
> a 4-deck controller.
>
ah yep, this is true. also the k2 is kind of odd that you have to send
different messages, not just different values, to select alternative
colours. i'm really not sure why they implemented it that way. i'm also
planning on getting a k2 soon.
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
> I think anything requiring a conditional is best addressed in
> javascript. Simple ANDs make sense inside XML, but once you get to IF
> and OR, things start to get supremely ugly.
> Do you think specifying two items in the option tag would be enough to
> get you the AND logic you need?
>
it should be, as that's all that traktor provides, but that's also why
traktor is so tricky to do anything but very simple stuff. in traktor you
end up duplicating a mapping several times over as you can only add two
modifier conditions and one value per modifier per mapping. i think we'd be
losing a trick if we limited it to the traktor mentality.
we could probably skip implementing OR's and just AND together all the
conditions. i.e: i don't see that this would be too bad to embed in the xml:
condition="modifier1 eq 1 && modifier2 gt 2 && modifier3 ne 3"
vdj just uses characters like ">" but then of course it has to xml encode
them. people do edit those by hand, but if we used perl's type of
stringified conditionals then we wouldnt have to.
i think it's important to be able to:
* name the modifers how we want, and then use by those modifier names in
any scripting (if any)
* check for a single value or a range of values in a condition
* string a number of modifier conditions together (would have to be more
than 2 else you can't check for ranges)
These are definitely good ideas but I'm trying to keep a narrow focus
> for the moment. Maybe we should start a wiki page for MIXXXML 2.0 :)
cool sure. i'll shut up on that for now then and not even mention that i
think that we should normalise the midi and hid xml files in some way ;)
------------------------------------------------------------------------------
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
