Ubuntu Studio 20.04 LTS Released

by Ubuntu Studio, at April 23, 2020 05:41:07 PM

The Ubuntu Studio team is pleased to announce the release of Ubuntu Studio 20.04, code-named “Focal Fossa”. This marks Ubuntu Studio’s 27th release. This release is a Long-Term Support release and as such, it is supported for 3 years (until April 2023). Since it’s just out, you may experience some… Continue reading

Development update: 6.0-rc1 tagged

by Ardour Blog, at April 18, 2020 10:57:53 PM

@paul wrote:

It’s been a productive 3 weeks since we tagged the current code as “6.0-pre1”. Roughly 400 or so commits (changes) later, we’re now marking the current code as “6.0-rc1”, which means:

1. no more translatable string changes before release (i.e. no major user-visible changes). Translators can now finish their work with high confidence that if they complete a translation, there will be no need to revisit it before 6.0 is released.

2. No substantial changes between now and the release of 6.0

We welcome bug reports and feature requests on tracker.ardour.org as always.

Two notable “newish” features that have landed since pre1 are

• Ardour now supports web interfaces via a websocket and JSON protocol. Luciano Iam was responsible for this work, and has already added a couple of demo “web pages” to show browser control of Ardour. We imagine/hope that this new “control surface” support will expand significantly during the post-6.0 development process. Start Ardour, enable websocket surface support, and point your browser at http://localhost:3818/ … then get busy with some HTML/CSS/JS. It must be stressed that this all preliminary work, and is not considered “finished”. However, it is open for significant contributions by non-C++ developers now.

• MIDI editing keybindings (shift notes in time and pitch, change velocities etc. etc.) are now all user-definable rather than hard-coded. The key editor now provides a handy reference for keyboard shortcuts when editing MIDI notes.

Posts: 25

Participants: 11

Read full topic

audiowmark – Audio Watermarking

by Stefan Westerfeld's blog, at April 18, 2020 06:56:28 PM

In 2018, a company I was working for asked me to develop an open source solution for audio watermarking. At that point, we didn’t even find a single open source software that would be close to being usable in production.

As a result, today I am making the source code of “audiowmark” publically available under GNU GPL3 or later. It has many features, it is robust, fast, secure and of course we believe that the watermark is not audible for most users.

More infos, source code and audio demos are available on the audiowmark web page.

Carla 2.1 is here!

by KXStudio, at April 15, 2020 10:39:54 PM

Exactly one year after 2.0, Carla version 2.1 is here!

Carla is an audio plugin host, with support for many audio drivers and plugin formats.
It has some nice features like automation of parameters via MIDI CC (and send output back as MIDI too) and full OSC control.

This is a small but significant update that builds up on top of what was released in 2.0.
Please see the 2.1-RC1 announcement for details on what is is new in 2.1.

Unlike last time, there are no official plans for version 2.2 just yet, my focus will now be going into the DPF and JACK projects instead.
The master branch of Carla's code repository is now for 2.1, while the previous 2.0 master got renamed "hotfix-2.0.0".
No new features will be added to 2.1 series, only bugfixes.

Changes since 2.1-RC2

• Add a simple cv2audio plugin
• Brown color for CV ports, to make them more easily recognizable
• Fix crash loading LV2 plugin with CV and latency ports
• Fix mingw/gcc-9 build

Changes between 2.1-RC2 and 2.1-RC1

• Fix crash on stack unwind for a few operations
• Fix duplicate data (name, label, uid) used in VST synth/fx Shell plugin
• Fix JACK metadata usage for multiple carla instances and plugin renames
• Fix MIDI CC assignment showing wrong selected value (base 16 vs 10)
• Fixup carla-control (was broken in RC1)
• Optimize and reduce memory usage of UI bridges
• Overall fix of postponed RT events
• Give focus to bridged UIs when first shown
• Ignore any LV2 patch:writable that is not an lv2:Parameter
• Rename experimental "prevent bad things" option and give it a tool-tip
• Support the new LV2 UI requestParameterValue API
• Support the new LV2 UI background/foreground color API
• Many other miscellaneous bug fixes, see the git log for details

Downloads

To download Carla binaries or source code, jump on over to the KXStudio downloads section.
Carla v2.1 is available pre-packaged in the KXStudio repositories, ArchLinux and Ubuntu since 20.04. On those you can simply install the carla package.
Bug reports and feature requests are welcome! Jump on over to the Carla's Github project page for those.

