April 03, 2020


TMS streaming concert Saturday the 4. April

We continue our streaming concerts, this time as TMS, on tomorrows Saturday at APO-33s Filiason streaming night:

playing the last slot.

by herrsteiner ( at April 03, 2020 04:15 PM

News – Ubuntu Studio

Ubuntu Studio 20.04 LTS Beta (Focal Fossa) Released

The Ubuntu Studio team is pleased to announce the beta release of Ubuntu Studio 20.04 LTS, codenamed Focal Fossa. While this beta is reasonably free of any showstopper DVD build or installer bugs, you may find some bugs within. This image is, however, reasonably representative of what you will find... Continue reading

by eeickmeyer at April 03, 2020 02:08 PM

SFZTools News

sfizz v0.3.2 release

  • sfizz now builds down to gcc-4.9 with stricter C++11 compliance. The main release builds use C++17 mode on newer compilers (#111, #110)
  • Upstream libraries updates (abseil, filesystem and atomic_queue) (#121)
  • Added an experimental support for make uninstall (#118, #120)
  • Add the autopan (#105), width, rectifier, gain, limiter (#131), and string resonator (#143) effects
  • Curves are now registered within the synth but cannot be referenced yet (#96)
  • Corrected a bug where the VST plugin got recreated needlessly in some hosts (#122)
  • Added a “panic button” API that kills voices (#122)
  • Corrected a potential overflow for CC names (930bfd)
  • Added support for more generators using wavetables (#61)
  • Added support for the oscillator opcode, to create generators from files (#128)
  • Generators using wavetables are now correctly tuned (#126)
  • The stereo panning stage of the process was corrected; width is now set to 100% by default as it should, and panning is properly applied (1faa7f, b55171, #133)
  • The logging API can be used to set a log filename (a6cbb4)
  • Corrected errors in the performance report script related to display values (file names and histogram range)
  • Reworked the parser; the new one is more efficient, and can indicate error/warning ranges (#130)
  • The VST plugin now reloads the file automatically, like the LV2 plugin (#139)
  • The max number of CCs was increased to 512, to accomodate some libraries that use cc300 modifiers.
  • The engine uses floating point values internally for midi events (#137); this prepares it for high-resolution midi down the line.
  • Fixes some realtime synchronization issues in the VST (#140)
  • Added support for note_polyphony, polyphony, and note_selfmask (#142)
  • Added support for pitch_cc and tune_cc modifiers (#142)
  • The modifier support was overhauled; all regions can now have multiple CCs modifying the same target (#142).
  • Corrected bugs and differences with Cakewalk/ARIA in the ADSR envelope (#136, #129)
  • Improved performance of the amplitude stage gain of the rendering process (#145)
  • The VST3 are now a submodule; more architecture targets have been added (#158, #147, patch proposed by hexdump0815)

by redtide at April 03, 2020 12:00 AM

March 28, 2020

Qtractor 0.9.13 - A QStuff* Spring'20 Release batch #3

Greetings, just one third time!

Qtractor 0.9.13 (spring'20) is released!


  • All meters background color are now customize-able (cf. View/Options.../Display/Meters, color level "Back").
  • Automatic mixer grid layout (multi-row) is now in effect permanently--being an option no more.
  • Always show plugins and meters on track list/left pane as permanent standard now.
  • LV2 UI Request-value feature/interface support has been implemented.
  • Audio output monitoring meters are now shown/hidden auto-magically on MIDI tracks and/or buses--no need for some user preference option anymore (ie. View/Options.../Plugins/Instruments/Show audio output monitoring meters, is now gone).
  • Default track height has been slightly increased.
  • Track / Duplicate Track... now also takes a MIDI track's audio meters setting into account.
  • VST3 plug-in support introduced. (EXPERIMENTAL)
  • Fixed first bar/measure position drawing on the time-scale/grid across time-signature changes on the MIDI clip editor (aka. piano-roll) (hopefully fixing issue #245).
  • Plugins and meters on track list/left pane, are now being set on as default--maybe going stapled in some near future ;)
  • Make man page compression reproducible (after request by Jelle van der Waa, while on the Vee-Ones, thanks).
  • Avoid resetting top or left position when zooming with mouse pointer is in main tracks or MIDI clip editor (piano-roll) views.
  • Make libaubio a build dependency on Debian/Ubuntu; also fix cross-build check to sizeof(float).
  • Bumped copyright headers into the New Year (2020).


Qtractor is an audio/MIDI multi-track sequencer application written in C++ with the Qt framework. Target platform is Linux, where the Jack Audio Connection Kit (JACK) for audio and the Advanced Linux Sound Architecture (ALSA) for MIDI are the main infrastructures to evolve as a fairly-featured Linux desktop audio workstation GUI, specially dedicated to the personal home-studio.


Project page:


Git repos:

Wiki (help wanted!):


Qtractor is free, open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.

Enjoy && Stay safe!

Donate to

by rncbc at March 28, 2020 02:00 PM

March 27, 2020

Development update: 6.0-pre1 now ready for testing

@paul wrote:

Well folks, we’ve done it. After two and a half years of development that has both excluded a few hoped-for features and also expanded to include many things not originally envisaged, we’re ready for people to start testing version 6.0-pre1. Please note: this is NOT the release of 6.0 - we’re now entering a testing phase that will continue through several “-preN” versions until we’re confident that it’s ready for release.

The nightly version is now (as ever) available at If you’re a subscriber (or paid US$45 or more for a pre-built version of 5.x), you can download the fully functional version. Others can get the free/demo version which periodically goes silent. Obviously, since this is a nightly version, it will be updated most days to reflect any new development work and fixes as we move towards the actual release of 6.0.

It will install in parallel to any existing version of Ardour, will not alter your preferences for older versions of Ardour, and if you use it on any existing session, it will save a copy of the session file (or snapshot) just to be safe.

Linux Package Maintainers

If you maintain a Linux distribution’s package of Ardour, please DO NOT consider packaging this version. This is NOT a release of Ardour 6.0, but merely a call for testing.

Here are some of the things the project needs right now:


Although 6.0 does not visibly change the most obvious functionality, design and workflow of Ardour, internally huge amounts of the code has changed during development. Several people have been testing it periodically, including users of Harrison Mixbus (whose version 6 release is based on the same set of changes). However, it is now time to open up testing to more people, because we know that this always results in unccovering more issues - something we’d like to do (and fix!) before the actual release.

We believe that 6.0-pre1 is just as if not more ready for use than Ardour 5.12 was, but we can only establish that with your help. Create some sessions. Do the stuff you do. Exercise your workflow. And if you find issues, please use the bug tracker to report them, marking them with the 6.0-pre1 version. Please do not report bugs here on the forums - we will mostly ignore them here (because there is no way to properly manage them).

Bug Triage

If you have ever reported a bug in Ardour, please give 6.0-pre1 a try and then head over to and mark your bug(s) closed if they are fixed. If a bug isn’t fixed, please update the version field to indicate the bug is still an issue in 6.0-pre1. We may automatically close all open bugs for previous versions after a fixed period of time, so if you would like your bug report to receive attention in the future, please go and update its status.

Theme Updates

Many users may not be aware that thanks to the hard work of a user known as cooltehno, Ardour has 6 different themes. During the development of 6.0, there were significant simplifications and changes to the internals of themes, and the 5 themes that cooltehno generated all need updating and revisiting. If you’re interested in doing this, for one or all 5, please get in touch.


As anyone who has seen the various “Development Update” posts along the way for 6.0 is aware, there are a lot of new and changed features in this version of Ardour. We need people to update and/or write new sections in the manual to reflect all these changes. Please get in touch if you’d like to be a part of this effort.


Ardour has been translated into 15 languages:

French, German, Spanish (unified Castillian and Latin American), Portugese (Brasilian & Portugese), Russian, Swedish, Czech, Norwegian, Italian, Japanese, Chinese, English (UK), Polish, Greek

All of these translations will need significant updates for version 6.0. Although we are not yet in a string freeze, we hope there won’t be too many string changes before 6.0, so now is an ideal time for existing or new translators to get started. If you’re interested in becoming a translator, please read our guide at

Posts: 33

Participants: 16

Read full topic

by @paul Paul Davis at March 27, 2020 12:51 AM

March 26, 2020

Vee One Suite 0.9.13 - A QStuff* Spring'20 Release batch #2

Greetings once more,

The Vee One Suite of old-school software instruments, synthv1, as a polyphonic subtractive synthesizer, samplv1, a polyphonic sampler synthesizer, drumkv1 as yet another drum-kit sampler and padthv1 as a polyphonic additive synthesizer, are all being released now for the second QStuff* Spring'20 batch of the (quarantine) season.

All still available in dual form deliveries:

  • a pure stand-alone JACK client with JACK-session, NSM (Non Session management) and both JACK MIDI and ALSA MIDI input support;
  • a LV2 instrument plug-in.

Not much of a ravishing change-log, just on the brink of utterly boring maintenance stuff:

  • Always keep the current sample loop-cycle on note-off, while entering a DCA Release stage. (applies to samplv1 only)
  • Maximum pitch-bend range has been expanded to 0..400%, allegedly to support some PME driven instruments.
  • Make man page compression reproducible (after request by Jelle van der Waa, thanks).
  • Fixed crash when showing the tooltip of a negative note number that results from dragging over and beyond the left edge of the virtual piano keyboard.
  • Remove -v (verbose) flag from 'strip' post-link command.
  • Fixed CMake build by adding missing Custom Color Theme (palette) form file (.ui).
  • Bumped copyright headers into the New Year (2020).

The Vee One Suite are free, open-source Linux Audio software, distributed under the terms of the GNU General Public License (GPL) version 2 or later.


synthv1 - an old-school polyphonic synthesizer

synthv1 0.9.13 (spring'20) released!

synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx.



project page:


git repos:


samplv1 - an old-school polyphonic sampler

samplv1 0.9.13 (spring'20) released!

samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.



project page:


git repos:


drumkv1 - an old-school drum-kit sampler

drumkv1 0.9.13 (spring'20) released!

drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx.



project page:


git repos:


padthv1 - an old-school polyphonic additive synthesizer

padthv1 0.9.13 (spring'20) released!

padthv1 is an old-school polyphonic additive synthesizer with stereo fx

padthv1 is based on the PADsynth algorithm by Paul Nasca, as a special variant of additive synthesis.



project page:


git repos:


Donate to

Enjoy && Stay safe!

by rncbc at March 26, 2020 08:00 PM

News – Ubuntu Studio

Ubuntu Studio 20.04 Testing Week

Ubuntu Studio 20.04 will be Ubuntu Studio’s first LTS release in four years. While we are working hard on the final polish for this, our 27th release, we would like to enlist your help with testing. On April 2nd, we will be releasing Ubuntu Studio 20.04 LTS Beta. This comes... Continue reading

by eeickmeyer at March 26, 2020 12:00 PM

March 25, 2020


March 21, 2020

digital audio hacks – Hackaday

Expansion Board Puts Spotify On The Amiga 500

No doubt some purists in the audience will call this one cheating, since this Amiga 500 from 1987 isn’t technically connecting to Spotify and playing the music by itself. But we also suspect those folks might be missing the point of a site called Hackaday. With all the hoops [Daniel Arvidsson] hopped through to make this happen, what else could it be if not a hack?

This one starts, like so many projects these days, with the Raspberry Pi. Don’t worry Amiga aficionados, this classic machine hasn’t been gutted and had its internals replaced with a diminutive Linux board. But thanks to an expansion card known as the A314, you could say it’s received a penguin infusion. This clever board allows an internally mounted Raspberry Pi to communicate with the Amiga 500 through shared memory, making all sorts of trickery possible.

In this case, the Raspberry Pi is actually the one connecting to the Spotify Connect service with raspotify and decoding the stream. But thanks to a few pipes and an ALSA plugin, the audio itself is actually pushed into the Amiga’s sound hardware. In the video after the break, the process is demonstrated with tunes that are befitting a computer of this vintage.

This process is similar to how one classic Apple fan got Spotify running on their Macintosh SE/30 with a similar respect for the vintage hardware. Of course if you actually want to gut your Amiga 500 and replace it with a Raspberry Pi, we’ve seen some pretty good conversions to get you started.

[Thanks to burningbroccoli for the tip.]

by Tom Nardi at March 21, 2020 05:00 AM

March 17, 2020

SFZ Format News

New tutorial and opcode additions

A new tutorial about subtractive synthesizers was shared by DSmolken’s sample instruments experience applied in the Caveman Cosmonaut sample library.
Some fixes and additions were made in our opcode database and in software as well, like the Windows OpenMPT music tracker by sagamusix.
New contributions was provided by other users like jisaacstone, and a big contribution from jpcima for the effects section.
Now we have also a new page for convenience that lists all opcodes present in our database.

by redtide at March 17, 2020 12:00 AM

March 14, 2020

SFZTools News

sfizz v0.3.1 release

  • Added a VST3 plug-in front-end to the library. It is still quite experimental and suffers from problems that stem from the VST3 SDK itself. (#99)
  • Added effect buses and processing. There is a lofi effect available for now, as well as the same filters and EQs you can apply on the regions. More will come soon! (#84)
  • Added a script to parse and render the timings. This can help tracking performance issues and regressions. (#89)
  • Various fixups, performance improvements, and CI updates.

by redtide at March 14, 2020 12:00 AM

February 29, 2020

digital audio hacks – Hackaday

Media Streamer With E-Ink Display Keeps it Classy

The Logitech SqueezeBox was a device you hooked up to your stereo so you could stream music from a Network Attached Storage (NAS) box or your desktop computer over the network. That might not sound very exciting now, but when [Aaron Ciuffo] bought it back in 2006, it was a pretty big deal. The little gadget has been chugging all these years, but the cracks are starting to form. Before it finally heads to that great electronics recycling center in the sky, he’s decided to start work on its replacement.

Thanks to the Raspberry Pi, building a little device to stream digital audio from a NAS is easy these days. But a Pi hooked up to a USB speaker isn’t necessarily a great fit for the living room. [Aaron] didn’t necessarily want his replacement player to actually look like the SqueezeBox, but he wanted it to be presentable. While most of us probably would have tried to make something that looked like a traditional piece of audio gear, he took his design is a somewhat more homey direction.

An OpenSCAD render of the enclosure.

The Raspberry Pi 4 and HiFiBerry DAC+ Pro live inside of a wooden laser cut case that [Aaron] designed with OpenSCAD. We generally associate this tool with 3D printing, but here he’s exporting each individual panel as an SVG file so they can be cut out. We especially like that he took the time to add all of the internal components to the render so he could be sure everything fit before bringing the design into the corporeal world.

While the case was definitely a step in the right direction, [Aaron] wasn’t done yet. He added a WaveShare e-Paper 5.83″ display and mounted it in a picture frame. Software he’s written for the Raspberry Pi shows the album information and cover art on the display while the music is playing, and the current time and weather forecast when it’s idle. He’s written the software to plug into Logitech’s media player back-end to retain compatibility with the not-quite-dead-yet SqueezeBox, but we imagine the code could be adapted to whatever digital media scheme you’re using.

Over the years, we’ve seen a number of SqueezeBox replacements. Many of which have been powered by the Raspberry Pi, but even the ESP8266 and ESP32 have gotten in on the action recently.

by Tom Nardi at February 29, 2020 09:00 PM

KXStudio News

KXStudio Monthly Report (February 2020)

Hello everyone, it is time for another monthly report in regards to the KXStudio project.

First, there were many bugfixes made to Carla, we are very close to RC2.
I only have 2 things that I want to do before the RC2, first being fixing multi-instance under multi-client mode and second is to finalize the last couple of bugfixes.
So the RC2 should be out in a few days, maximum weeks.

Second, something that came out of (re-)packaging WineASIO (and moving away from Cadence, but that is a story for another day...).
I am taking over as maintainer of the WineASIO project.

WineASIO is something that is mostly "done", there is not much that we can add to it.
Since I have to keep it building in order to package it, I spoke with upstream and let them know I was available to take over.
(maintaince work is pretty minimal, just got to make it build basically)

We are trying to take over organization, so we can place the source code repository in there.
If that takes too long, the repository will just end up at as it is for the moment.
In any case, we will see v1.0.0 release of WineASIO quite soon!

The KXStudio repositories' armhf build of surge has been fixed.
I have opened a pull request on upstream surge to discuss the armhf/arm64 needed changes (basically a SSE2 to NEON conversion).
They are quite open to it, which is nice to see.
We just need to fix some minor things now and that could likely be part of 1.7.0 release later on.

Finally, these are the package updates made in the repositories:

  • carla-git updated
  • mod-cv-plugins updated to latest git
  • sequencer64 updated to latest git, midi_control branch
  • surge updated to 1.6.6
  • cv-lfo-blender-lv2 added
  • g2reverb added
  • invada-studio-plugins (LADSPA) and invada-studio-plugins-lv2 added
  • setbfree added, including VST2 version through lv2vst
  • wineasio added
  • zlfo added

That is all for now. Have a great weekend everyone! :)

by falkTX at February 29, 2020 01:22 PM

February 13, 2020

Audio – Stefan Westerfeld's blog

SpectMorph 0.5.1 released

A new version, SpectMorph 0.5.1 is available at SpectMorph is a VST/LV2/JACK synthesis engine which is based on the idea of analyzing audio samples and combining them using morphing.

As you can see in the screenshot, there are a few new LFO wave forms available (saw, square and random).

On Windows and macOS, from the beginning there was no need for users to compile anything. You could just download SpectMorph, install it and use it. On Linux, we provide packages for Ubuntu and there are also distribution packages for Arch Linux. But this means that as a user, if you use a different linux distribution, you had to build SpectMorph from source. Which may be too difficult for the average user.

This release improves the situation: there are now Generic 64bit Linux binaries available, which provide the VST/LV2 plugin (statically linked). So these binaries should run on just about any linux. Note that this is a new feature, so please let me know if the generic binaries don’t work for you.

This release also contains a few fixes and the detailed list of changes can be found here.

Finally let me recommend two youtube videos (if you haven’t watched these yet):

by stw at February 13, 2020 10:51 AM

February 07, 2020

Is Open Source a diversion from what users really want?

@paul wrote:

When I started working on Ardour, it never occured to me to do anything other than use the GNU Public License (GPL), the most well-known way to release “open source” software. At that time, it was a choice driven by a combination of:

  • my passionate belief in what is more appropriately called "free/libre software"
  • an awareness that I'd probably need help developing Ardour. The open source model seemedto me the best way to make it possible for others to contribute (no matter what their motivations might have been).
  • the desirability of being able to use dozens of software libraries released under GPL-related licenses

Of course, developing software with complexity on the level of Ardour’s is never going to be easy, and finding other people willing and able to contribute to such a project is always going to be hard, whether you’re an open source project or a proprietary company.

However, underlying both of those reasons why I wanted to use the GPL was a conviction the access to the source code was critical to both:

  1. giving users the freedom they deserved
  2. attracting developers (or even just "power users") to contribute to the project.

I remain convinced that access to source code is a fundamental part of the "four freedoms" that Richard Stallman has outlined as the basis of the concept of "free/libre software". But as described at great length and exhaustive detail by Berlin-based electronic musician and developer Louigi Verona, it's not quite that simple.

Meanwhile, how could anyone really contribute to the project in any substantive way without source code access? If they were going to add functionality, or extend it or in some other way modify it, source code access seems like a basic and absolute requirement.

A recent thread on our forums has made me revisit these assumptions, and this has led me to have some doubts about what "open source" really means for a project like Ardour.

Forum member Musocity wants to be able to extend Ardour without having to build the program from source. If you read the thread, you'll see both myself and co-developer Robin Gareus pushing back on this concept several times. Nevertheless, Musocity continues to use Reaper as a counter-example in which much greater levels of user-driven "extensions" are possible without any access to the source code and without any requirement to rebuild the program.

My gut reaction continues to be something along the lines of

Are you kidding me? We give you full access to everything in Ardour, not just some pre-selected functionality exposed via a scripting language. You can build it on almost any platform, add/remove/enhance almost anything you can imagine ... and you keep pushing for a 2nd-rate scripting interface just so that you can do stuff without dealing with the build process?

But this forum thread has made me keep returning to two points I mentioned above. Specifically in the form of follow up questions:

  1. are users truly being given freedom by confronting them with a technological infrastructure that almost none of them can comprehend?
  2. does the requirement to rebuild the program, or from a different perspective, to write C++ code, attract or deter developers to/from the project?

These are not easy questions to answer.

Let's start by pointing out what Ardour already offers: a very sustantial Lua API providing access to the majority of the program, and with it the ability to write both DSP code and higher-level functionality, all without rebuilding Ardour or dealing with C++. This has all been Robin Gareus' effort, and he has done an amazing job (aided by just how suitable Lua is for this sort of thing - partly why Reaper uses it too, no doubt). What is missing is the ability to construct arbitrary graphic user interface components from Lua. This puts distinct limits on what can be done with scripting in Ardour, even given how much is already possible.

Reaper stands as an existence proof of what can be done when the scripting capabilities are essentially all-encompassing. Ableton Live, with both Max4Live and other "scripting systems" offers slightly less extensive capabilities, but still somewhat more than Ardour in terms of GUI integration.

Nevertheless, it remains the case that nobody except for Reaper's (or Live's) developers can modify fundamental aspects of the program. The work that we have been doing on Ardour 6.0 would never have been possible to do via Lua, and that would be true in the context of Reaper or Live as well. So the first thing that we need to note is:

  1. the scripting interface for a DAW can vary in terms of what it makes possible to accomplish.
  2. this is particularly true in terms of integration into the "main body" of DAW's own GUI.
  3. no matter what the scripting interface offers, it does not allow anyone to do fundamental work on the internals of the DAW. A DAW that cannot do cue monitoring will never become one that can because of a script extension. The same goes for full latency compensation, misdesigned region/clip lists and an almost inexhaustible list of other features that cannot be implemented via script extension system.

Musocity, it appears, doesn't really care about any of this: they've seen what you can do with Reaper's scripting interface, and it seems entirely reasonable to them that the same ought to be true in Ardour whether or not the entire program's source code is available.

Which brings us to the second aspect of why this is complicated. Even 20 years ago there were full time web developers. There were also so-called "application developers" who typically worked entirely inside database-connected development tools to create ways to view and edit data. In the two decades since Ardour started, we've seen an entire generation of people whose job description includes "programming" but who have never (or almost never) compiled a piece of software in their life. The web development infrastructure that has grown up over the last two decades has seen huge numbers of people creating software in ways that never require them to take "source code" and transform it into "a program". They write "scripts" (be it in Javascript, Java, Python, Ruby or whatever they prefer) and the necessary magic happens to ensure that what they've written actually executes, somehow. Even for the most sophisticated web development stacks, where there's some notion of "build systems" and "deployment", these only have a superficial resemblance to the workflow involved with a desktop application written in a compiled language.

In my limited experience interacting with people who develop on a web stack, the build process for a program like Ardour is frequently a massive stumbling block to any participation they might have considered. They may not mind dealing with poorly documented (or undocumented) APIs, complex data structures and mind-boggling program control flow. But tell them that after they make a change, they have to "build" the program and that in some circumstances this will take several minutes to complete ... enthusiasm starts dying rapidly. And now consider what happens when these developers are on platforms (primarily Windows and macOS) where they cannot issue a single command (e.g. apt-get build-dep ardour) to set up their build environment, but must painstakingly build/install 2GB of source code-provided 3rd party libraries, before they can even build Ardour for the first time.

It's not entirely surprising that a project like this doesn't have many active developers at any given point in time!

Of course, there are other factors too: really getting into Ardour development means being comfortable with (in no particular order): real time programming, parallel/thread programming, cross-platform development, C++ idioms, model-view-controller design, the GTK+ toolkit, some level of DSP knowledge, a non-trivial understanding of audio and MIDI hardware, the MIDI protocol, and lots more. Even if Ardour was paying more developers, it would be extremely hard to find people with the right background and outlook.

When I released Ardour under the GPL, my vision was that by virtue of it being an open source project (technically orthogonal to its status as "free/libre software"), it would be possible, even encouraged, for other developers to participate and get involved in extending its capabilities. Musocity's forum thread, and their insistence that "all this should be possible by scripting" has made me wonder if this belief was ever true, and in particular if it is still true.

Why isn't the Reaper model better? Technically-inclined users can do insane things with a script, and in so doing can easily address most of the things that particular users want the program to do. Almost no Reaper user cares that they cannot build Reaper from source, cannot modify the fundamentals of the program, cannot redistribute a modified Reaper to their colleagues/friends. It matters much more to them that someone outside of the Reaper team can cook up a script that can do "just about anything". That's what freedom looks like to Reaper users (or so it appears), and giving them the source to Reaper would barely change that, if at all.

Verona touches on so many aspects of this in his piece. The demographics/background of computer users in 2020 is so very, very different from the way things were when Stallman began the concept of "free/libre software". Back then, "freedom to tinker" really did mean the freedom to read and edit source code, and to rebuild programs from source. Today, even though this is still a foundational aspect of the concept of "free/libre software", the freedom that many users want doesn't come from source code access at all. It comes from applications that enable their users to easily customize things to "about the level that most users care about".

Nevertheless, the concept of free/libre software is still vitally important to me and millions of other people. As mentioned above, even the best script extension system (or any form of program customizability) cannot replace source code (and build system) access in terms of providing the kind of freedom to tinker (and thus freedom to learn) that Stallman (and many others) envisaged.

But perhaps for applications like Ardour, ones that do not yet exist, there ought to be a different development pathway. I remember once wondering if we should have implemented the entire GUI in PyGTK (i.e. Python). We didn't, and most of my curiosity was about whether it would have helped or hindered our development process. However, had we done so, one of the consequences would have been that many changes to the program would have been made simpler, easier to access and would require no "rebuild".

I wonder if going forward, large-scale apps like Ardour ought to (as Reaper did relatively early in its life) consider the "script extension system" to be a vital and critical part of the application infrastructure. This would mean, for example, writing large parts of "core functionality" using this system, rather than dropping back into C++ to get things done. There are precedents for this: GNU Emacs, for example, is at some level written in C, but almost everything about the program is actually constructed in Emacs Lisp, its own "scripting extension". The C core of Emacs is so small and so irrelevant that it almost doesn't matter that it is there: if you want to modify or extend Emacs, you (almost always) write Lisp, not C.

Forcing the "core" developers to, as the saying goes, "eat the same shit" as regular users forces them to focus their attention on the quality of said "shit". Removing the need to rebuild the application after most changes opens the application to contributions from people who cannot deal with (1) the idea of compilation and/or (2) the reality of compilation.

Would we have attracted more developers over the years if Ardour had been more accessible to programmers with skills in Python, Javascript or Ruby? It's hard to know. I have no idea how many people (absolute or as a fraction of the user base) have written notable extensions for Reaper (or Live). It's possible that it would make no difference whatsoever, and would merely divert developer time away from one level (C++) where we can function efficiently and happily and divert it to another ("scripting extension") that doesn't actually enable much at all.

I don't know that answers to any of the questions I've mentioned above. I do know that Robin did an amazing job bringing an incredible level of scripting with Lua into Ardour, and that the things you can't do with it are very much a result of our joint intention - the intention that people who want to modify or extend Ardour should plan on working on the (open) source code for the program, not by convincing us to expand to scope of our scripting support.

But perhaps that's wrong. What do you think?

Posts: 69

Participants: 27

Read full topic

by @paul Paul Davis at February 07, 2020 06:51 AM

January 31, 2020

SFZ Format News

New year, new work in progress

The most relevant additions on the website for this month were Instruments and Modulations sections, adding slowly one by one some sample instruments libraries created and freely distribuited over the net, and documenting in a generic way the various modulations used in SFZ. Some new opcodes were also added in our database, starting from some modulation aliases like amplitude_ccN, pan_ccN and tune_ccN to the recent fil_gain. I would like to thank some people who contributed to the site, like falkTX for adding our news feed on Linuxaudio Planet, jpcima, MatFluor, PaulFd and sfw. This website is an opensource non profit project, I hope to see more people involved in the future to help make it grow.

by redtide at January 31, 2020 12:00 AM

January 29, 2020

KXStudio News

KXStudio Monthly Report (January 2020)

Hello all, another monthly report about the KXStudio project is here.

A few days ago, Carla 2.1-RC1 was announced.
As mentioned in that post, Carla's frontend move to C++ has started, for performance, reliability and debugging reasons.
It is going to be something that, even though means a lot behind the scenes, visibly nothing will change. (except performance)
Because of this, do not expect many UI related changes in Carla for the time being.

There were more package updates in the repositories. Those are:

  • lsp-plugins updated to 1.1.13
  • x42-plugins updated to 20200114
  • distrho-ports updated (added Temper as LV2 and VST plugin)
  • bchoppr added
  • bslizr added
  • bsequencer added
  • bshapr added
  • geonkick added
  • mod-cv-plugins added
  • noise-repellent added
  • regrader added

A few of those were made possible thanks to LibraZik project, from which I imported a few.
I am quite grateful for them, and you should be too! :)

On a more personal side of things, I have started renting an office for work (both for employer and FLOSS stuff).
Its setup took most of the time on the holidays, and quite a fair bit in January too.
It is mostly done now, only final touches needed. It certainly helps as a kind of motivation boost, and as a way to keep focus too.

Next month will be slower than usual, as I plan to focus more on "boring" stuff like updating the website and documentation.
That is all for now.

Since I mentioned it, I leave you with a picture of the office (the working area).
See you next month!


by falkTX at January 29, 2020 10:37 PM

January 23, 2020


Intersecting Intel & AMD Instruction Set Extensions

In some of my projects, I’ve recently had the need to utilize FMA (fused-multiply-add) or AVX instructions. Compiling C/C++ on X86_64 will by default only activate MXX and a few of the early SSE extensions. The utilized instruction set basically predates the core2 which was introduced in 2006. Math…

January 23, 2020 11:33 AM

January 18, 2020

The Linux-audio-announce Archives

[LAA] Yoshimi V 1.7.0


Just one visible change, but a major one.
Instead of a few controls giving an immediate response, there are only a few that don't :)

More details are in /doc/Yoshimi_1.7.0_features.txt

Yoshimi source code is available from either:

Full build instructions are in 'INSTALL'.

Our list archive is at:
To post, email to:
yoshimi at

Will J Godfrey
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.

by willgodfrey at (Will Godfrey) at January 18, 2020 03:20 PM

January 17, 2020

The Linux-audio-announce Archives

[LAA] Ninjas2 sample slicer plugin released (v.0.2.0)

Hi all,

I've updated Ninjas2 audio sample slicer plugin.
Source and binaries (linux/windows/mac) are available at :
readme :

>From the readme:
Easy to use sample slicer, quick slicing of sample and auto-mapping
slices to midi note numbers.

# Intended usage:
Primarily targeted at chopping up loops or short (  10 - 20 seconds)
samples. Think drum loops, vocal chops etc. Currently there's no limit
on imported sample length. User can play the slices using midi notes
and change the pitch with midi pitchbend.

# Downloads:
Linux, Windows and Mac binaries for several architectures are
available here. There are no installers, just unzip and copy the
plugin to an appropiate location.

# New Features
 - redesigned interface
 - controls are grouped in Global, Slicing and Slice
 - the Slice box shows the currently selected slice number
 - keyboard
     - click on key to play slice
     - red dot on key indicates which slice is currently selected in
the waveform display
     - keys that don't have a slice mapped to them are greyed out

# Known Bugs and Limitations
- some host don't work very well with the lv2 version
     - zrythm and qtractor had trouble with the lv2 version but worked
fine with the vst
     - ardour, carla and muse3 worked well with the lv2
- care should be taken when automating the playmodes and adsr
     - the automation is sent to the currently played note (slice),
when multiple slices are played, this leads to "undefinied behaviour"

by rghvdberg at (Rob van den Berg) at January 17, 2020 12:12 PM