This article discusses audio production on Linux. The author identifies two problems: integration and usability. “I am convinced the the problems discussed here have readily available solutions, but I think opening some dialog with the providers of different parts of the stack needs to happen to allow the solution to develop.”
Audio has always been a sore spot in Linux
This article’s subject comes from Lugradio. See this lugradio forums thread “Moving to an Open Source editing program for LUGRadio”
http://forums.lugradio.org/viewtopic.php?t=1071
I ranted in that thread as “underscan”.
Brings up a lot of problems with Linux for audio. This is one of the main reasons I cannot switch to Linux completely, as it just doesn’t cut it…. yet.
This is another area that if the software and hardware manufacturers stepped up to the plate, it would be a lot different.
Imagine if Echo Audio bundled in a complete customized version of Fedora Core or Debian with their sound card on DVD, with all the available apps?
Imagine if Adobe, having already ported some stuff to Linux, ported Audition, one of the best editing and multitrack apps out there?
Tracktion is also another wonderful cross-platform sequencer (crossplatform meaning OSX/XP) that would be fantastic to have, and the original developer has already stated interest in porting it to Linux.
the trick is to make it all happen.
does anyone know midiox equivalent linux application or plugin ??
I used midiox for midi filter, velocity scaler (my keyboard only goes up to 100 velocity level). but I can’t find similar midi filter and/or velocity scaler on linux…
You might have a look at the Agnula distro,flavors:demudi (based on debian),remudi(based on Red Hat).A distro with a lot of music related applications.
some “usabilitity expert” has some suggestions for improving audacity, check out:
http://open-source.nanokron.info/?voir=projets/audacity/audacity-in…
JACK should be started at boot time and all apps should be ported to use it.
A GUI patchbay that supports LADSPA plugins for JACK needs to be built into GNOME/KDE.
.alsarc needs a GUI configurator built into GNOME/KDE.
ALSA MIDI routing needs a GUI configurator built into GNOME/KDE.
With those three things, audio would be as good on Linux as anywhere else, if not better.
Heh, you’re asking too much. I’ve noticed(and I know I’m not alone) that linux devs like to do the same work twice…… Instead of doing something else that is really needed.
Excellent ideas, I agree.
Hopefully this article will bet spread around the linux community and this barrier can be broken.(yes, naturally this guy is not 100% correct. He doesn’t have to be. His message is clear. COLLABORATION)
IMHO collaboration includes not re-inventing the wheel.
yea ok! load up linspire and see what a great implementation of JACK they managed to do… From what I have seen jack aint JACK!
i think i usually have less trouble with esd… or maybe it is artsd…heck dont even remember which I usually go with but my experience with jack has always been poor…
now once jack matures…. like alsa ALMOST has then I think we might see a decent sound system! but i doubt it! I think all the distros are jumping on what “all the distros are using” and that mean alsa and jack…
personally i always had better luck and IMO better sound from OSS than alsa…. especially on older hardware! but we had to recreate the wheel….
> .alsarc needs a GUI configurator built into GNOME/KDE.
GNOME and KDE are portable desktops used in the Unix world. ALSA isn’t portable and it isn’t used in the Unix world – only Linux. Therefore I think it’s a bad idea to integrade a GUI configuration into GNOME/KDE. It’s better to have an external tool.
Well, I think’d be better to have it integrated on every OS possible – e.g. if GNOME is built on Solaris the audio patchbay application built into GNOME controls the Solaris audio driver. This already happens with esd to some degree – the problem being that esd is completely inadequate re. latency and synchronisation and provides only minimal functionality.
Theres no reason why you wouldnt want support for your OSes sound subsystems built into the DE’s tools, and Linux is just an example here.
But in saying that its one of the few *NIXes with good support for sound and MIDI on modern hardware.
I mean, the situation you described with external apps is exactly what we have now and it sucks.
Its not better to have an external tool for this stuff – SGI , Apple, Microsoft all provide DE-level multimedia configuration tools and thats why they get used in multimedia systems instead of the inconsistent, non-integrated mess that we have to deal with elsewhere.
I tend to agree there are some open source applications in the Linux community that need improvement. Though it seems there are a few people that tend to not want an open source alternative but instead a commercial one. Particularly one that is ported to Linux that the user is more familiar with. While this has been available to other artists working in game design, visual effects, video editing, etc muscisians have at this time only open source applications to choose from which is unfortunate. Though I know a few muscisians that would tend to dissagree with the article’s author commenting on what he deems as a poor alternative for muscisians using Linux in the studio.
A few more links for muscisians considering Linux for their studio.
Ardour review:
http://www.linuxjournal.com/article/7796
Rosegarden tour:
http://www.rosegardenmusic.com/tour/
Linux Multimedia Studio:
http://lmms.sourceforge.net/
Correction: Meant “musicians” not “muscisians”..lol.
IMHO collaboration includes not re-inventing the wheel.
However, trying a few different approaches to inventing the wheel to see which one works out best can be pretty useful. I’m not familiar with the systems mentioned, but they probably all have their strengths and weaknesses.
In all likelyhood the newer projects learned from the older projects’ designs and decided that it’d be useful to do it a different way now. Else they’d just have taken the existing project.
Interesting to see there are always people ready to tell us “what those linux people should do”.
Of course, some analysis of how things can improve is useful, but it often feels like the author thinks he knows better than all those stupid developers who fail to see the big picture.
Those authors often don’t seem to realize that most open-source development is done in spare time as a hobby, which means that the developers are free to work on what they like to work on, instead of on what somebody else thinks is most useful.
(this article happens to be pretty nice by the way, but i couldn’t resist ranting about this for a bit in general
)
Whats wrong with feedback? Anyhow, I completely agree with the author. My experience with linux and recording has been a pain in the butt.
Whats wrong with feedback? Anyhow, I completely agree with the author. My experience with linux and recording has been a pain in the butt.
>
>
Who gives a damn about no-talnet flakes from the Amiga MOD community like you to begin with?
99.9999% of the stuff you idoits release is techno-garbage to begin with and most likely is of little interest to Linux developers who likely don’t either download or listen to the crap.
I find it interesting you title a comment as “arrogant” and in reply the following quote can be found.
———–Who gives a damn about no-talnet flakes from the Amiga MOD community like you to begin with? ————
It must be nice to anonymously post about a reviewer who you believe to be “arrogant” while at the same time flaming anyone who disagree with your position.
You’re louder so therefore you must be right?
I wouldn’t say the author is arrogant. He may be a little picky about what software he uses but then again aren’t we all
Anyway, I agree there are a lot of open source applications that need to mature. Otherwise these developers working out of their basement, garage, etc so to speak should join other similar projects that have progressed further. This would then speed up developement with the community working together on one project instead of several small ones. Jahshaka for example is intended to be a highend video editor/visual effects compositor similar to Discreet’s Smoke or IFX Pirhana HD. The project for a long time was going no where and so sponsors started to slip off. That was until recently when developers working on other similar ideas decided to join the project which has lead to a speed up in developement and renewed interest from sponsors. So basically feedback even negative feedback can be good for a project as long as it’s constructive to assisting the developers develope a worth while application. Also having more developers working together can have a better effect than working alone.
The integration issue is proportionate throughout the entire system. If I plug in a USB sound card, I want all of my applications to make use of it.
Doesn’t this already happen as long as the card is supported?
but if you have a complex card with 10 ins and 10 outs and multiple recording modes, you need an application to manage this.
I think exactly this is handled very good in jack. See to the right of this screenshot, there’s a full patchbay:
http://ardour.org/img/main-screenshot-big.png
You can certainly control levels with the ALSA mixer, but it will not allow you to deal with the many other options for the card.
This of course depends on how well the card is supported by alsa. The ones who are can make for a very nice recording system afaik.
As with setting up RT-kernel, jack and all, I recommend one of the pre-configured distros like planet ccrma.
Each of these modes of practise can be reasonably implemented in sensible defaults throughout the entire application. This not only applies to effects, but to other areas. Some ideas: [his ideas]
These ideas are pretty good.
As for “integration” I don’t know, to me it seems he hasn’t really used GNU/Linux THAT much for audio, cause there’s really just jack to worry about, and once you’ve got that in tune the rest is really as straightforward as any system. Jack is also analogue and simple once you discover what it is and can do.
He mentions Cubase, and that’s more of an application designed to emulate hardware than taking advantage of the computer as such. That might be why he’s doubtful, cause this is not the case for jack and it’s client apps. But that doesn’t mean it’s harder. Me I learned most of my audioknowledge via the computer, and in many cases I find Cubase, Nuendo and such harder to use than jack/etc because of this.
If I can’t use it, how is someone with no knowledge of audio recording supposed to use it?
Seriously, if you can’t use Ardour I doubt you can consider yourself competent of judging these tools. Ardour operates very much exactly as other similiar apps. I suspect he’s looking more for nice graphics then actually where buttons are located, streamline’ism etc.
It’s just that I’m using Nuendo nowadays because of an assignement, and many times problems arises where the solution would be pretty easy to solve with Ardour/jack because of it’s concept and design. Nuendo might be easier at first, but once you get to a realistic session it might come short and you have to make unclean solutions to solve them.
I agree with him on having more good presets/templates and having things more ready setup. There should also absolutely have been some kind of session-saving system for all jack-apps simultaneously, so that if you use fx seq24, hydrogen and specimen through jack, you could save all of them in one go.
Quote “This is where cards such as the M-Audio Delta range fly on Windows – they come with a little control application to manage these parameters. You can certainly control levels with the ALSA mixer, but it will not allow you to deal with the many other options for the card.”
Actually, there is a separate mixer app for Linux strictly for the M Audio cards, called envy24control. It controls all the features unique to it. If you use Mandrake/Mandriva, it’s just a simple download.
Quote: “I suspected Ardour with be a cinch to pick up – unfortunately I found it impossible to be productive straight away.”
All programs take some getting used to. I think that because you’ve used Cubase for a long time, you shouldn’t expect to know exactly how to use a completely different program straight away. I really don’t think anybody would learn Cubase or pick it up any faster than they would learn or pick up Ardour. Myself personally, it took me about the same time to learn the basics of both Magix Music Studio and Ardour. (and I picked up Audacity even a little quicker than either of them)
Overall a pretty good article. I especially agree with the need for some presets. I’d do it myself if I knew more about audio recording.