Patchage 1.0.2

by drobilla.net - LAD, at April 09, 2020 04:29:00 PM

Patchage 1.0.2 has been released. Patchage is a modular patch bay for Jack and ALSA based audio/MIDI systems.

Changes:

• Add support for exporting canvas as PDF
• Bring back Jack buffer size selector
• Configure based on compiler target OS for cross-compilation
• Don't install 512x512 icons
• Fix compilation with Jack DBus
• Order ports deterministically
• Restore messages pane visibility and height
• Save window size and position when closed via window manager
• Style messages pane to match canvas
• Support Jack CV and OSC via metadata
• Upgrade to waf 2.0.19

Ganv 1.6.0

by drobilla.net - LAD, at April 09, 2020 03:45:00 PM

Ganv 1.6.0 has been released. Ganv is an interactive Gtk canvas widget for graph-based interfaces (patchers, modular synthesizers, finite state automata, interactive graphs, etc). For more information, see http://drobilla.net/software/ganv.

Changes:

• Add API to specify module port order.
• Add support for PDF and PS export.
• Add support for beveled box corners.
• Add support for edges that do not constrain the layout.
• Dampen sprung layout energy over time to prevent oscillation.
• Distinguish edge color from port color slighly.
• Fix compilation with --no-fdgl (patch from Vlad Glagolev).
• Fix crash when destroying canvas.
• Fix port position on modules with embedded widgets.
• Fix positioning of embedded widgets when changing layout.
• Fix size of vertical flow modules.
• Fix unexpected node jumping when dragging new connections.
• Fix various minor visual alignment/sizing issues.
• Highlight connected edges on port hover.
• Improve appearance of graphs with circle nodes.
• Improve text rendering at high zoom.
• Improve update performance.
• Preserve selection for quickly making several connections.
• Upgrade to waf 2.0.19

Ubuntu Studio 20.04 LTS Beta (Focal Fossa) Released

by Ubuntu Studio, at April 03, 2020 02:08:30 PM

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

sfizz v0.3.2 release

by SFZ Tools News, at April 03, 2020 12:00:00 AM

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

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

by rncbc.org, at March 28, 2020 02:00:00 PM

Development update: 6.0-pre1 now ready for testing

by Ardour Blog, at March 27, 2020 12:51:41 AM

@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 nightly.ardour.org. 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:

Testing

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 tracker.ardour.org 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.

Documentation

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.

Translation

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 https://raw.githubusercontent.com/Ardour/ardour/master/TRANSLATORS

Posts: 53

Participants: 23

Read full topic

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

by rncbc.org, at March 26, 2020 08:00:00 PM

Ubuntu Studio 20.04 Testing Week

by Ubuntu Studio, at March 26, 2020 12:00:30 PM

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

A QStuff* Spring'20 Release batch #1

by rncbc.org, at March 24, 2020 08:00:00 PM

New tutorial and opcode additions

by SFZ Format News, at March 17, 2020 12:00:00 AM

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.

sfizz v0.3.1 release

by SFZ Tools News, at March 14, 2020 12:00:00 AM

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

What is “Support”?

by Ubuntu Studio, at March 13, 2020 11:21:32 PM

In technology, you hear the term “support” thrown around a lot. There are multiple definitions of that word. Here, we will focus on two Development and Maintenance The first one is related to development and maintenance. This is where the Ubuntu Studio development team comes in. That scope is rather… Continue reading

Ubuntu Studio 20.04 LTS Wallpaper Contest Winners

by Ubuntu Studio, at March 07, 2020 07:50:55 PM

Out of 41 entries, the following 10 wallpapers were selected. Congratulations to the winners! These should be included on the daily Focal Fossa (future 20.04 LTS) daily ISO images shortly. Ubuntu Studio 20.04 LTS Community Wallpapers

Wallpaper Contest – VOTE HERE!

by Ubuntu Studio, at March 01, 2020 08:54:27 PM

We would like to extend a huge thank you to everyone who submitted a wallpaper for the Ubuntu Studio 20.04 LTS wallpaper contest. We had 41 submissions, out of which we have narrowed it down to 17 of the best. Out of these 17, the top 10 will be selected… Continue reading

sfizz v0.3.0 release

by SFZ Tools News, at February 29, 2020 12:00:00 AM

