Louigi Verona's Workshop

‹‹‹back

Linux Audio: In what way modular approach is limiting

An analysis of what modular approach can and cannot do.


24 February, 02010

Being relatively new to Linux Audio, but not new to music, I perhaps might sound like one of those critics who start to speak about things they do not quite know about.
However, I still would like to take the liberty to discuss the limitations of modular approach, believing that my input can be useful simply because in these several months I've spent most of my free time working with GNU/Linux audio, learning, studying, trying out, keen on making GNU/Linux my musical station. So perhaps my dedication makes these 3-4 months a pretty vast experience.

First of all, I would like to underline the fact that I do believe that modular approach is something that makes GNU/Linux stand out. If one requires a special, complex setup, modular approach is the way to go - installations, live performances, non-standard signal processing. All of that is usually not possible with Integral Music Environments (later as IME, meaning a standalone, all-in-one DAW).

However, I do not agree with people, who say that GNU/Linux should stick with modular approach and stream all energy in that direction.

Indeed, this opinion is very much dominating and the only IME - LMMS - in the world of Linux Audio is not getting much support from the core community.

Let's then see what kind of music is easy to do in Linux today.

Well, generally speaking, the best type of music that fits Linux is actually recording bands. Putting it shortly and yet descriptive: recording acoustic music and then post editing those recordings.

This is what Ardour is best at, this is what the whole workflow of many Linux applications is aimed at.
The vast majority of midi DAWs, such as Muse, Rosegarden, QTractor, are aimed at producing electronic versions of acoustic music or additional arrangements around already recorded pieces - that is, use various external synthesizers to input notes. All the options, the way the workflow is shaped, is aimed at producing melodic music, similar to orchestral aimed Cakewalk in the early nineties.

Of course, before anyone says that the above tools can do much more than that, I should agree that they can. But the amount of workarounds, setup and/or limitations in order to produce other types of music other than mentioned above is at most times increasingly larger than incentive to produce it using Linux.

And thus we come to limitations of the modular approach.

1. Not suited for certain types of music.

My belief, as an electronic musician, that modular approach is not an optimal approach for complex electronic music. By complex electronic music I mean music with highly detailed arrangements, which requires the musician to go back to any place in the arrangement and change something, anything - be it a note, it's placing, a parameter, its automation, sound source.
Please, do not be fooled by the word "complex". A tune can become technically complex very fast without being a masterpiece of detail. Most house tunes can be relatively complex with various automations, break downs and build ups.

That for this kind of music modular approach is probably the worst approach is clear to anyone who has ever attempted it.
The reason why this is rarely brought up is because by my observations most musicians who hang around Linux Audio communities are rock bands, jazz bands and people who produce songs and music that requires no technically complex arrangements (which by no means indicates that the music itself is uninteresting). Recording your voice and then layering some basic drums with Hydrogen and then adding some orchestral elements like strings, a flute phrase and possibly an organ is not difficult to achieve in Linux. In fact, being able to stick the required synth into Ardour or QTractor and record what you need makes everything charmingly inspiring. This is where modular approach only helps the workflow.

Not so for complex electronic music. It requires much more than being able to input notes. And the possibility of having a session handler is not a solution. While some may say that having dozen of programms open is just a matter of getting used to or even taste, in reality it is plain inconvenient - in fact, something as simple as producing a decent house tune with modular approach is quite difficult, to say the least. Not only you need to sync everything, the amount of work required to build up the arrangement, to introduce sudden break downs and parameter automations makes it quite, I would say, uninspiring.
Thing is, nothing can beat a list of channels with appropriate samples and synths on every channel and a master sync above it all for this kind of music. And while JACK does have the JACK transport, my experience shows that it does not really work as a master sync the way it works in an IME, not to mention that not all Linux audio software supports it.

In other words, using modular approach for doing complex electronic music is same as using a toothbrush to clean the floor - it can be done, but the only good reason to use that method is if you really have too much time on your hands.

All of the above can actually be demonstrated - and with free software.

Let's look at a tune I made using LMMS. Follow this link and scroll down to video "The Tribe".

This is not the most detailed arrangement I've done and is certainly not the most detailed arrangement typical for that kind of electronic music. However, I am claiming it is complex enough to be very difficult to set up and create using modular approach (although possible).
Let me break it down for you.

The tune uses 27 instruments, out of which there are:
3 Mallets synths
3 sf2 players
3 Zyn synths
17 audio plugins (wave samples, 7 of those are used as melodic instruments in a piano roll, 10 just sounds like drums and effects which require no piano roll but a drum machine kind of editor)

The tune has 40 separate midi tracks.

