Robin's expertise is in A/V technology and related hardware/software research and development.
Currently Robin works as contractor for Harrison, Manufacturer of the World's Finest Consoles. He develops the Digital Audio Workstation Ardour and produces a line of professional Audio Plugins.
You can find him as x42 on github and mastodon.
I recently had a nice conversation with Amadeus from @linuxaudioplugindevelopment, talking about my involvement with Linux Audio, Ardour and free/libre software.
It turns out that I have short answers to long questions, and vice versa. :) You can find the interview with yours truly on the Linux Audio Developers Spotlight page on linuxaudio.dev.
I was supposed to host a hands-on workshop, planned for 5-6 persons at the Linux Audio Conference in Lyon in June 2025.
On the project rider I had “Boîte de macarons pistache”, not only did I not get that, but the night before I was told that the workshop space was not air-conditioned and +40degC (105 degF).
So I pivoted, spent some late night hours after the conference banquet (free drinks) and turned the workshop into a lecture to be presented in the main hall, which was air-conditioned, before the whole audience (it made be a bit nervous in the beginning). Here you go:
PS. Slides are available.
As some of you may know, ski vacations in Europe come in multiple of weeks: check in Saturday afternoon at the resort, leave next Saturday morning. So the runs are usually empty on Saturdays. So Robin arrives Friday night, stays somewhere in the valley, drives up early Saturday early morning, changes in the car, and hits the slopes:
..and meanwhile leaves his Thinkpad Laptop in the car.
This time at -10 degC.
Later that day when moving luggage in to the apartment after an amazing ski day, the bag with the laptop inside fell from the backseat to the leg area in the car.
And when I finally fired up the Thinkpad that night (really resume suspend-to-RAM), the screen showed damage, dead-pixels on the right-side and top. Everything else worked just fine.
I assumed those were cracks and caused by dropping the laptop, so I contacted my trusted Thinkpad service center (cecon.de) in Berlin by email that night, and got a reply from the service technician on Sunday (!). Replacing the display on the X1 costs 254 euro (incl. new screen, excl. VAT), and takes 30mins. I can wait while he replaced it. So I booked an appointment for the Monday after we return.
Then something miraculous happened.
The next day there were fewer dead pixels, and when cleaning the display with a cloth, I noticed that I could move dead pixels around with a bit of pressure.
So the actual issue was frost! Water apparently shorted out some pixels.
I didn't want to risk residue to permanently keep pixels from working so I didn't use a heat, but instead stored the laptop upside down over night and let gravity do the work at room temperature.
After 3 days the left edge had no dead pixels anymore, and only an area at the top-left remained broken.
As can be seen in the pictures, the area of dead pixels changed shape, and at first the amount of dead pixels remained about the same, mainly covering each window's title-bar.
It was only after I returned home that the amount of dead pixels started to decrease.
It was fun to watch the dead-pixel area change shape and shrink over time.
And lo and behold, a month later the display has no dead pixels anymore.
I didn't know that Frost can do this, and that the display recover by itself.
—
PS. A small side-project I wrote a few lines of JavaScript to color the whole screen, X/Y mouse coordinates controls hue and saturation: https://gareus.org/tmp/color.html (use in fullscreen mode). Came in handy to check for dead pixels.
It's been a long time coming,…
I have recently defended my doctoral Dissertation (PDF) on The Ardour DAW – Latency Compensation and Anywhere-to-Anywhere Signal Routing Systems at the University Paris 8.
Many thanks for everyone who helped make this happen, friends close and far and all the wonderful people who joined me during various periods along the road in the last 5 years. It's been quite a ride! Dr. Robin
I pulled into Nashville, Tennessee,…
I'm a miserable blogger. Even small attempts to write something short regularly once per week failed in the past.
Trying to get to the bottom of this, I realized that the issue here is blogging: I'm generally not interested to shout out my opinion one-way to the public at regular intervals. But what about other areas of communications? For example programming language code?
Another aspect that I noticed to distract me are lack of constraints: Focus on a topic is beneficial to weave a chain. …and the key ingredient for me is a good challenge to motivate me.
Recognizing one's shortcomings is the first step, playing to one's strength.. et voila.
I set out a year ago today (after the skiing holidays), and the rest is [in the] git history :)
I killed two birds with one stone: combine my interest as user and developer in the Linux Audio ecosystem in general and responsibilities I shouldered there, with the endeavor to set a good example on the following statement:
If every Linux Audio developer would make regular contributions to the GNU/Linux Audio ecosystem, the overall state would increase rapidly.
The idea came up in the wake of one of the most active thread on the linux-audio-dev and -users mailing lists 2/Feb/2013 "So what do you think sucks about Linux Audio?". Well, instead of bitching about, I opted to provide a different response, “A patch a day keeps bit-rot away” :)
The contributions made over the last year are spread out about half/half to projects of my own and to projects with a different lead-developer or maintainer.
As for the former, I've been most active in meters.lv2, the goal being to make GNU/Linux even more suitable as a platform for Pro-Audio work. Regarding the latter I became a major contributor to the flag-ship of Linux Audio: The Ardour3 Digital Audio Workstation. On the sidelines there were (and are) many more projects, not all of them on github.
I'm not personally interested in data-mining and analyzing the commit-log for patterns. The general Mantra of it all is “Find something that you're interested in, can do, and do it”. The only problem here is that eventually there's much more to do that there is time for doing it. Luckily there is some overlap with many projects as well as with my personal and professional use-cases which makes it easier to set priorities, even though not necessarily favorable ones from the 'fun' point of view.
Another related issue is that collaboration requires communication with other authors, which can prevent a regular code-contribution pattern. While this is a good thing in general (plan, think and discuss first), it did not aid the challenge at hand… In fact, this “Don't break the chain” coding endeavor required a bit of time-planning in itself to be useful.
The hard part to keep this up was after around 3 month (late spring) and then again later in August/September (summer holidays). Here, I motivated myself with a small side project there: I can now say “I wrote git …on github” :)
Eventually a git commit became daily routine, just like reading mail. A git commit can be anything from a simple one line typo fix to a major rework of a piece of code so the measure of actual contributions is somewhat meaningless, but as the Scottish say: “Many a mickle makes a muckle.”
GitHub rightfully counts bug-reports as contribution to a project, though in my case the goal was a daily contribution to the master branch of some project (not counting fun projects such as the git-message).
Anyway, it's been a rewarding experience and I'm planning to keep this going, maybe not as rigorously as during the last year, since other (non code) projects are about to become more central in the not too distant future. Either way I gave up for good on trying to repeat a feat that I managed from age 15 to 25: Play at least 1 hour guitar every day.
Coming late to my own party..
In the wake of overhauling Ardour's bar-graph meters, I've taken the time to implement corresponding needle-style meters and more.
meters.lv2 features 10 needle-style meters: Mono and stereo variants of DIN, Nordic, EBU, BBC and VU types (which are based on jmeters by Fons Adriaensen).
Additionally it includes a Stereo Phase Correlation Meter, an EBU-R128 Meter with Histogram and History display, a Digital True-Peak Meter, a Stereo Phase Scope (Goniometer), a 31 Band Spectrum-Analyzer and six K-meters (mono,stereo versions of the K12, K14 and K20 K meter-standard by Bob Katz).
Source-code, information and screenshots can be found at https://github.com/x42/meters.lv2
Alexandre Prokoudine has written a nice blog-post over at LGW and gave away a hard-copy of the “Audio Metering. Measurements, Standards, Practice” book by Eddy Brixen to celebrate the release.
meters.lv2 would not be what it is without the various contributions from Fons Adriaensen, David Robillard, Chris Goddard and Axel Müller. Thanks to Jaromír Mikeš they are already packaged in debian, part of the x42-plugins package.
Ardour 3.2 has been released featuring the videotimeline and a lot of other things that I've been working on on the past years, months and weeks!
I count myself lucky that after all that work, I don't need to write the announcement by myself. Let the buzz begin.
There's…
Many thanks to everyone who contributed, provided feedback and support. In particular Chris Goddard, Thomas Vecchione and Paul Davis. Not to mention the projects on who made this possible in the first place – most notably ffmpeg.
The source-code is available out there and if you don't want to get the official ready-to-run application, various multimedia GNU/Linux distributions have already picked it up.
I've started to tackle a major todo item on the setBfree issue-tracker: the Organ needs a GUI :)
Well, strictly speaking it does not. All controls are available as MIDI-CCs, so when playing it using a midi-keyboard, a GUI is uncalled for. The GUI is completely optional. But setting up those MIDI-CC maps and midi-program-presets in the first place can be quite an advanced talk for musicians who are not comfortable with editing text config files. Also using when using the organ synthesizer as plugin in a sequencer MIDI-CCs are unwieldy for visualizing drawbar settings. Last but not least the GUI is bi-directional: the GUI is updated if the synth receives MIDI messages and can be used to quicky check the state (e.g. when loading midi-programs/presets) and changing values in the GUI sends corresponding midi feeback to the connected device.
A major factor in the GUI design decision was that GUI should run cross-platform and can be used in LV2 plugin hosts without causing ABI conflicts. The toolkit should also be reasonably lightweight. This basically ruled out gtk+, QT, FLTK and NTK :( Luckily there's OpenGL!
So if GL, why not 3D too?! In the context of an audio-plugin it's one of the most superfluous uses of 3D, ever, but WTH!
setBfree running as LV2-plugin in ardour – of course you can pan, zoom and tilt the 3D view :)
The 3D model was made with blender and the textures with gimp, the files are available with the source-code at github. The folder also contains a readme file with basic information.
Now, I'm not much of a 3D artist, hence Alexandre Prokoudine from http://libregraphicsworld.org/ has issued an open call.
For inspiration, here are some pictures that google found searching for Hammond B3.
Work on the GUI is still ongoing. It is already functional but work on many of the planned features - like interactive midi-maps, presets, etc - has only just begun.
Have you ever wanted to include raw data - such as images - in an executable application file?
An application that can be compiled for any platform including Windows, Linux and OSX?
– Well, while I was working on harvid, I did.
It turned out to be quite easy - once you know how :) gnu/ld rocks, but as usual there are some issues – in particular on OSX.
Check out the complete embedding resources in executables story.
