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

News – Ubuntu Studio

Ubuntu Studio 19.04 reaches End Of Life

Our favorite Disco Dingo, Ubuntu Studio 19.04, has reached end-of-life and will no longer receive any updates. If you have not yet upgraded, please do so now or forever lose the ability to upgrade! Ubuntu Studio 20.04 LTS is scheduled for April of 2020. The transition from 19.10 to 20.04... Continue reading

by eeickmeyer at January 23, 2020 12:00 AM

January 21, 2020

News – Ubuntu Studio

New Website!

Ubuntu Studio has had the same website design for nearly 9 years. Today, that changed. We were approached by Shinta from Playmain, asking if they could contribute to the project by designing a new website theme for us. Today, after months of correspondence and collaboration, we are proud to unveil... Continue reading

by eeickmeyer at January 21, 2020 06:48 PM

January 20, 2020


The Big Crash at KUNSTEN.NU

My upcoming solo exhibition The Big Crash at Spanien19c in Aarhus Denmark from 8. February till 8. March is in KUNSTEN.NU

by herrsteiner ( at January 20, 2020 10:14 PM

January 19, 2020

KXStudio News

Carla 2.1 RC1 is here!

Hello again everyone, it is release day! (kinda, just a casual 4 days late...)

This is the announcement of the first release candidate of Carla 2.1.
I am skipping the beta phase as done for the 2.0 release and going straight into a Release Candidate.
This means there will be no more changes in the graphical user interface or engine/backend features, except when required for fixing bugs.

Carla projects/sessions are meant to be fully compatible between between 2.0 and 2.1 versions, except for features marked experimental.
The "native" API to access carla as plugin (as used by LMMS) is ABI and API-wise backwards compatible compatible with 2.0.
If this is not the case, consider it a bug that needs to be fixed.

As with the v2.0 release, the list of changes is a little big, so let's split it by parts.
First, the highlights and major changes, in no particular order of relevance.


Better CV Support

CV ports are now supported in the internal patchbay mode, meaning you do not need to use JACK with Carla in order to use CV plugins.

Automable parameters can now be exposed as a CV port, so they can be controlled by regular CV sources or other plugins.
This is a kinda feature preview, as there are some limitations at the moment:

  • Parameter changes are not sample accurate
    (in a later version, Carla will split buffer up to 32 frames for more fine-grained control changes)
  • Not all plugin formats and parameter types are allowed to be controlled this way
    (to be extended as I test more compatibility)
  • Only available for parameter inputs, not outputs

In order to make CV more useful by default, a new internal "MIDI to CV" plugin was added, originally created by Bram Giesen.
More plugins will be added as needed, for now I recommend to use ams-lv2 and mod-cv-plugins as they already do a lot.

Also, a new variant of Carla as plugin was created that provides audio, MIDI and 5 CV ports (for each side).
This allows CV signals to flow in and out of Carla as a plugin.


High-DPI support (work in progress)

Initial work was done to support high-DPI screens.
Note that this was not tested very extensively, due to lack of proper hardware, but the requirements in terms of code are all there.
There are still a few "normal" resolution bitmaps in use, to be replaced in future releases.
You can click on the screenshot on the left to see Carla rendered at 3x the resolution.

So for now, the situation is:

  • Most of the icons changed to scalable format
  • UI will scale with the desktop automatically, as Qt takes care of that for us
  • Some bitmaps still remain, to be replaced by vector images in a future release
  • Not extensively tested, feedback is welcome


Proper theme and Carla-Control for Windows

The Windows build stack changed from using official Python and PyQt5 packages to msys ones, allowing us to link against them using mingw (Carla does not support MSVC)
This makes it possible to use the proper "pro" theme like Linux and macOS already did, and also get Carla-Control finally working on Windows.

Previously, the Carla Windows builds were using Qt's "fusion" theme (which the Carla "pro" theme is based on), which looks very similar but misses all of custom tweaks made for Carla.
This includes, for example, preventing pop-up menus from taking the entire screen or ugly thick lines being drawn where a small one was expected.

A small but important step towards cross-platform feature parity. \o/


VST2 plugin for macOS and Windows, plus exposed parameters

This is the final item that was missing for cross-platform feature parity.
We now have Carla as VST2 plugin running on both macOS and Windows!

Embedding of the full GUI on these systems is not possible, so a small "middleware" window is shown as the plugin custom UI.
Not the best experience, but allows Carla to finally work as VST2.

Additionally, 100 parameters are exposed to the host, dynamically used in the order of the plugins loaded.
So for example, if the first plugin in the rack has 20 parameters, the first 20 parameters of carla-vst will be mapped to that plugin.
This continues in order for the remaining plugin parameters until we reach 100 of them.

When Carla is loaded as an internal plugin, parameters will be dynamically available too.
This feature is not available in the LV2 version of Carla though, at least not yet.

Note: Carla plugins are not "notarized" yet, so they will not run under latest macOS 10.15/Catalina where this is a requirement.


Wine-native bridge, sorta experimental

This is a way to load Linux binaries under Windows applications running with Wine, in case you need that for some reason
Personally I made it so that I could run the native Carla inside FL Studio, which allows me to use its sequencer but not have to deal with Windows plugins.

This is available in the KXStudio repositories as "carla-vst-wine" package, you need to copy /usr/lib/winvst/Carla* into your Wine VST dll folder to make it work.
It requires Carla to be installed system-wide, so it cannot work if Carla is downloaded manually.

Building it is kinda tricky, as it requires building a native-windows dll first, and then a few things with winegcc...
Packager documentation will be added soon to Carla's source code repository, so other Linux distributions can pick it up.

I demoed this feature at Sonoj last year (2019), you can watch it as the 3rd part of this video.


Refreshed add-plugin dialog and favorite plugins

The add-plugin dialog had a major overhaul, now looking much better and with more content visible at once.
Target was to improve the user experience, making clear that there are filters available. (it was not so obvious in previous versions)

The star on the most-left section of the table is to mark a plugin as a favorite, which will add it as a shortcut to the right-click menus on empty rack and patchbay areas.


Single-page and grouped plugin parameters

The dialog for the generic plugin parameter view also had an update.
All parameters are now placed in the same tab (separated only by input and output types), and grouped when supported by the plugin.
The options for mapping a parameter to a MIDI CC were taken out and replaced by a button that triggers a menu with the relevant options.

Note that, at the moment, only a few LV2 plugins support parameter groups.
This is because most hosts do not support this feature, so plugins do not have many incentives to support such a thing.
And with not a lot of plugins supporting it, hosts also do not care that much. The usual circular dependency deal...
But since the feature applies quite nicely to Carla, made sense to add it.

The group can be collapsed by clicking on it.

A similar feature will be added to the patchbay in a later release, so we can group audio ports too. :)