For an IME this is standard stuff. For modular approach setting all of this up for work is a serious task. And I've been working on the tune for several days in a row. Many times I had to go back to the beginning and change things - be it notes or parameters or automation. If that was done with modular approach, putting all that together would be a non-trivial task.
How would I go about it? Have audio samples in Ardour? But I need them in a piano roll so that I can easily play several notes in different pitches. Ardour does not have a piano roll. QTractor has a piano roll but it does not support having audio files as a midi source. In fact, I do not know of any program in Linux but LMMS that has that kind of functionality. Yet, it is nothing fancy. You have a sound effect and you want to play it in a different pitch. Of course, you can multiply the clip in Ardour and in copies of the clip change the pitch, that being a reference to the toothbrush example.
Okay, let's picture that eventually I am using Ardour. Where would I have midi? Ardour does not support midi, so I would have to use, say, QTractor, to write midi. I did not try syncing these two DAWs via JACK transport, but if, say, it is possible, I would have to manage all the clips in two separate programms and align them almost by ear, constantly switching between two different windows, because some things I just need to have in precise positions. If, at some point I would need to remove or add some midi/audio clips into the middle of the composition, I will have to move all the clips in both programms.
Next, I am using some volume and panning automation. QTractor has no automation, so eventually, once the basic structure is done, I would have to export midi clips from Qtractor to audio clips and put them into Ardour and there automate the volume and panning. If suddenly I realize I have to change smth (which happens often during production) I would have to go back to QTractor, change the midi clips, re-render the clips and then re-export them to Ardour. I am not sure if I would be able to copy the automation easily - if no, then I would have to redo it again.
I can, of course, go a simpler way and just route QTractor to buses in Ardour and do the automation instantly from there - this would work if JACK transport works well for Ardour and QTractor.
I also use various controllers to automate synth parameters, effects and the amount of wet gain on a track. How it is possible to do in modular approach I do not even know. Effect automation is, of course, possible through mixer in Ardour. How to automate other things I am not sure. Maybe it is my lack of knowledge in this area, maybe it is not possible.

All in all, the above description shows that it is possible to make such a tune without IME, but it is much more difficult, since you will have to switch between two separate DAWs and also constantly care about what is routed to where. Keep in mind, LMMS 0.4.6, being stable and sweet to work with in as it is, is far from offering all the flexible functionality that most modern proprietary DAWs do. Once it has routing capabilities and a whole other list of improvements, which are a logical continuation if what is there now, imitating its workflow with a modular environment will shift from "difficult" to "impossible".

I am not even mentioning that the amount of frustration to set things up even for an experienced musician is enough to kill any amount of inspiration. I remember I was doing a tune in QTractor. This tune used two Bristol synths and an organ. Simple enough, right? But setting it up each time was so long that many times I chose to not go through the process.

The whole convenience issue is, actually, extremely important. I have often observed that complaints of IME type of musicians about modular approach being too difficult to set up are either ignored or treated as a sign of weakness and/or lack of desire to do music the "linux way". But I personally see no point in such persistence. After all, IME approach is an approach which can greatly improve what can be done on GNU/Linux and - as many might admit - help to make music making on Linux a solid good experience, instead of shifting it closer to things like programming or chemistry, with all the low level code and several line formulas. After all, convenient does not mean bad.

2. Not guaranteeing standardization.
Thing is, even if we imagine we have a solid working session handler (which we do not), some app you are using might not yet support it or even never support it.
So even if there is a session handler, nobody can guarantee all the apps will have it. Moreover, the way programming works, especially in the free world, you rarely get an end product instantly. You first get alpha and beta versions and those go around for ages.
Relying on modular environment means relying on the developer of each app. It means that in order to make the system work perfectly, we need many-many developers to comply with the standard. In an IME there is no such thing. If the synth is ported into an IME, like Zyn into LMMS, everything is saved. You do not even have to save a preset, all your changes are simply saved within a project because in that case it is easier to implement a project setup.
So, the nature of the modular approach is such that it will never be perfect. It will always lack something - some useful app or a plugin which will happen to not support something - be it a session handler or a parameter control protocol or whatever needs support.

Conclusion.

Okay, so what exactly did I want to say with that?

1. I believe that GNU/Linux audio community has to be less rigid in the question of modular vs. IME approach and instead stop thinking in terms of "vs" at all. While modular approach is unique to Linux and certainly is perfect for certain tasks, no audio platform will be complete without a decent integrated music environment. This is not a question of being used to something or of luxurious convenience - it is a matter of being able or not being able to create certain types of music. In other words - IME is important. Yes, even for such a unique operating system as GNU/Linux.

2. I am going even more detailed and claim, with a concrete audio example, that there are whole classes of music which are close to impossible to do with modular approach.

3. Finally, I show that due to the fact that modular environment is... well, modular, it by its nature relies on many different developers to work. That makes it vulnerable to a good app not supporting something or an app not being stable enough and thus falling out of the system. Thus, building a stable audio system becomes much more challenging since it relies on too many independent components.

4. In theory, modular does offer more functionality than IME, but the majority of musicians really would prefer a stable system to produce more regular types of music than difficult rocket-science-type setups to get some additional effects not achievable in standalone, IME type DAWs.
Atm, due to historical reasons, I presume, and to the fact that modular approach is still being considered the only thing worth doing on Linux, making normal, usual electronic music is difficult.