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!
Not sure if it fits the bill, but when I was looking for something to play around with, I ended up using this.
May I suggest you visit http://kvraudio.com/ ? :)
Pro Tools is only compatible with Pro Tools hardware, they have a lite version for M-Audio hardware (because they bought them). Not all manufacturers are hostile and some of those who are get to see their hardware running fine on *nix anyway. Most PCI-based soundcards run fine, there isn't a hell of a lot PCIe cards to worry about yet, USB (yuck) works if it's class compliant. Check the freebob project for Linux firewire compability, class compliance applies. ADAT is a digital connection used to connect to outside gear, the other end is PCI or firewire (I have yet to see an USB card with ADAT, not that I'm trying), you might as well say that linux can't use XLR-cables... Pleeeeeease get your facts straight before you hit submit.
PlanetCCRMA http://ccrma.stanford.edu/planetccrma/software/ is a collection of RPMs intended for audio workstation use that can be added to a Fedora Core 5 install (or 1-4, or RedHat9.) It includes a low-latency kernel, and apps for audio work.
Your hardware matters. RME's Hammerfall soundcards are very high quality, and designed with Linux compatibility in mind (kudos.)
For multi-track recording and work requiring low-latency, I believe you're stuck with Linux; AFAIK the BSDs will not provide real-time kernel access for non-root users.
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
http://jokosher.org/
Jokosher is described as "Audio production made simple".
Based on gstreamer and an attempt to make something that is much easier than Ardour to get in to (not as complex, and never will be). A music editing and mixing software targeted for garage bands and hobby podcasters and the like. 0.2 are more or less 1.0, which will be released any week now (when the gstreamer multi input soundcard bugs are taken care of). Will support Jack and such...
I've learned all I know about politics from
A nice distro is http://64studio.com/ for 64 bit cpus but also available for 32 bit. I get at least as low as 2ms latency which I never got either on Windows nor OS 9/ OSX, maybe less is possible but I didnt dare so far.
Further sequencing: Muse
http://www.muse-sequencer.org/
wired looks promising but seems a bit hard to get it running
http://wired.epitech.net/
Linux can do professional grade audio and is often used by academic musicians. The Jack audiosystem adds an flexibility which is missing on other platforms (except its now available for OSX and soon Windows).
For mastering Jamin do incredible things:
http://jamin.sourceforge.net/en/about.html
Cheers, Malte
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)
Isn't this exactly what the --nperiods option for JACK's ALSA driver is for?
From the manual:
-n, --nperiods int
Specify the number of periods of playback latency. In seconds,
this corresponds to --nperiods times --period divided by --rate.
The default is 2, the minimum allowable. For most devices,
there is no need for any other value with the --realtime option.
Without realtime privileges or with boards providing unreliable
interrupts (like ymfpci), a larger value may yield fewer xruns.
This can also help if the system is not tuned for reliable real
time scheduling.
Isn't this exactly what the --nperiods option for JACK's ALSA driver is for?
Nope. Or if that's what it's intended for, then it's not what it actually does, so maybe we're merely looking at a coding bug --- I hope so. But if so, then the bug's been there forever.
The problem is easy to see. For example, with --nperiods == 4 (say), an XRUN occurs if the quarter-latency buffer isn't processed in 1/4 of the latency time, instead of allowing the instantaneous failure to slack over into the other 3/4 of the available time. In other words, if the instantaneous timing requirement isn't met, then the current implementation of --nperiods doesn't allow the CPU to catch up during the remainder of the overall latency period, even if the glitch was much shorter than the latency period and there is tons of CPU available. A hot-rod machine simply isn't given a chance to recover, regardless of the setting of --nperiods.
The --nperiods setting should be allowing us a tradoff between instantaneous responsiveness and system load average, because for a fixed value of latency we should be able to use smaller buffers (and so have more processing overheads) but have more time to recover from timing failures by applying CPU muscle "after the event". Well it ain't, sadly.
And I don't think that there's any interest in fixing the problem, because so many Linux audio developers have very efficient pro' interfaces and so the occurrence of timing faults isn't high enough to matter for them. YET, that is! -- it will matter as sample rates rise. Well, sure, a pro' user would almost always buy a pro' interface, but that's no reason for ignoring a problem in the implementation (or design) that affects everyone else. This issue still bites users with pro' interfaces, but it just does it a lot less often.
There's too much "we're already perfect" attitude around in Jack circles, and it's not helping. The fact is, we glitch audibly in circumstances when one other O/S that we regard as crappy (and rightly so) doesn't, on the same computer and using the same interfaces and with RT properly set up. We're not perfect. Swallow your pride, listen for glitches using a less efficient interface, and fix it if it's a bug. Or redesign the damn thing if it's a more fundamental problem.
You sir, are either ignorant fool, a troll general, or a total idiot. As other reply clearly suggests, JACK offers -nperiods or simply -n flag which allows exactly what you are looking for. Currently, JACK technologically speaking is ahead of anything else out there in terms of sample-accurate sync, audio I/O resource sharing, and low latency.
"delay model is buffersize-based"
In audio, is there any other model *if* you wish to maintain sample-accurate sync which is criticial for pro-audio work?
"and so it requires *HARD* realtime to work"
No it doesn't. You can run JACK with or without -rt flag.
"which simply isn't what the standard realtime module in 2.6 and special patches give you"
History teaches us that there is no such thing as the ultimate solution that meets all needs and is fit for all purposes. There is no such vehicle which can be a sports car, a family van, an all-terrain vehicle, a bus, a truck, limo, and a bulldozer. Each car has its purpose and thus its disadvantages. The same is with kernels. This becomes especially the case when you go into extreme scenarios, i.e. ~2ms latency in the audio world. For instance, OSX is a well-rounded OS which offers (apart from other benefits) a relatively good audio latency. However, attemtps at getting extremely low audio latency is pretty much a lesson in futility.
"You *can* still get Jack to work perfectly with 2ms latency (and hundreds of people do), but only with extreme care about what applications you're running and with the use of fast top-end audio hardware,"
Another troll. JACK can run real-time on a crummy laptop soundcard as well as pro-audio hardware with the same results. If a card is especially crummy sometimes extremely low buffer size will not work due to hardware limitations. Also unreasonably large buffers will usually not work on many soundcards, but trying to do so would be stupid anyhow. If you want big buffers and no sample-accurate sync, why not use the enchant ESD instead?
"to provide vastly more timing slack"
Why would you want that? Are you interested in having your apps' audio output drift from each other? How about Propellerhead's Rewire? Does it allow this? Again, if you are looking for a crappy solution, use a crappy solution. Don't bitch how something not geared towards your needs does not meet your needs.
I will give you a credit for saying that achieving XRUN-free and low latency situation is not easy. However, this is not due to flawed design in JACK but rather a flaw in how other concurrently running software is abusing kernel spinlocks, especially proprietary drivers (i.e. ATI and NVIDIA) which we have no ability to alter other than not use them (something that in most situations means disabling of 3D acceleration). But again, this is not because JACK is flawed, rather because the offending software makers are doing things they shouldn't.
http://en.wikipedia.org/wiki/Free_audio_softwares oftware
s oftware
http://en.wikipedia.org/wiki/List_of_Linux_audio_
http://en.wikipedia.org/wiki/Category:Free_audio_
http://en.wikipedia.org/wiki/Hydrogen_(software)
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
"It's sad that for years now, the Linux kernel devs seem to have done their utmost to ignore Ingo. Well, that's life I guess, but until they do, your good experiences have almost no relevance to the far poorer performance seen by mainstream users of Jack who have to rely on realtime-lsm."
Most of Ingo's realtime/preempt work is already merged into the mainstream kernel. Full merge by 2.6.21 or thereabouts.
Also, most jack users are using a realtime kernel, so it is a relevant point.
"It's sad that for years now, the Linux kernel devs seem to have done their utmost to ignore Ingo. Well, that's life I guess, but until they do, your good experiences have almost no relevance to the far poorer performance seen by mainstream users of Jack who have to rely on realtime-lsm."
The realtime-lsm module is deprecated since 2.6.18 (at least). No patching or extra modules are needed to allow RT scheduling for normal users in recent kernels (which is what realtime-lsm did), meaning that anyone can get reasonably glitch-free realtime audio out of the box. What is left to do in order to get really low latencies is to shorten the long code paths in the kernel, which is what the RT-patch does, and as another poster wrote that is in the process of being merged into the mainline kernel. Good times ahead!
"configured for realtime-lsm operation, lacking only Ingo's patches that aren't available in the standard kernel"
(1) realtime-lsm doesn't do anything performance related at all. It is an old solution to a permissions problem, namely allowing non-root users to run threads in the SCHED_FIFO scheduling class and allowing them to use mlock() to pin memory in physical RAM. how well a SCHED_FIFO thread performs is 100% orthogonal to the existence of realtime-lsm. it is also now a deprecated solution for 2.6 kernels, which support a LKML approved mechanism for granting these permissions that has finally made it up into user space for most distributions.
(2) nobody has ever claimed that a non-patched kernel can be used to get xrun-free behaviour. what is true is that recent 2.6 kernels have becomes good enough (mostly through including parts of Ingo's work) that with larger latencies most users will get acceptable behaviour whereas they used to get terrible behaviour. If you want to either go lower or get guaranteed behaviour or both, you *must* have Ingo's patches installed. We are not going to redesign JACK for a kernel that is acknowledged by its authors to be incorrectly implemented for JACK's purpose. Ingo's patches solve 99% of the mis-design and thus represent a kernel suitable for low latency, critical audio work. the standard kernel is not likely to ever do this, although we can always dream.