More UI changes

The rack items will dynamically show as many knobs as possible
You can now change the "skin" and color of any rack item, making it easy to identify certain plugins
Added buffer-size, sample-rate and xrun information to the status; clicking on the xrun counter will reset it to zero

Canvas changes

Right-clicking on a canvas group will show options for quickly connecting all ports to another group
Many small tweaks and fixes, plus a few extra actions, as contributed by Nikita Zlobin (to be documented on the user manual)
Support for Ardour-style inline-displays, marked experimental in this release (sadly cannot be made stable until Carla v3.0)

Carla-control and OSC rework

Carla's OSC support has been reworked, now has its own dedicated page in the settings.
Carla-Control has been extended to support all non-local-dependent features of the main Carla (like patchbay management and transport controls).
This will be extended even further in future releases.

AU and VST3 support is back, by leveraging JUCE

Disabled during a previous 2.0 beta release, support for the JUCE library was removed and replaced by a heavily stripped-down version of it. (while it was still GPlv2 licensed)
The reasons for that decision still remain relevant, but in order to keep in mind with Carla's goals, I decided to add back JUCE support - but now completely optional.
It will always be possible to build Carla without JUCE, it is only used for extra hardware and plugin format support.
In fact, Linux builds by default do not use it, as there is no need for it.

Anyway, the published macOS and Windows Carla builds do use JUCE, which means Carla supports VST3 under macOS and Windows, and AU under macOS.
As a bonus, it is now possible to show the custom control panel of ASIO devices. :)

Worth noting is that JUCE does not support VST3 under Linux at this point, so neither does Carla even if you build it yourself with JUCE enabled.

Other changes

Within a bunch of small fixes and new implementations, here are some changes that deserve to be mentioned:

  • Carla now requires Qt5, can no longer work with Qt4; but can still use LV2 Qt4 UIs with its built-in bridges
  • NSM is now supported for JACK applications
  • Added a 16 MIDI port mode for JACK applications
  • Added "Cancelable actions" during project and plugin bridges load, so they will no longer time-out; instead the user has the option to cancel them at anytime
  • Initial support for LV2 parameter API
  • Initial support for LV2 file paths, assuming plugin has no custom UI (click on the show-gui button to open a file dialog)

Notes for developers and packagers

  • Linking against the JACK library directly is now possible by using `make JACKBRIDGE_DIRECT=true`, which allows for building Carla as an internal client

Notes for users

The code for scanning plugins had a little rework, again, making some internal data structures change.
Because of this, a full rescan of your plugins is needed after the update.


