Hey JP,
On Mon, May 27, 2013 at 6:32 AM, <raskolni...@es.gnu.org> wrote:
> HI RJ,
>
> When you say that the XML is good for usabiity, do you mean because you do
> not consider editing a XML file as "writing code", or because it is
> automatically edited by Mixxx preferences GUI?
>
>
I wouldn't consider writing XML as writing code (but it's just as bad
usability wise). What I meant was that using structured representation of
the mappings allows the users to add/edit/remove them via the GUI and then
share the results with other Mixxx users. A non-technical person should be
able to map (or re-map, staring from an existing preset) their controller
with either a wizard or a table and share that preset on the Mixxx forums.
In a future version of Mixxx users will be able to share and download
presets from mixxx.org from within Mixxx -- we have a Google Summer of Code
student working on this project. I think this will lower the bar in terms
of how people share and collaborate on presets. Lowering the bar to sharing
does no good if the bar for authorship is higher than ever (requires
programming knowledge or the ability to edit an XML file).
> In the later case, it could still be used internally, but get rid of it
> for scripting purposes, where it adds a lot of noise and makes the scripts
> hard to maintain.
>
Ideally if a control does not require scripts then it should be mapped via
XML. This is the most efficient and low-latency way to process input from a
controller. Using script add to input processing latency since the
Javascript VM has to be invoked.
>
> Also, for the performance argument, that convinces me that we really need
> an API like this:
>
> engine.connectMidiToControl(status, midino, group, control, options);
> engine.connectControlToMidi(group, control, status, midino,options);
>
> If I want some control X just to be enabled when button Y is pressed, I
> should do this with scripting, but there is no reason why X messages
> should not be processed in the same way as XML-configured values.
>
I disagree -- the XML mappings already have tons of options for how to
interpret messages and cover the common cases. In this case, the connection
should be made in the XML so that it is editable by the user without
editing the script.
> Anyway, your email convinces me that my approach is conservative and good.
> The XML file is still there, it is just generated. And the XML contains
> direct-bindings whenever possible, so there is no general performance
> loss. Also the use of literate programming and a very declarative API
>
might lower the barrier to scripting for non-advanced users.
>
Well, it depends on what you imagine for generating the XML. Is this a
utility that allows for easy authoring of scripts that generates the XML/JS
once and then the XML/JS is distributed or is this something that generates
the XML every time? A few tools already exist for the former (and that's
mostly fine though if the author wants to re-integrate changes made by
other community members then they have to do it by hand) but the latter is
not OK since it is not editable by a user without changing the script that
generates the XML.
Best regards,
RJ
> Cheers!
>
> JP
>
>
> > 1) It's valuable to have a structured representation of the mappings.
> Code is a black box and Mixxx has no visibility into it. This means that
> mappings expressed purely in code are not manipulatable by Mixxx. It
> doesn't matter what the declarative format is (JSON, YAML, XML, etc.)
> but a practical consideration is that breaking compatibility with the
> extensive set of controller scripts in the wild would be an extremely
> sub-optimal outcome.
> >
> > 2) QtScript is nice because it supports natural interoperation with Qt
> core
> > features (Qt properties, signals and slots, etc.).
> >
> > 3) Distribution-wise, QtScript is a no-brainer since it comes with Qt.
> >
> > 4) Controller scripts do not run in the engine thread so it doesn't
> affect audio processing whether the script VM is realtime or not.
> However, currently the standard way of implementing scratching via
> controller scripts routes all the ticks from the controller through the
> QtScript VM. This adds unpredictable latency to scratch processing.
> >
> > If you care about performance, you should instead be coming up with a
> standard, non-script way to implement scratching. Compared to executing
> code in a VM, the current XML bindings are orders of magnitude more
> efficient (It's a hash-map lookup to figure out which control to
> dispatch a message to).
> >
> > 5) Controller scripts are a mechanism for advanced script authors to get
> full control and customization. Throwing out the mappings eliminates all
> possibility for non-advanced users to customize their controller without
> writing code.
> >
> > For all these reasons, it would be a very bad outcome for our users to
> remove the XML mappings.
> >
> > Best regards,
> > RJ
> >
> > On Sun, May 26, 2013 at 10:52 AM, Juan Pedro Bolívar Puente <
> > raskolni...@gnu.org> wrote:
> >
> >> I disagree.
> >>
> >> First, there is nothing intrinsically "more performant" in Lua than in
> JavaScript -- they are both dynamically typed languages with objects
> and first-class functions. Also, there is a wide choice of VMs in in
> Javascript. While QtScript uses the webkit JS engine, which is fairly
> good and nothing prevents us to moving to V8 or something like that.
> >>
> >> Lua does not meet the realtime constraints neither anyway. In my
> experience, the scripting language should not be the fastest, but the
> most expressive, because its goal is to allow very fast development and
> hackability. If you look around, other music software are also using a
> wide variety of similar approaches, like Ableton Live, which uses
> Python (which is slower but more expressive than JS), or Max/MSP, which
> uses JavaScript.
> >>
> >> What its missing in Mixxx is, however, an API in the scripting engine
> to bind a MIDI signal to a control. This way, the script can handle
> mode selection, but for every mode, the important MIDI messages (cue
> button, knobs and faders) still go through the engine directly.
> Something like:
> >>
>
> >>
> >> Which would be equivalent to defining an entry in the <controls> or
> <outputs> section of the XML file.
> >>
> >> If I were to critisize JavaScript, on the other hand, it would be
> because it is not always as concise and expressive as it could be.
> Fortunatelly, a wide range of languages nowadays compile to JavaScript,
> and that is one of the reasons my CoffeeScript project can exist at
> all.
> >>
> >> JP
> >>
> >>
> >>
> >> On 25/05/13 15:38, petah wrote:
> >> > Hi there,
> >> >
> >> > first post but I am NOT a student looking to rubberstamp GSoC all over
> >> my resume :)
> >> >
> >> > RJ, you may remember me from www.hackerdjs.com/software/cdj2midi.html
> ,
> >> introduced by Mark Hills, through Adam D, I think. Since we last spoke
> I've
> >> become a linux-head, been stalking Mixxx-devel for a month. Seeing
> you're
> >> into 3D/games I'm surprised Mixxx uses Javascript, Python and qtScript
> but
> >> not Lua.
> >> >
> >> > I'm guessing the initial choice of XML/Javascript was to attract more
> >> people to write controller glue code but Mixxx has gotten a lot of
> traction/attention since then. With a new focus on reliability,
> Mixxx/hardware-interface drivers should really be written by somewhat
> experienced programmers (at least not invite bad code). QA's a bitch
> now cause you often don't have the hardware but if Mixxx's user base
> keeps growing as it does you'll soon be able to threaten manufacturers
> *not* to
> >> support their device:)
> >> >
> >> > Assuming Mixxx maintains its growth (vs withers & dies), driver and
> >> hardware availability is a given, what matters is runtime
> >> quality/efficiency. Porting the current ./res/controllers/ is a
> one-time effort. Also, the majority of users will be non-techie DJs; at
> the top DJs
> >> with a coding assistant :)
> >> >
> >> > Wrt speed, Javascript engines can afford many luxuries when running in
> >> web browsers (or servers) because they're not dealing with 10ms
> latencies.
> >> A web-surfing user won't notice a garbage collector hiccup but in a
> "critical realtime" app like Mixxx it's the end of the world for a very
> pissed DJ. Hardcore videogames are somewhat similar and there's
> virtually
> >> no Javascript; #1 engine is Lua because it's tiny and predictable;
> where the VM falls short you bind native C code in a handful of lines.
> >> >
> >> > Either way I think it'd make sense to use the same VM for both drivers
> >> and macros since they're really on the same path between the hardware
> interface and Mixxx.
> >> >
> >> > (bowing out)
> >> >
> >> > -- p
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> > Try New Relic Now & We'll Send You this Cool Shirt
> >> > New Relic is the only SaaS-based application performance monitoring
> >> service
> >> > that delivers powerful full stack analytics. Optimize and monitor
> your browser, app, & servers with just a few lines of code. Try New
> Relic and get this awesome Nerd Life shirt!
> >> http://p.sf.net/sfu/newrelic_d2d_may
> >> > _______________________________________________
> >> > 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
> >> >
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> >> New Relic is the only SaaS-based application performance monitoring
> service
> >> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt!
> >> http://p.sf.net/sfu/newrelic_d2d_may
> >> _______________________________________________
> >> 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
> >>
> >
>
>
>
>
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
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
