> I didn't mean to start a language pissing contest... but it looks > like I did :)
Sorry my message was a bit harsh... I did not mean to dismerit Lua. But lets make some comments... >> Lua does not meet the realtime constraints neither anyway. > > What makes you say that? I see you have experience in just about > every interpreter expect Lua (btw I live next door in Valencia if you > want to take it outside:). I am based in Berlin now, so lets argue here instead :) By "real-time constraints" I mean the real-time constraints that are usually required in the engine of most audio applications, which require algorithms to be O(bufferSize). Even non-GC heap allocations do not qualify for this, and because closures and dynamic typing can not be implemented without heap allocations (and GC) I don't think one can run Lua code in the engine threads. And if one can not run Lua code in the engine threads, there is going to be an added latency anyway to send the messages accross the engine boundaries, as long as the interpreter is not really bad, I do not think this is a big issue. If you mean, on the other hand, that if you do not use objects and closures then Lua can meet real-time conditions, the same holds for JavaScript. I would suggest you to take a look at "asm.js", a subset of JavaScript used to compile new-generation C++ games to JavaScript that run at 2X the native version (and it is the whole game running in JS, even the engine!). > Lua's used by Reason and ReNoise and in game engines since the PS2 > all the way to Crytek's Far Cry/Crysis which have similar > frame-lock/tick constraints. There's a laundry list of realtime apps > on www.lua.org/uses.html. Most tellingly, you'll find it in many > embedded systems like Cisco, Barracuda, MicroTik RouterOS, OpenWrt, > Wavecom GSM firmware. It hardly gets more realtime than that. Ok, that means its fast, but not real-time in the sense I mean, because they do not have a deadline. Or to put otherwise: in Far Cry if a single frame takes 50ms instead of an average of 16 (assuming 60fps) it will most probably go unnoticed. In an audio application engine if you get a 10ms cycle with a not-so-low bufferSize of 256, you already have an audio dropout with a noticeable click that I would not want to have at all in a big soundsystem. >> 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) > > You would know so correct me if I'm wrong, aren't large parts of Live > itself written in Python? Lua is much nimbler and doesn't offer > Python's richer object orientation. In Mixxx's case, I understand the > idea is extensibility - not to rewrite large parts of the application > in script. Python is used mostly there for hardware mappings, same use-case as for Mixxx. It is true that those hardware mappings are more complex than in Mixxx (think for example about Ableton Push) but, wouldn't it be nice to have such kind of complex controllers also having crazy workflows in Mixxx? >> 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); > > I wrote something like that and used it on all but my very first > gigs. I attached the glue code and script here; initialization is at > the bottom. Please don't judge Lua's merits (or mine for that > matter:) based on this, it was never meant to be used/seen by anyone > but myself, is/was a work in progress and I frequently tweaked > scripts just before a gig, knowing full well it was pretty > risky/stupid. Nice effort! Maybe you could put that in a branch in bzr so its easier for people interested in Lua can grab it and maintain it or reuse parts of it. > >> 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. > > I'm fairly sure Lua is one of the most concise languages there is. > Its reference manual is 103 pages long, including the C API. Also Lua > 5.2 has a rich set of binary operators (for example bit range > extract, ROL/ROR) that'd help HID/MIDI processing. By concise I meant with regards of the code written in the language. Anyway, I understand the merits of Lua w.r.t performance and so on. However, I do not see these strong enough to compensate for the benefits of JavaScript (many people know it, other languages can be compiled to it, wide choice fo VMs, etc.) JP ------------------------------------------------------------------------------ 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