To download Carla binaries or source code, jump on over to the KXStudio downloads section.
If you're using the KXStudio repositories, you can simply install "carla-git" (plus "carla-lv2" and "carla-vst" if you're so inclined).
Bug reports and feature requests are welcome! Jump on over to the Carla's Github project page for those.

Future and final notes

I have started a change of the Carla's frontend coding language, from Python to C++ (for performance, reliability and debugging reasons).
There are a few canvas related things, currently experimental, that can never be made stable or fast due to how Python/PyQt works.
Also Carla is not scaling very well at the moment, and the addition of CV controlled parameters and inline-displays does not help its case.
So a move of the entire frontend to C++ makes quite a lot of sense.
Whenever this is finished a new release will be made.
But 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.

A user manual for Carla has been started.
It proved to be quite helpful for development too, as I had to justify why things are the way they are, and explain how they work too.
Now that Carla UI should not change too much for a while, it is the right time for such thing.
I personally dislike writing such things, but understand it can be quite useful.
The work-in-progress manual is at
(Not much to see there at the moment though, give me time)

That's it.
Please remember that this is a release candidate, and not the final release.
Some issues are expected, I will do my best to fix all reports that get to me.
If I don't know about the issues though, I can't fix them. So please report any issues you find, thanks!

by falkTX at January 19, 2020 02:13 PM

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

January 15, 2020


Notstandskomitee musicvideo

Musicvideo for the track Ultracapacitor by Notstandskomitee from the album Deleted, released at the end of 2019 by the French label Serendip Lab. CGI created in Blender...

