playing the last slot.
make uninstall(#118, #120)
oscillatoropcode, to create generators from files (#128)
Wiki (help wanted!):
Enjoy && Stay safe!
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:
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).
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.
Many users may not be aware that thanks to the hard work of a user known as cooltehno, Ardour has 6 different themes. During the development of 6.0, there were significant simplifications and changes to the internals of themes, and the 5 themes that cooltehno generated all need updating and revisiting. If you’re interested in doing this, for one or all 5, please get in touch.
As anyone who has seen the various “Development Update” posts along the way for 6.0 is aware, there are a lot of new and changed features in this version of Ardour. We need people to update and/or write new sections in the manual to reflect all these changes. Please get in touch if you’d like to be a part of this effort.
Ardour has been translated into 15 languages:
French, German, Spanish (unified Castillian and Latin American), Portugese (Brasilian & Portugese), Russian, Swedish, Czech, Norwegian, Italian, Japanese, Chinese, English (UK), Polish, Greek
All of these translations will need significant updates for version 6.0. Although we are not yet in a string freeze, we hope there won’t be too many string changes before 6.0, so now is an ideal time for existing or new translators to get started. If you’re interested in becoming a translator, please read our guide at https://raw.githubusercontent.com/Ardour/ardour/master/TRANSLATORS
Greetings once more,
The Vee One Suite of old-school software instruments, synthv1, as a polyphonic subtractive synthesizer, samplv1, a polyphonic sampler synthesizer, drumkv1 as yet another drum-kit sampler and padthv1 as a polyphonic additive synthesizer, are all being released now for the second QStuff* Spring'20 batch of the (quarantine) season.
All still available in dual form deliveries:
Not much of a ravishing change-log, just on the brink of utterly boring maintenance stuff:
synthv1 0.9.13 (spring'20) released!
synthv1 is an old-school all-digital 4-oscillator subtractive polyphonic synthesizer with stereo fx.
samplv1 0.9.13 (spring'20) released!
samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.
drumkv1 0.9.13 (spring'20) released!
drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx.
padthv1 0.9.13 (spring'20) released!
padthv1 is an old-school polyphonic additive synthesizer with stereo fx
Enjoy && Stay safe!
No doubt some purists in the audience will call this one cheating, since this Amiga 500 from 1987 isn’t technically connecting to Spotify and playing the music by itself. But we also suspect those folks might be missing the point of a site called Hackaday. With all the hoops [Daniel Arvidsson] hopped through to make this happen, what else could it be if not a hack?
This one starts, like so many projects these days, with the Raspberry Pi. Don’t worry Amiga aficionados, this classic machine hasn’t been gutted and had its internals replaced with a diminutive Linux board. But thanks to an expansion card known as the A314, you could say it’s received a penguin infusion. This clever board allows an internally mounted Raspberry Pi to communicate with the Amiga 500 through shared memory, making all sorts of trickery possible.
In this case, the Raspberry Pi is actually the one connecting to the Spotify Connect service with
raspotify and decoding the stream. But thanks to a few pipes and an ALSA plugin, the audio itself is actually pushed into the Amiga’s sound hardware. In the video after the break, the process is demonstrated with tunes that are befitting a computer of this vintage.
This process is similar to how one classic Apple fan got Spotify running on their Macintosh SE/30 with a similar respect for the vintage hardware. Of course if you actually want to gut your Amiga 500 and replace it with a Raspberry Pi, we’ve seen some pretty good conversions to get you started.
[Thanks to burningbroccoli for the tip.]
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.
The Logitech SqueezeBox was a device you hooked up to your stereo so you could stream music from a Network Attached Storage (NAS) box or your desktop computer over the network. That might not sound very exciting now, but when [Aaron Ciuffo] bought it back in 2006, it was a pretty big deal. The little gadget has been chugging all these years, but the cracks are starting to form. Before it finally heads to that great electronics recycling center in the sky, he’s decided to start work on its replacement.
Thanks to the Raspberry Pi, building a little device to stream digital audio from a NAS is easy these days. But a Pi hooked up to a USB speaker isn’t necessarily a great fit for the living room. [Aaron] didn’t necessarily want his replacement player to actually look like the SqueezeBox, but he wanted it to be presentable. While most of us probably would have tried to make something that looked like a traditional piece of audio gear, he took his design is a somewhat more homey direction.
The Raspberry Pi 4 and HiFiBerry DAC+ Pro live inside of a wooden laser cut case that [Aaron] designed with OpenSCAD. We generally associate this tool with 3D printing, but here he’s exporting each individual panel as an SVG file so they can be cut out. We especially like that he took the time to add all of the internal components to the render so he could be sure everything fit before bringing the design into the corporeal world.
While the case was definitely a step in the right direction, [Aaron] wasn’t done yet. He added a WaveShare e-Paper 5.83″ display and mounted it in a picture frame. Software he’s written for the Raspberry Pi shows the album information and cover art on the display while the music is playing, and the current time and weather forecast when it’s idle. He’s written the software to plug into Logitech’s media player back-end to retain compatibility with the not-quite-dead-yet SqueezeBox, but we imagine the code could be adapted to whatever digital media scheme you’re using.
Over the years, we’ve seen a number of SqueezeBox replacements. Many of which have been powered by the Raspberry Pi, but even the ESP8266 and ESP32 have gotten in on the action recently.
Hello everyone, it is time for another monthly report in regards to the KXStudio project.
First, there were many bugfixes made to Carla, we are very close to RC2.
I only have 2 things that I want to do before the RC2, first being fixing multi-instance under multi-client mode and second is to finalize the last couple of bugfixes.
So the RC2 should be out in a few days, maximum weeks.
Second, something that came out of (re-)packaging WineASIO
(and moving away from Cadence, but that is a story for another day...).
I am taking over as maintainer of the WineASIO project.
WineASIO is something that is mostly "done", there is not much that we can add to it.
Since I have to keep it building in order to package it, I spoke with upstream and let them know I was available to take over.
(maintaince work is pretty minimal, just got to make it build basically)
We are trying to take over
organization, so we can place the source code repository in there.
If that takes too long, the repository will just end up at 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:
That is all for now. Have a great weekend everyone! :)
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):
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:
- giving users the freedom they deserved
- 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 ofAre 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:
- are users truly being given freedom by confronting them with a technological infrastructure that almost none of them can comprehend?
- 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:
- the scripting interface for a DAW can vary in terms of what it makes possible to accomplish.
- this is particularly true in terms of integration into the "main body" of DAW's own GUI.
- 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.
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.
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?
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.
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:
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!
V1.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: https://sourceforge.net/projects/yoshimi Or: https://github.com/Yoshimi/yoshimi Full build instructions are in 'INSTALL'. Our list archive is at: https://www.freelists.org/archive/yoshimi To post, email to: yoshimi at freelists.org -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song.
Hi all, I've updated Ninjas2 audio sample slicer plugin. Source and binaries (linux/windows/mac) are available at : https://github.com/rghvdberg/ninjas2/releases/tag/v0.2.0 readme : https://github.com/rghvdberg/ninjas2/blob/master/README.md >From the readme: #Goal: 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"