Hi again. Since I'm a newbie, please correct any of my misconceptions below!
Garth Dahlstrom wrote: > On Sun, Nov 23, 2008 at 7:32 AM, Robin Sheat <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: >> 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. I think what Robin's referring to is that the new XML mapping still has <miditype> and <midino> when there are separately defined MIDI codes within the script. Let me try to clarify based on my understanding: the regular XML mapping specifies what MIDI event to listen for (as currently,) the only change is allowing triggering a script on that event. At that point it's up to the script to do the rest, which will likely involve other MIDI commands & events, so must be separately defined. Take the fx/cue/loop example: MIDI note 7 triggers the behavior according to the XML, while the script operates on other MIDI notes. So you really need to have MIDI codes in both places: one for listening, the other for processing. > 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. This sounds like he might be thinking of having all the simple mappings in the XML and use script to simply select which ones are active based on the current mode, like the <controlgroups> and <outputgroups> I proposed in https://sourceforge.net/mailarchive/message.php?msg_name=18f1a7640811100658j350012c2k4214c3e6abf96bce%40mail.gmail.com But the problem with that idea seems to be that XML is static and you can't activate & deactivate certain portions conditionally, hence the need for scripting to handle anything that is at all dynamic, even if we're just talking about switching between otherwise simple controls. > Would their be some <IF> type tags in there defining what to do? > (mixing mapping and behaviour? reusable across different > controllers?) See now this idea ties into the above for controllers like the SCS.3d which are basically 5 otherwise static controllers in one, swappable between decks on the fly. So for now, adding <if> & <currentstate> tags and a <stateset> directive would make me happy. But future-proofing requires scripting, such as for tuning jog wheel & slider sensitivity or working with re-mappable alphanumeric LCD displays. > 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? Having to recompile Mixxx to support new controllers (or even tweak existing ones) is totally not an option as far as I'm concerned. Meeting this goal will allow many more controllers to be supported in record time since end users (who aren't afraid of a little scripting) can write all the control logic and test it immediately. And other users can tweak the settings to their liking very easily without having to know a thing about building the software. I'm just waiting on final decisions so I can get coding! :) Sean M. Pappalardo "D.J. Pegasus" <<--------------------------------------------------------------------------------->> 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