by herrsteiner ( at January 15, 2020 09:33 PM

January 06, 2020

digital audio hacks – Hackaday

Organic Audio: Putting Carrots as Audio Couplers To The Test

[Boltz999]'s carrot interconnect.
[Boltz999]’s carrot interconnect.
If there’s one thing that gives us joy here at Hackaday it’s a story of audio silliness. There is a rich vein of dubious products aimed at audiophiles which just beg to be made fun of, and once in a while we oblige. But sometimes an odd piece of audio equipment emerges with another purpose. Take [Boltz999]’s interconnects for example, which were born of necessity when there were no female-to-female phono adapters to connect a set of cables. Taking a baby carrot and simply plugging the phonos into its flesh delivered an audio connectivity solution that worked.

Does this mean that our gold-nanoparticle-plated oxygen-free directional audio cables are junk, and we should be heading for the supermarket to pick up a bag of root vegetables instead? I set out to test this new material in the secret Hackaday audio lab, located on an anonymous 1970s industrial estate in Milton Keynes, UK.

Characterising A Root Vegetable

The high point of an engineer's life comes as they measure the electrical properties of a root vegetable.
The high point of an engineer’s life comes as they measure the electrical properties of a root vegetable.

A quick search on the composition of a carrot reveals an 88% water content, with the other 12% being mostly carbohydrates, followed by small quantities of fat, protein, and a cocktail of those vitamins and minerals that caused our parents to be so enthusiastic about our younger selves eating them. In particular about 0.4% of a carrot is comprised of potassium, sodium, and calcium ions in solution, making the vegetable analagous to a sponge soaked in a weak electrolyte solution. Thus you’d expect it to be conductive, and to pass a line-level audio signal into a high-impedance load such as an audio amplifier. A quick DC resistance measurement of our test carrot showed a resistance that started at about 50K for distances up to about 10mm, rising slowly to near 100K across its roughly 80mm length. It’s probably beyond the scope of this piece, to characterise the complex impedance of a carrot.

Attenuator Π-section circuit by SpinningSpark CC-BY-SA 3.0. R2 represents the width of the carrot, R1 and R3 each represent the carrot distance between pin and outer of a phono plug.

The hack that prompted all this though didn’t simply replace the pair of copper wires with ones made of carrot. By plugging the phono into the tap root an extra 50K resistance is created between its two conductors as well as between it and the other phono, and the result is a resistor network. Because it’s not an unreasonable assumption the two pieces of hi-fi equipment in the same rack could share an earth, rather than disappear down the rabbit hole of infinite meshes of resistors  it’s probably safe instead to think of it as something closer to the familiar Pi network attenuator. There are plenty of online calculators that could give you a performance figure for a given network, but in this case with so many approximations and carrot-related guesses their results would be rather meaningless. All that we need to know is that there will be some attenuation of any audio fed into the carrot.

Crisp Treble, and a Crunchy Midrange

The square wave performance of a carrot
The square wave performance of a carrot

Having discussed the theory, it’s time to move onto the practice. Standing in for a high-end audio source was my phone playing YouTube videos, and for a high-end hi-fi a set of amplified computer speakers. Surprisingly it worked, but unsurprisingly in doing so there was a noticeable attenuation that cut the volume by around half. Exactly as expected, but there was a further step of taking a look at it with a ‘scope.

Applying a handy 1kHz squarewave a 30% attenuation was immediately obvious (as well as that maybe the secret lab’s ‘scope probes needed adjusting). We lacked an audio analyser to measure the harmonic distortion of the coupling, but there has to come a point at which characterising a vegetable comes to an end.

So, we’ve proved the original story to be true, you can use a carrot in an audio interconnect. But how would we describe its sound? The answer if you are fond of audiophile reviews is that it adds an organic feel to the broader soundstage, with crisp treble notes, a crunchy midrange, and deep, earthy bass tones. Meanwhile if you are simply looking for something to connect two cables, we’d suggest a carrot sounds better in the roasting pan.

Header image: Sajetpa [CC BY-SA 3.0]

by Jenny List at January 06, 2020 06:01 PM

December 29, 2019

Ardour: 20th birthday

@paul wrote:

It’s hard to pinpoint the precise day that a project like Ardour started. But if that’s the goal, then right now, December 28th 1999 is probably about as good a date as any. That means that today Ardour is 20 years old.

It’s hard to write this, let alone read it. If you had told me back in the last few days of 1999 that I was starting something that would last (at least) two decades, I really do not think I would have believed you. But I did start, and it has lasted, and so I thought that it would be worthwhile to put down on paper the story of how it started. I’ve told this story in person to countless people, and even described it at several conferences and meetings, but I’d like this version to be considered definitive.


In the winter of 1996, I left to become a stay-at-home parent to my 1 year old daughter. By 1998 her mother, worried that I was vanishing into what I lovingly referred to as “the zen of parenting” started to encourage me to pick up some of my own hobbies to balance the time spent with a very young child. I decided to start ultra-distance cycling again, something I had enjoyed before she was born (and was quite good at, which helps). I also decided to pursue my lifelong interest in electronic music, but this time by trying to make music myself. After a brief consultation with a student I had known from the University of Washington who was into some of the same sort of music as I was thinking of making, I ended up buying an Oberheim Matrix 6 synthesizer, a Doepfer MAQ16 sequencer and an Alesis FX unit. It didn’t take long before I started to realize that I would probably benefit from having a computer as part of whatever process I was developing.

Strange as it might seem, since I had already been a programmer since the mid-1980s, this was a troubling thought, because I had avoided having a computer at home until that time. I did have an X Terminal at home for a while during the period that I worked for Amazon, but this didn’t really count as a computer in the conventional sense. There was the dilemma that a Mac was clearly overpriced and I had taken a vow (yes, really) in the 1980s that I would never use Windows. While at Amazon, I had pushed for us to use Linux (Slackware) as the basis for a machine that we called “CC Motel” (as in “Credit Cards check in but they don’t check out”, a riff on a popular meme), and I had been working on Unix-based systems since 1986, so the idea of setting up a Linux machine seemed like an obvious one.

I ended up buying a second hand 486, deliberately staying well behind the leading edge so as to discourage me from doing more on the machine, and picked up a Turtle Beach Tropez+ audio interface for it. I installed an early version of Red Hat on the machine, eager to use a program I had found called “Multitrack” which promised to be a multitrack, multichannel digital audio workstation, or something like that.

It turned out that there was no device driver for the Tropez+ (I think there was for the Tropez, and I had assumed they were similar, driver-compatible hardware). I had written device drivers before, and wasn’t too intimidated by the idea of needing to do this. It didn’t take too long, although I also wrote a patch editor for the Tropez+ which was of some use since it had a wavetable synth on board. I never used that for anything, as it turned out.

Quite against my original intention, I was programming again, a few years after I thought I had decided to give it up for good. The original plan had been that my daughter’s mother would finish her post-doc in Philadelphia, we would all move back to the Pacific Northwest, I would become a farmer with the time to slowly bring a small farm into production my way while mom did research and teaching at some PNW institution. It didn’t quite work out like that. By the summer of 1999 we were divorced, and I had already written a couple of MIDI software tools to “help with my music”. The farming idea began to really slip away as that year rolled on, as I recognized that my energy had really been refocused on software, albeit in a wholly new context - music, audio and open source. (The phrase “my energy” refers to whatever I had left over after being the at-home parent for a 3 year old, which was still my primary role in life.)


Sometime during 1999, I became aware of the RME Digi series of audio interfaces. I still wasn’t really making any music, and so like most music gearheads decided that more equipment was obviously the answer. How could having 24 channels of I/O not help my compositional and performance processes? Winfried Rietsch in Vienna had already written a Linux driver for the RME card but his was based on the increasingly obsolete “OSS” audio driver architecture. I decided to take his work and use it as the basis of a driver for the ALSA system, which was more or less established by then as the new audio driver architecture for Linux. RME were helpful and cooperative (as they had been with Winfried), and by sometime in early December of 1999, I had a working ALSA driver for the massively multichannel (by the standards of that era) device.


Which then led to a fundamental problem: I had a working 24 channel I/O device for Linux, but what was I going to do with it? From reading around (Electronic Musician and Sound On Sound magazines in particular), it was obvious that I needed a “Digital Audio Workstation”. It had turned out that “Multitrack” was utterly useless. Another application, “Jazz++” seemed promising but on deeper investigation was also very, very far from doing what a DAW would do. I decided to call the company that made the 800lb gorilla of the DAW world, called “ProTools”. At that time PT was primarily a macOS application that had only recently appeared for Windows (and even then, was only supported on a single piece of Windows hardware).


I managed to get forwarded through a couple of layers at Digidesign and finally found myself talking to someone who seemed to understand what I was talking about. I asked them for the source code and offered to port ProTools to Linux, free of charge. They laughed, and made it clear that this was never, ever going to happen. I remember ending the phone call with an offhand remark to the effect of “oh well, I’ll just write it from scratch on my own”.


My daughter was going to spend New Years with her mother that year, and so on about December 28th 1999, I sat down and started to write what was initially going to be a 24 track hard disk recorder and playback application. It was initially called HDR32/96, the numbers coming from the fact that it recorded 32 bit floating point data to disk, and could function at up to 96kHz sample rates (though to be honest, it didn’t really care). It took me about 3-4 weeks to get this working (borrowing button images from the photographs of the relatively Mackie HDR24 which had just come out!).

So there it was: I could record and playback 24 channels of high quality digital audio on my Linux machine. Exciting, no?


Well, no was the answer. Being able to just record and playback really seemed like a very uninteresting capability the moment it was available. You could not edit the sound in any way at all, which from the perspective of creating music seemed like a total non-starter. I continued to work on polishing aspects of the program, and announced it in the still fairly nascent linux audio community. A young programmer called Taybin Rutkin soon got involved with the project, bringing lots of nice idiomatic C++ aspects to the codebase, and we would talk on the ardour-dev mailing list about what to do about the program’s inability to edit.

There was an exciting extremely powerful and supremely geeky audio editor called “snd”. Its developer, the venerable Bill Schottstaedt, ported it to GTK+ over a single weekend, mostly at our prompting, and this encouraged us to go down the path of merging snd and ardour. snd appeared insanely powerful - this was long before I really understood what “non-linear, non-destructive” editing really meant - and even had a Lisp interpreter builtin which seemed to allow for unimaginable possibilities. Alas, snd stumbled over something much more basic. Like so many audio projects of the time - certainly the open source ones - it assumed that you could either load all the audio into memory, and if not that, then you could read it from disk on-demand without any problems. Neither of these were (or are) true for the sorts of projects I imagined Ardour being useful for, which at that time were imagined to be something like 18GB of data spread across 24 tracks. snd could barely handle 6 tracks at that time, and even then it wasn’t reliable in terms of playback or recording without clicks and pops.


So, somewhere in the middle of 2000, Taybin and I decided that we would just write our own editor for Ardour. “How hard can it be?” we said to ourselves, and got started.


In a few days, it will be 2020. The editor is still a work in progress. Some of the features that Ardour had back in 2000 are announced with great pride in the new releases of other DAWs. Some of the most basic features of ProTools are still not available in Ardour. Some of Ardour’s design has crept into other DAWs without much fanfare, but we know where they got the idea :slight_smile: Somebody starts the program somewhere on earth (at least) every 3 minutes, all day every day. The income from Ardour has grown to levels that are largely unprecedented for niche creation-centric applications in the open source world.


Every day I am thankful for the life that Ardour’s users have allowed me to lead for the last 20 years. Every day I am thankful for the incredible contributions of the nearly 80 other developers that have contributed to the program over the last 20 years. 20 years is a long time for a piece of software to be around, though in the DAW world, perhaps less so. It is notable that Ableton Live began its life at about the same time as Ardour, and has completely changed the zeitgeist of computer-based music production as well as creating jobs for hundreds of people and making a lot of money. By that standard, Ardour hasn’t been that much of a success. But I always remember the night desk man at a little hotel in Paris who told my daughter that his band used Ardour to record themselves every week. I think of the laptops that were distributed into the favelas of Brazil with Linux and Ardour preloaded. I remember the screenshot of Ardour recording the chatter during the Mars lander launch at NASA. And I remember everyone who has made Ardour what it is today. I can’t promise anything about the next 20 years, but I will do everything I can to keep advancing and improving Ardour in small and big ways. If you’ve been here since the beginning, THANK YOU. If you’ve just discovered Ardour, stick around - it should be a fun ride!

Posts: 27

Participants: 26

Read full topic

by @paul Paul Davis at December 29, 2019 02:44 AM

SFZ Format News

Happy new year!

Here we are with the latest relevant updates, the last ones for this year:

  • Added *_mod and *_dynamic opcodes
  • Added Cakewalk SFZv2 opcodes (work in progress) page
  • Added the SFZ test suite for sample instruments developers in homepage
  • Improved SFZ syntax highlighting in Google Prettify for all pages
  • Search now works correctly, though it is slow and needs some more improvements

Happy new year!

by RedTide at December 29, 2019 12:00 AM

December 28, 2019

Qtractor 0.9.12 - The QStuff* Winter'19 Release batch #3

Greetings, just one last time!

Qtractor 0.9.12 (winter'19) is released!

The change-log is rather short but nevertheless:

  • Basic key-signature has been added to tempo, time-signature and location markers map.
  • MIDI Clip editor (aka. piano-roll) horizontal and vertical splitter sizes, widths and heights resp. are now preserved as user preferences and also to session state.
  • Second attempt to fix the yet non-official though CMake build configuration.


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 && Happy new year/decade's eve.

Donate to

by rncbc at December 28, 2019 12:00 PM

December 26, 2019

Vee One Suite 0.9.12 - The QStuff* Winter'19 Release batch #2

Greetings, a second time!

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 here and now released, making it for the second QStuff* Winter'19 batch of the season.

All delivered in dual form:

  • 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.

Changes for this special season are pretty much the same for all the gang-of-four:

  • Custom color (palette) theme editor introduced; color (palette) theme changes are now effective immediately, except on default.
  • Second attempt to fix the yet non-official though CMake build configuration.
  • Move QApplication construction/destruction from LV2 UI to plug-in instantiation and cleanup.

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.12 (winter'19) is out!

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.12 (winter'19) is out!

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.12 (winter'19) is out!

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.12 (winter'19) is out!

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 && Have fun!

by rncbc at December 26, 2019 07:00 PM

December 18, 2019

GStreamer News

GStreamer Rust bindings 0.15.0 release

A new version of the GStreamer Rust bindings, 0.15.0, was released.

As usual this release follows the latest gtk-rs release, and a new version of the GStreamer plugins written in Rust was also released.

This new version features a lot of newly bound API for creating subclasses of various GStreamer types: GstPreset, GstTagSetter, GstClock, GstSystemClock, GstAudioSink, GstAudioSrc, GstDevice, GstDeviceProvider, GstAudioDecoder and GstAudioEncoder.

In addition to that, a lot of bugfixes and further API improvements have happened over the last few months that should make development of GStreamer applications or plugins in Rust as convenient as possible.

A new release of the GStreamer Rust plugins will follow in the next days.

Details can be found in the release notes for gstreamer-rs and gstreamer-rs-sys.

The code and documentation for the bindings is available on the GitLab

as well as on

If you find any bugs, missing features or other issues please report them in GitLab.

December 18, 2019 05:00 PM

December 16, 2019

KXStudio News

KXStudio Monthly Report (December 2019)

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

There is not a whole lot of new exciting stuff this time around, as most of the time was spent on Carla new features and bug-fixing.
I am doing a push towards CV support in Carla (a "MIDI to CV" internal plugin was added, for example),
with only 1 new feature to be implemented - allowing to automate any regular parameter with CV.
The idea is to make it easier to automate things in Carla, by exposing individual parameters in the patchbay as CV ports.
There is only 1 month left for the planned release, so going to be tight on time, but still seems doable, specially with holidays coming.
(so more free time to work on this)

There were a few minor package updates in the repositories. Those are:

  • x42-plugins updated to 20191215
  • zam-plugins updated to 3.12
  • sequencer64 added (Qt5 build from git master)

A new small extra repository has been created, one I have been using for some time now.
This came out of the necessity to update JACK2, but JACK not being something we can distribute in generic packages like KXStudio does for applications and plugins.
A few pieces of software, like JACK2 and other libraries, cannot be made into generic deb packages.
So, I want to create a few small but nice repositories for basic utilities and nice-to-have things.
For now, I have created a first, small one for Ubuntu 18.04 users (which includes me, obviously :P) which contains an updated JACK2, Wine-RT, among other small things.
You can find more details about this repository and all future ones coming soon at

In some news regarding the JACK2 project, it has its own news page now, so I won't be posting JACK2 related stuff here anymore.
The latest about it, which is worth mentioning, is that its mailing list is back online once again! \o/

Cadence v0.9.1 was released, just tagging it in its git repo so distributions can pick it up.
It was mostly needed due to an incompatibility with Python 3.8.

And finally, donations for the KXStudio project (basically myself) are open once again, now even with a Patreon page.
In the past I mentioned that, due to legal costs, it was not worth having them while in Germany and I would open them again once I moved.
That happened a few months ago, but I dislike dealing with these things, so it took some time...
They are open once again now, though I removed the PayPal subscription option and counter for now.
(I am intentionally not posting the link here, I trust that if you care enough, you know where to find it)

Next month hopefully a new Carla release will be here.
Catia will be made into a standalone project, leaving Cadence behind. But that is news for another time... :)

by falkTX at December 16, 2019 09:42 PM

JACK Audio Connection Kit News

JACK mailing list is back!

The mailing list for the JACK Audio project is back! You can now find it here.

The archive was restored, but not the subscriber list (due to technical difficulties). You will have to re-subscribe in order to keep using the JACK mailing list.

by falkTX at December 16, 2019 12:00 AM

December 11, 2019

linux-audio « Tag Feed

How to fix Debian/Slax Linux playing no sound on laptops

I encountered this issue while trying to boot a Slax Linux ( image on a laptop. I’ve read that this issue sometimes occurs on Debian as well, which is plausible since Slax is based off Debian now. I haven’t tested the fix on Debian yet, but it should work in theory since they’re related.

The issue in itself is the user not being able to play audio and encountering errors like these:

VLC fails to play audio

ALSA Basic Audio Test fails

speaker-test fails










There are multiple ways to fix this problem, some more simpler than the other. The crux of the matter is Linux detecting multiple audio devices and using one that’s not actually in use (example: using the missing HDMI audio output as default instead of the usuable analog). We fix it by changing the default audio card.

Method 1: setting the ALSA configuration file at /etc/asound.conf or ~/.asoundrc

ALSA stands for Advanced Linux Sound Architecture, the framework that connects the Linux kernel with sound card drivers. We need to configure ALSA so that it uses the correct sound card for audio playback.

The /etc/ directory is used to hold configuration files. Our ALSA config file needs to be named asound.conf. We need to find the id numbers of our connected sound cards and create the asound.conf configuration file to set our desired device as the default. From the ALSA project wiki [ and], we can see the ids of the connected sound cards with the command:

cat /proc/asound/cards

cat /proc/asound/cards

We can also list all sound cards with aplay -l

aplay -l

We can then use any text editor to make the asound.conf config file and put the following text in it:

pcm.!default {
type hw
card 1
ctl.!default {
type hw
card 1


defaults.pcm.card 1
defaults.ctl.card 1

Editing asound.conf

I’m using the id 1 to set the Intel PCH analog sound card as the default instead of the HDMI card which clearly doesn’t work since it’s not connected to an HDMI output. Replace 1 with the id of whichever card you want to use. Save the file and exit. The audio should start working now.

Alternatively, instead of making /etc/asound.conf you can create .asoundrc in your home directory instead. This is useful if only want to make changes for your own user and not system-wide (which is what happens with asound.conf).

Method 2: Using PulseAudio

PulseAudio is a sound server that works with ALSA and routes audio streams. It comes pre-installed with most Linux distributions and desktop environments. However, Slax itself doesn’t come with PulseAudio. We’ll need an internet connection to download PulseAudio on Slax. Use apt to install it:

apt-get install pulseaudio

[use sudo apt-get install pulseaudio if you’re not root/superuser]

Start the PulseAudio server with the command:

pulseaudio --start

Now, use the pactl command to set the correct sound card as the audio source for PulseAudio. The PulseAudio server system uses sinks to get and play audio from sound sources

pactl list short sinks       #list all sinks
pactl list short sources     #list all sources
pactl set-default-sink 0     #set default sink, replace 0 with your desired sink id
pactl set-default-source 1   #set default source, replace 1 with your desired source id

Match the correct sound sink to sound source with pactl

You can also alternatively use pacmd for an interactive shell to configure PulseAudio. The commands are essentially the same.

by Suryansh at December 11, 2019 10:51 PM

December 07, 2019

Internet Archive - Collection: osmpodcast

An error occurred

The RSS feed is currently experiencing technical difficulties. The error is: invalid or no response from Elasticsearch

December 07, 2019 03:01 AM

December 05, 2019

Linux – CDM Create Digital Music

Reaper 6 is here – and even more the everyday, budget DAW to beat

It’s got a $60 license for nearly everyone, you can evaluate it for free, and now Reaper – yet again – adds a ton of well-implemented power features. Reaper 6 is the newest edition of this exceptionally capable DAW.

New in this release:

Use effects plug-ins right from the tracks/mixer view. So, some DAWs already have something like a little EQ that you can see in the channel strip visually, or maybe a simple compressor. Reaper has gone further, with small versions of the UI for a bunch of popular plug-ins you can embed wherever you want. That means less jumping in and out of windows while you patch.

You get EQ, filtering, compressor, and more. (ReaEQ, ReaFIR, ReaXcomp, graphical JSFX, etc.)

Powerful routing/patching. The Routing Diagram feature gives you an overview of how audio signal is routed throughout the environment, which makes sends and effects and busing and sidechaining and so on visual. It’s like having a graphical patchbay for audio right inside the DAW. (Or it’s like the ghost of the Logic Pro Environment came back and this time, average people actually wanted to use it. )

Auto-stretch audio. Now, various DAWs have attempted this – you want sound to automatically stretch and conform as you adjust tempo or make complex tempo changes. That’s useful for film scoring, for creative purposes, and just because, well, you want things to work that way. Now Reaper’s developers say they’ve made it easy to do this with tempo-mapped and live-recorded materials (Auto-stretch Timebase). This is one we’ll have to test.

Make real envelopes for MIDI. You can draw continuous shapes for your MIDI control adjustments, complete with curve adjustment. That’s a bit like what you get in Ableton Live’s clip envelopes, as well as other DAWs. But it’s a welcome addition to Reaper, which increasingly starts to share the depth of other older DAWs, without the same UI complexity (cough).

It works with high-density displays on Mac and PC. That’s Retina on Mac and the awkwardly-named HiDPI on PC. But the basic idea is, you can natively scale the default theme to 100%, 150%, and 250% on new high-def displays without squinting. Speaking of which

There’s a new tweakable theme. The new theme is set up to be customizable with Tweaker script.

Big projects and displays work better. The developers say they’ve “vastly” optimized 200+ track-count projects. On the Mac, you also get faster screen drawing with support for Apple’s Metal API. (Yeah, everyone griped about that being Mac-only and proprietary, but it seems savvy developers are just writing for it and liking it. I’m honestly unsure what the exact performance implications are of doing the same thing on Windows, though on the other hand I’m happy with how Reaper performs everywhere.)

And more. ” Dynamic Split improvements; import and render media with embedded transient information; per-track positive or negative playback offset; faster and higher quality samplerate conversion; and many other fixes and improvements.”

Honestly, I’m already won over by some of these changes, and I had been shifting conventional DAW editing work to Reaper as it was. (That is, sure, Ableton Live and Bitwig Studio and Reason and whatever else are fun for production, but sometimes you want a single DAW for editing and mixdown that is none of those others.)

Where Reaper stands out is its extraordinary budget price and its no-nonsense, dead-simple UI – when you really don’t want the DAW to be too creative, because you want to get to work. It does that, but still has the depth of functionality and customization that means you feel you’re unlikely to outgrow it. That’s not a knock on other excellent DAW choices, but those developers should seriously consider Reaper as real competition. Ask some users out there, and you’ll hear this name a lot.

Now if they just finish that “experimental” native Linux build, they’ll really win some nerd hearts.

Those of you who are deeper into the tool, do let us know if you’ve got some tips to share.

The post Reaper 6 is here – and even more the everyday, budget DAW to beat appeared first on CDM Create Digital Music.

by Peter Kirn at December 05, 2019 05:47 PM

digital audio hacks – Hackaday

A STM32 Tonewheel Organ Without A Single Tonewheel

The one thing you might be surprised not to find in [Laurent]’s beautiful tonewheel organ build is any tonewheels at all.

Tonewheels were an early way to produce electronic organ sounds: by spinning a toothed wheel at different frequencies and transcending the signal one way or another it was possible to synthesize quite an array of sounds. We like to imagine that they’re all still there in [Laruent]’s organ, albeit very tiny, but the truth is that they’re being synthesized entirely on an STM32 micro controller.

The build itself is beautiful and extremely professional looking. We were unaware that it was possible to buy keybeds for a custom synthesizer, but a model from FATAR sits at the center of the show. There’s a MIDI encoder board and a Nucleo development board inside, tied together with a custom PCB. The UI is an momentary encoder wheel and a display from Mikroelektronika.

You can see and hear this beautiful instrument in the video after the break.

by Gerrit Coetzee at December 05, 2019 04:30 PM