This is my deadly attempt to migrate this discussion to mixxx-devel. I'll send an explanatory e-mail shortly.
2008/11/10 Adam Davison <[EMAIL PROTECTED]>: > Hi Sean, > > Obviously this whole scripting thing is a slightly larger project so I > understand you're keen to stick to a simpler solution, I'll try to explain > my thinking a bit. > > This is certainly not the only way to handle this problem, however the thing > that I would like to avoid is that we implement some variable in mixxx that > holds a group and allow a midi control to switch it between "Channel1" and > "Channel2" and then allow other midi controls to act on that group and > everything works great. Then next week Steve comes along with another > controller that has that and one more thing that switches modes and so we > add another variable and so on and we're back to basically coding support > for the controllers in C++ and the xml being there is basically a waste of > time. > > For this reason I would prefer us not to accept code unless we can see that > clearly this is going to be useful for lots of controllers, rather than it > being code that just makes this particular one work. > > It is however a reasonable point that if you just do script then you end up > basically doing a lot of tedious mappings which are basically just what the > xml was doing for you before. If we want to avoid using full scripting for > at least some things, then clearly we need to add some more programmability > to the XML. Maybe the answer is that you provide ways to hook to handler > functions and then provide some useful defaults to do things like store some > state variable and act on it. Maybe something else... I'm thinking... > > Thoughts? > > Also, if you don't mind I'm going to try and move this onto mixxx-devel > since this should probably be public discussion. If you could reply to that > thread then that'd be handy. > > Thanks, > > Adam > > Sean M. Pappalardo wrote: >> >> Your ideas sound great and will work well for future devices too. >> >> Are you saying that it's not possible to have selectable control groups >> (comprised of traditional control/light mappings) in the XML file? If >> not, can the active XML file be changed or swapped on-the-fly? >> >> While I'm not opposed to a monolithic script that handles everything, >> I'm trying to leverage the static mapping abilities of the current XML >> to avoid many static mappings in the script (and allow end users to make >> tweaks more easily, say to change LED color.) >> >> Imagine the SCS.3d as five separate fixed controllers, each with static >> MIDI mappings, able to be handled by the current XML format. (In fact I >> will be testing with five such XML files for the time being.) The only >> controls that require special handling are the mode & deck select >> buttons, of which there are only six. (Even in these cases, they need >> only change the active control group and fire a command to the device.) >> So the thing looks like just another static controller except during a >> mode/deck change. >> >> Is a monolithic script the best way to handle such a device? Or are you >> saying it's the only way? >> >> >> Sean >> >> >> <<--------------------------------------------------------------------------------->> >> 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