• Added filter and EQ handling (the filN_... and eqN_... opcodes). There are also no limits to the amount of filters and EQs you can slap on each region beyond your CPU. Most if not all of the relevant filter types from the SFZ v2 spec are supported.
• Added a new command-line option for the JACK client to set the client’s name (#75, #76).
• Added initial MIDNAM support (#79). The MIDNAM shows the named CCs in the SFZ file for now.
• Reworked the parsing code for faster dispatching and better handling of complex opcodes with multiple parameters in their opcode name (#40).
• Reworked the panning and stereo image process. The new process uses tabulated functions and avoid expensive calls to compute sine and cosine functions (#47, #56).
• Added a crude *noise generator. This generator is a bit expensive for what it does but it’s mostly useful to test the filters.
• Added fine timings within the callbacks for performance improvements and regression testing (#65).
• Corrected a bug with Ardour where saving a session with no file loaded would crash on reopening.
• Corrected a bug where voices triggered on key off would never end and fill up the polyphony (#63).
• Improved and completed CI on all platforms.

KXStudio Monthly Report (February 2020)

by KXStudio, at February 29, 2020 01:22:23 PM

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 github.com/WineASIO organization, so we can place the source code repository in there.
If that takes too long, the repository will just end up at github.com/falkTX/WineASIO 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! :)

SpectMorph 0.5.1 released

by Stefan Westerfeld's blog, at February 13, 2020 10:51:52 AM

A new version, SpectMorph 0.5.1 is available at www.spectmorph.org. 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):

• Instrument Editor (Tutorial Video)
• Blue Matrix (New Song made with SpectMorph)

Is Open Source a diversion from what users really want?

by Ardour Blog, at February 07, 2020 06:51:06 AM

@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: 71

Participants: 28

Read full topic

Ubuntu Studio 20.04 LTS Wallpaper Contest

by Ubuntu Studio, at February 01, 2020 08:45:58 PM

As we begin getting closer to the next release date of Ubuntu Studio 20.04 LTS, now is a great time to show what the best of the Ubuntu Studio Community has to offer! We know that many of our users are graphic artists and photographers and we would like to… Continue reading

New year, new work in progress

by SFZ Format News, at January 31, 2020 12:00:00 AM

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.

sfizz v0.2.0 release

by SFZ Tools News, at January 30, 2020 12:00:00 AM

• Added an LV2 plugin version.
• The parser now falls back to case-insensitive search if it doesn’t find the sample file in its current path (#28), so that the behavior of SFZ libraries on case-sensitive filesystems will match Windows and macOS default case-insensitive filesystems.
• The file now reload automatically on file change, and you can force a reload if necessary (#17).
• Corrected a bug where memory would be read past the end of the file in memory, generating artifacts.
• Corrected a bug where the real-time queue handling background loading of the voices would fail spuriously.
• Corrected a bug where in the LV2 plugin the unknown opcode list was truncated (#18).
• Added dynamic updates for the current modifiers (panning, stereo image, volume and amplitude mainly) (#19, #28)
• Added timing for callbacks and file loading times.
• Added support for pitch bends (#6) as well as pitch-bend activation for regions (lobend and hibend opcodes).
• The JACK client will warn you instead of crashing if you do not give it a file to load (#27).
• Added a windows build process for both the shared library and the LV2. sfizz now builds on all major platforms.

KXStudio Monthly Report (January 2020)

by KXStudio, at January 29, 2020 10:37:03 PM

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!

Ubuntu Studio 19.04 reaches End Of Life

by Ubuntu Studio, at January 23, 2020 12:00:03 AM

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

New Website!

by Ubuntu Studio, at January 21, 2020 06:48:06 PM

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

Carla 2.1 RC1 is here!

by KXStudio, at January 19, 2020 02:01:41 PM

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.

Downloads

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 https://kx.studio/Documentation:Manual:Carla.
(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!

Ubuntu Studio 19.04 (Disco Dingo) reaches End of Life on January 23, 2020

by Ubuntu Studio, at January 09, 2020 12:00:07 AM

Ubuntu Studio 19.04 was released on April 18, 2019. As a non-LTS release, 19.04 has a 9-month support cycle, and, as such, the support period is now nearing its end and Ubuntu Studio 19.04 will reach end of life on Thursday, January 23, 2020. The supported upgrade path from Ubuntu… Continue reading

[ News Archive ]