On Monday 24 November 2008 06:57:25 Garth Dahlstrom wrote: > 1. do as little work as possible within the internals of Mixxx, yet be as > flexible as possible (for all controllers, the first real controller will > be something like the Stanton SCS.3d)
What happens if you gain your flexibility by doing work in Mixxx? (or, wait, do you mean CPU work or programmer work? My idea doesn't impinge on CPU at all really) > 2. avoid anything that would break the midi learning stuff or make it or > tool-based another mapping approach significantly more complicated My thinking is that scripting would make tool-based mapping a lot harder. Programs generating ECMAScript? I think of it like this: without actually emulating a device, could you have a program show you all the possible buttons and modes a device can handle? With script, you can't. With declarative XML, you could have something that pops up a display showing a picture of the device, and all the possible functions any button could perform. > So... now it's my turn to ask some questions and explain how the current > proposal dodges them... :D OK :) > I understand mixing content and presentation, but I don't follow how it > applies here. A bad analogy on my part I think. > We aren't mixing mapping with behaviour, the two are still very much You have MIDI codes in the script. That is the essence of mixing them :) > Where does the behaviour that powers "mappingschange" get defined? Has to > either be an internal compiled-in behaviour or a script of some kind... Compiled in, definitely. Now, I'm assuming that the MIDI code in mix reads through the XML and fills variables/objects with the mapping information. I'm thinking that when a mode change occurs, you reinterpret the XML with a different mapping view selected, so in the things with selectable mapping, different button->function bindings get inserted into the data structure that holds that (or the objects that hold that info understand mappings, and you tell them what their new one should be and they just update. That would probably be cleaner). > What if company XYZ comes out with a new device that uses a slider to > change mapping modes based on different ranges (0..31 = fx, 32..63 = > bankswitch, 64.. 97 = loop, 98 .. 127 = cue point)? We handle the standard cases, guessing a bit, but say: * herc style button to cycle, * /n/-position knob (which is either implemented like a special-case slider, or like the herc pitch knob, so a direction control - depending on the hardware), * multiple separate buttons. for anything else, we thunk to script. If we find scripts are being used for certain things a lot, we pull that functionality into mixxx. > The proposed extension handles this by dumping the raw midi event to a > script, the script is still equally messy, maybe more so, but there is no > trace of that mess in the XML file. But it has to be somewhere, and it will cause maintenance headaches. Say you implement it for the 3-state cycling button. Now you have support for that, but only for the herc, you can't reuse that code for another device, or for a 4-state cycle. If you design it in a declarative way, you just need to add a new mapping name and button->function bindings, and the code that backs this will work across all controllers. > HerculesMk2.fx_cue_loop_button > HerculesMk2.fx_cue_loop_mode That seems clunky to me :( > Where would the state for this get stored in Mixxx? How will control > mapping XML know what state its in? Basically, for every mapping group, it has a simple state. Just an iterator that can be told to cycle through the defined values. > > <control mapping="fx"> > > <!-- stuff to apply to the button '1' when the mapping mode is > > 'fx' --> > > </control> > The guts of this are _extremely important_ for the implications of the > functions need to be compiled-in to support them... Not in this case, I was thinking of having it exactly like the current '1' definition, except calling the function appropriate for 'fx' mode. > Would their be some kind of reference to a compiled-in function? > Inflexible, needs recompile to change/extend... You can still have scripts. I think they're likely to be required. I just think that common cases should be declared rather than written, and that if we design our XML format around this idea now, it'll be easier than if we wait longer and there are lots of third party mapping file all over the place. > Would their be some <IF> type tags in there defining what to do? (mixing > mapping and behaviour? reusable across different controllers?) No. The idea of turning a declarative structure (the XML) into a procedural one (with 'if' and such) makes be twitch a little. Think of it like Prolog. > If so, we'd have to write some kind of interpreter to compile this to > script for execution or we'd have to represent this in some kind of logical > tree thingy I'm guessing. We could present the user some kind of > excel-like-function-wizard... Tree thingy is what I was thinking of. I'm assuming you load the XML and use it to populate a data structure. You just make that data structure aware of the mappings. When you switch mappings, and look up that structure to see what happens when button X is pressed, you interpret what it responds based on the context of the mapping, or alternately, it knows about the mapping, and so gives you the right response. Another way is that whenever the mode is changed, that structure is updated with the new mappings, but that seems less elegant and slower too. > > 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. > Where would the logic live? What would it look like? It would only be a small difference in interpretation when the XML is loaded. > 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? Programming is a strong word here :) I wouldn't consider XML scripting programming, in this case. You're just outlining the buttons, and in some cases allowing options based on something else. Of course, when you want properly complex, turing-completish behaviour, then you hook into a script. But I don't think it's needed for most simple cases. > As usual the devil's in the details. Yep :) -- 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
