Hi RJ,
I fully agree with your thoughts!
But let me explain my "get rid of XML" idea.
Almost All Midi mappings have an *.xml and a *js file. It is a pain to
maintain them.
The coffee script approach is (correct me if I am wrong) to generate them
both in a single process.
Advantage:
* single location to edit the mapping
* backward compatibility
Disadvantage:
* a new process to maintain
* Three files to handle
So what about trying to move as much code as possible to the C++ (ASM)
domain, and let a single JS only control those functions and data
structures.
Today Mixxx reads the xml to fill the hash tables, tomorrow it should be
possible to fill them by JS as well.
Advantage:
* single location to edit the mapping
* backward compatibility
* only one file to maintain
Disadvantage:
* a new process to maintain
Nice Trip!
Daniel
2013/5/27 RJ Ryan <russelljr...@gmail.com>
> Hi everybody,
>
> I'm on a climbing trip but I just wanted to chime in with some comments.
> Here are some of my thoughts:
>
> 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:
>>
>> engine.connectMidiToControl(status, midino, group, control, options);
>> engine.connectControlToMidi(group, control, status, midino, options);
>>
>> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
