The idea of having the script embedded in the XML does appeal to me for the
aspects of making distribution simpler. I think it *might* make the job of
maintaining the XML file programatically more difficult, but I'm not really
sure nor am I sure it would make it that much more difficult that it
wouldn't be worth it.
I guess the thing to consider with respect to the "MIDI Learning" code is
only scoped to map a controller signal to some function, you will not be
able to teach Mixxx what to do through with that signal (it is not some
fancy macro recording language or anything like that). So, no matter how
you do the "MIDI Learning", you are still going to have to go in by hand and
edit some QtScript to enhance behaviours beyond the currently compiled-in
functions. Ah shit, I wish his branch was merged already... then people
could just see how it works and where it ends.
So having script embedded in the XML means that humans and machines will
both be editing the same file. Maybe that isn't a problem though. Maybe
we should do it this way...
On Mon, Nov 24, 2008 at 12:20 AM, Russell Ryan <[EMAIL PROTECTED]> wrote:
>
> I have a few comments and questions on this this spec draft:
>
> http://mixxx.org/wiki/doku.php/midi#midi_extension_proposal_2008-11-23_draft
>
> 1) Where is the 'library' of QtScript stored? Is it one giant library
> for all controllers, or is it a script file per device?
>
> Would it be more simple to have the script for a device stored inside
> the same XML file for the device?
>
> i.e.
>
> <controller>
> <script>
> ... QTScript definitions for controller ...
> </script>
> <control>
> <group>[Channel1]</group>
> ...
> </control>
> <control>
> ...
> </control>
> ... etc ...
> </controller>
>
>
> That way, the entire controller definition is self contained and much
> easier to understand because everything is in one place.
>
> Imagine the use case of a new controller definition that isn't included
> in the release yet.
>
> If someone posted it to the forums, then they would have to include an
> updated version of the library that had the relevant script. (and if
> someone had customized their library or added other definitions, then
> they would have to hand merge the two libraries, yuck!).
>
> If there are two files for one device (one script, one xml), then the
> mapping author has to post two files, and you have to make sure two
> files make it into your Mixxx distribution. One file just makes things
> much easier / simpler.
>
> 2) Hopefully Tom's MIDI rewrite/rework and this work that is going on
> will last Mixxx far into the future in terms of the hardware of
> tomorrow. I think that allowing scripting like this is a safe and
> extensible way to add lots of flexibility.
>
> A good example of the 'hardware of tomorrow' is the JazzMutant Lemur :
> http://www.jazzmutant.com/lemur_overview.php
> Basically, what is the next new thing and how can we future proof
> against it?
>
> 3)
> My only worry for MIDI-Learn is something like this:
>
> My FooBaz controller already does X in mode A, Y in mode B, and Z in
> mode C. I want to change what it does in mode C only. How are we going
> to support something like that? That isn't a terribly unreasonable thing
> to want. Especially in the case of a single turntable control surface
> which has a button to switch from being turntable 1 to turntable 2, so
> the entire device is mode-based.
>
>
> That's all! Good job everybody it's really exciting to see all of the
> great things on the road ahead.
>
> Cheers,
> RJ
>
> Adam Davison wrote:
> > Hi,
> >
> > I think I was one of the original people criticising the idea of
> > making the parsing of the XML more dynamic. My reasoning for this was
> > that you're basically about to go and implement an interpreter and
> > every time we need an additional feature, the interpreter gets more
> > complicated, until you have basically a programming language. At that
> > point we've spent all this time where we could have used an existing
> > language and we probably also didn't design our interpreter as well as
> > the ones that already exist either.
> >
> > Try to think of this design as an extension of the existing options
> > block. Where currently you're choosing from a list of builtin
> > functions, here you would be choosing from some combination of builtin
> > functions and script you wrote yourself.
> >
> > This is a very simple extension of the current midi mapping scheme,
> > allows for a lot of new behaviour but without too much work to be
> > done.
> >
> > Obviously this doesn't have to be the end of it but I'm not sure that
> > any of us really has a complete understanding of how the final
> > solution to this problem should look. So it's a good stepping stone to
> > seeing how a really good API for MIDI mapping might look. And for now
> > you can theoretically stuff basically infinite complexity down it's
> > throat too, pretty or otherwise.
> >
> > Adam
> >
> > 2008/11/23 Robin Sheat <[EMAIL PROTECTED]>:
> >
> >> 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
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> 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
> >>
> >>
> >>
> >
> > -------------------------------------------------------------------------
> > 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
> >
>
>
> -------------------------------------------------------------------------
> 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
>
--
__
--- == __/ t.O ==--
http://stacktrace.org/
-------------------------------------------------------------------------
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
