Ardour Pong from Robin Gareus on Vimeo.
A console classic for your console. Sample-accurate automation and all :)
Showcasing Lua scripting facilities/ for the Ardour Digital Audio Workstation. Compact, easy to read code
Amazing 
Now you can play pong while editing audio, no more boring moments when working
Lua scripting opens a whole new world for Ardour users. The language seems to use quite a lot of processing power though. But the possibilities it offers are very exciting.
The compiled Lua bytecode is actually fine and the compiler is spiffy, too. It’s on the same order as un-optimized (not vectorized) C code (not quite as efficient but close).
For the inner-loop one would indeed usually call a vectorized C function from Lua. The overhead accumulates easily otherwise.
But hey for some quick prototyping or one-off custom cases it’s fine and Lua is realtime safe.
Great. So you can play pong in ardour. Wouldn’t be better, if you can actually edit and mix music without crashing and annoying bugs? Why is (like in lots of other SW) adding features priority instead of making it stable?
To be honest - I’ve made one song yesterday in A5 without any crash (all stables versions of A4 was crashing all day long). But still I was not able to “shorten” recorded samples using drag’n’dropping on the edge of region, if it was snapped to whole bar. Regions aligned to second, third or fourth quarter of bar had about 1px area, where it can be dragged by mouse.
And one time, I had to restart Ardour 'coz moving a region made tens of copies.
Ardour is really great project and I like it, I even supported it with some money (not so many though). But these little bugs, crashes and sometimes hard to use UI along with focusing “just” on adding features make a gap between Ardour and the professional software (cubase, reaper).
So developers can’t have fun while working huh? Pong is a demonstration code really, to show basics of how to interact with the lua scripting that exists in Ardour for those that care to (Like myself). This just simplifies it and does it in a way that some people would find easier to deal with than the DSP code itself. Useful for people like me that never learned calculus but can do basic programming. It really doesn’t add any new features to Ardour at all in all honesty, it is about documentation more than anything, just having a bit more fun while doing it.
The reason adding features ‘seems’ to take priority is that fixing bugs is a lot more work than people realize, and far more difficult. You have crashing bugs, have these been reported? Have you helped create backtraces and documented the steps as demonstrated in http://ardour.org/reporting_bugs ? These are the steps that are needed that many users ignore, but the problem is you have a crash on your system that a developer has obviously not reproduced so they need you to reproduce it for them and create the needed information so that they can troubleshoot it, without it if they can’t reproduce it they can’t do much.
By the way, I believe the 1px area bug has already been fixed in the nightly builds and will be in the next release IIRC. Also for the reference the pong referenced here is only in the nightly releases as of right now, not in the release on the website.
SeabladeSeablade: AFAIK, whole Lua iface is new feature 
Nevertheless I understand, that fighting insects like bugs isn’t so simple. I’m programmer and also I have flour moths in kitchen
You are right, that I was not much helpful as I didn’t send any stack trace to devs. I’m not used to start ardour with stdout redirected to file nor enabled coredumps, so I don’t have any relevant info when it crashes. And lot crashes happens randomly - when moving mouse, region, when recording, routing signal - and I’m not able to reproduce them again. But, I will try to be a better person and submit some crash report when it occurs.
Anyway, my message was meant just by “don’t exaggerate features”, not as hate . My favourite browser (Opera w/ Presto) ended few years ago by ignoring crashes and bugs and adding more and more pointless features. So I don’t want ardour ended the same.
Have a nice day :),
S.
@sukcz: we make releases based on our impression of application stability. That is based on our own testing of the application and feedback from users (primarily via IRC and tracker.ardour.org). In general, there’s a typical pattern in which a release appears to be the most stable version in a while, then development is underway and things get worse, and then we slowly get to fixing the issues and eventually we’re back to something more stable than we had before.
That is certainly true for Ardour 3, 4 and 5.
If people are having lots of crashes, we need to know that. If we don’t know that, then our impression is that software is stable and at a reasonable point for a release. Certainly our general impression from users on IRC is that Ardour is harder and harder to crash.
It is also the case that people’s workflows with a program of this complexity vary enormously. Sometimes crashes are caused by incredibly obvious and stupid programming errors that don’t get trigged except when a user does X then Y then Z, and almost nobody has ever done X, Y and then Z and told us about it. The first time I tried Cubase 5, I crashed it 3 times in about as many minutes. I was used to doing things “The Ardour Way” and Cubase wasn’t too happy about that.
Also, the Lua interface exists in part so that developers who do want to deal with C++ or the build process can add useful functionality to Ardour that otherwise would be inaccessible. We’ve already had one example since release of a brand new user who cooked up some (to him) very useful scripts to do batch renaming and coloring of tracks.
This interface needs to evolve in order to be as useful as it probably should be, and that evolution involve doing new and possibly strange things with it to test out APIs, implementations and performance. Pong is one such example, which exists more to exercise binding all of the 2d drawing library (Cairo) to Lua than to be any kind of serious new feature for Ardour. This allows people to create useful, dynamic displays in mixer strips, and that is the real new feature here.
As others have already noted: It’s not all just toys and fun. It’s mainly example-code to exercise the internal API.
a-pong also nicely demonstrates Ardour’s automating thinning: Automate pong. At the end of the automation write Ardour removes dense automation points. Since pong is incremental (integrate over automation) it’ll game-over. Very few audio-plugins do integrate, so this is a good test.
Oh, and there are sounds on all three “walls” now. Some users also have found stable loop configurations: pong-synth!
And the bonus: Next time you have some guests in the studio, you can let them play fader-pong™ while waiting for the guitarists to tune. How cool is that? Try that with PT.
PS. No worries bug-fixing remains a priority over new features in general. Coincidentally, one can inspect libardour’s internals at runtime using Lua, which simplifies debugging, too.
Haha, this is way cool! 
@rgareus: I love it Robin! What truly nostalgic memories a-pong brings back to mind! (I’m old) I have zero programming capability so all this is “voodoo” to me but I understand enough about coding to appreciate all of you and the fantastic work you’ve done to create Ardour - thanks so much!!
Just a thought: a script to force the fader moving following the draw (envelope) - we could get an analogue of Volumeshaper (http://www.cableguys.com/volumeshaper.html)