Slashdot Mirror
Music Sequencing Software for Unix?
caluml asks: "I am looking at getting more into music making, and buying some decent-ish synthesizers. Most sequencing software out there is for Mac or Windows, neither of which I have. I have looked at Audigy and Audacity, but wonder if there are any others that others find worthwile. Can anyone give me their recommendations for sequencers, audio editors, and multi-track recording software?"
Ardour is a pretty good multitrack recording program, with a rich feature set. For sequencing, I'd recommend Rosegarden.
"Better to be vulgar than non-existent" -Bev Henson
LMMS. Aims to be an alternative to FL. Documentation is in the form of skimp wiki. But if you know how to use FL I heard it's not too hard to get a hang of lMMS.
Have you ever worked in a professional audio environment or even seen a studio? I have. You probably haven't. I've recorded over 10 tracks simultaneously in "Windoze" as you put it, with 1 millisecond audio latency. Absolutely no problem. I've also done the same on OSX, but that's besides the point.
There is NOTHING for Linux or BSD or whatever you want to use that comes close to the quality of the four programs I mentioned. Period. Go use a few of them, then come back to me and tell me to use [insert Linux DAW here]. You won't get any proper AU or VST support in Linux, which pretty much couns you out for using any mastering software. As for hardware support? Good luck getting any of the professional audio devices (Read: Echo, Mackie, MOTU, Digidesign) to work to their full capacity. You'll be lucky if you get 200 millisecond audio latency.
You seem to get off on simply insulting people instead of posting anything relevant. Do me a favor, go to a real studio, then come back after you've had some practical experience. Thanks.
As a side note, pretty much anyone who spells Windows "Windoze" or Microsoft "Micro$oft" or whatever the hell else have you loses all credibility right away. Look, ha ha, he tried to make a funny. Isn't that so clever?
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
A good starting place is to nose around the sites hosted at http://portal.linuxaudio.org/
The linux audio users and linux audio developers lists are vibrant (perhaps overwhelming) and their archives and associated documents and HOWTOs contain more information than you could possibly want.
Personally, I've had very good experiences with:
ecasound (multitrack recording, processing, general all-around fiddling)
ardour (recording and mixing)
rosegarder (midi sequencing and scoring)
JACK (patchbay and tool interfacing)
Everything Linux audio/music is listed here:
http://linux-sound.org/one-page.html
There are a lot of other great manufacturers, I was just naming a few of them. However, I must say RME isn't a brand that I've ever heard of until now, but looking at the specs and such they look like good hardware.
This still doesn't really affect the main argument though, which is that in the current state of things there isn't any software out for Linux that can do a great job competing with the main players. Hopefully some day there will be, but it'll take some time... Either that or one of them will get a Linux port made. The thing is, working in the music industry, if you aren't using Pro Tools, you really might as well not be in the music industry. It's sad but it's true.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
Yeah, unfortunately, the parent has a point. Having used Audacity, Ardor, and a few others, they are hobby toys. They are GOOD hobby toys, but they are hobby toys. A pro studio would not risk a client's project on any of the current open source options. They just aren't rock solid.
I have recorded major parts of a commercially released CD on a Digital Performer/Tascam 1884 system. That was a few years ago, and about as low-end as I was willing for a commercial project. That system was maxing out at 32 audio+8 MIDI tracks (with effects). I much prefer Digital Performer or Pro Tools on Digidesign TDM cards in some decent Mac.
If the recording/sequencing software like Ardor had some major support behind it, and the hardware companies released linux drivers, then I might give them a serious try in a pro environment. Until then, I might play with OSS at home, but at work, I will be sitting in front of a Control24 desk enjoying Pro Tools. I don't have a choice, if I want to keep clients.
Sig (appended to the end of comments you post, 120 chars)
They say that a little knowledge can be dangerous. You either suffer from this, or you're a genius with an insight that many systems other than JACK should benefit from.
Your comment about what is effectively variable size buffers is either a superb insight, or you just totally missing the point. Every M msecs, the audio interface expects to get N audio frames delivered to it, and makes available the same number of incoming audio frames. There is no way around this limitation. So the question becomes: is there way to process the N frames to meet the deadline that is more reliable than what JACK currently does?
If there is, it seems remarkable that no other system has implemented it. The overhead of calling the graph associated with the data flow for the frames is not insignificant, even on contemporary processors. Therefore, calling the graph the minimum number of times is of some significance, significance that only grows as the latency is reduced. Because of this, all existing designs, including ASIO and CoreAudio (with the proviso that CoreAudio is *not* driven by the interrupt from the audio interface) call the graph only once for every hardware buffer segment/period/whatever.
You are correctly identifying the major issue with JACK being occasional code paths in the kernel that prevent the graph from executing in time to meet the deadlines. However, I cannot see how adding overhead to processing N frames by executing the graph several times instead of once can possibly help. What we have been doing instead is encouraging and supporting the work of people like Ingo Molnar that get the kernel (and/or a patched kernel) closer and closer to actually being able to offer soft realtime that is close enough to what we need. On most hardware, Ingo's kernels now work phenomenally well, and only errant device drivers are capable of preventing the amazing good guarantee of service the kernel offers SCHED_FIFO tasks.
Paul Davis, Principal architect and author of JACK
You apparently don't understand that realtime audio software has to be ... well, realtime. The simplest definition of what that means for audio processing is:
T(nframes) = A(nframes) + B
that is: the time it takes to process nframes of audio is a linear function of nframes plus a constant.
As a result "applying more CPU muscle" is irrelevant because the time per nframes is essentially fixed. If you missed the deadline the first time (but had "breathing room") there are only two reasons why: either you code is badly written and doesn't meet the condition stated above, or the kernel interrupt you, took processor time away from you, and you were unable to get the job done.
Trying to fix the second situation by dividing the processing of nframes into even smaller chunks just increases processor overhead, and doesn't stand much chance of improving the situation.