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
There's nothing that's truly professional quality, which is sad, but that's the state of things. Cubase, Logic, Sonar, and Pro Tools are the four standards.
However, there IS one fairly good program for UNIX type systems, though it's nowhere near the quality of the four I mentioned above. Have a look at Rosegarden.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
If you don't mind getting your feet wet with some programming, ChucK is a Java-like audio programming language that can interact with MIDI devices, and is a nice alternative to Csound and Pd for people who want to do sequencing programmatically.
-- listen to interesting music, support independent radio... WPRB
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.
Real men use cat and a directory with one file for each possible note.
When information is power, privacy is freedom.
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)
Gah.
Why do I get a sudden urge to download it and write some death metal with satanic themes after seeing that page?
Advanced users are users too!
My understanding, based partly on what others have said here and partly on my experience with Linux, is that there just aren't that many people using Linux for professional audio, so there's no works-perfectly-out-of-the-box solution. However, a good amount of the groundwork has been laid (ALSA, JACK, Rosegarden, etc.), so if you are a programmer (or know one who would be interested in playing with some fancy hardware) and you're not under major time constraints, you could probably get a very nice workflow going on Linux.
You will be one of the pioneers in this area, though, so if you need to get something done NOW, you'll probably disappointed. On the other hand, if you're looking to set something up that you'll be using for a few years, and you have the knowledge and patience to play around with it to get exactly what you want, then it might be worth looking into.
http://outcampaign.org/
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
If you're willing to take the time to learn how to use it, a tracker can be amazingly flexible, and you can do quite a lot with one.
:) -- Schism Tracker.
For Linux, there's (among plenty others, these are just the most prominent ones) MilkyTracker, ChibiTracker (which is the successor to Cheese Tracker), and -- don't mind if I spam my own program
Bears don't normally eat things that talk and move backwards.
Jack is as good as audio gets in Linux and BSD, but unfortunately it's quite severely broken by its design model.
... but it's far too late to do that now, as the current buffer model is engrained in a million Jack clients.
The problem is simply that its delay model is buffersize-based, which means that you can't assign a fixed latency without using a buffer size of a corresponding length. But this in turn means that during this amount of time, the system has to process the *entire* buffer for each Jack client in the stream, which means that even the tiniest system delay causes big trouble. If the design were intended for professional use, it would process only quite small blocks (corresponding to a fraction of the requested latency), but would maintain a constant specified in-out latency simply as a means of defence against small system delays.
Jack has no such defence against small system delays, and so it requires *HARD* realtime to work, which simply isn't what the standard realtime module in 2.6 and special patches give you. When it works, it's working on a prayer. To fix this, the buffer size and the configured in-out sample latency need to be decoupled to provide vastly more timing slack
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, no Internet access, and no random commands invoked from xterms. In contrast, the thousands of other people running Jack with realtime-lsm on their general-purpose Linux box still get the occasional XRUN at the best of times despite running with a load average of 0.01, and for professional work, even 1 XRUN per week is 1 XRUN too many.
That musician may have been flown in for 2 hours from the other side of the globe at huge cost. A brief audio glitch is simply not an option.
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.
This is all wrong. It takes A(nframes) + B cycles to process nframes of audio. This is an invariant, unrelated to period size or count (although period size may affect B). The only things that can really change A(nframes) + B are:
If you were slow on one of the blocks, perhaps you could make up for it in a later block by applying CPU muscle. But this just a band-aid over the problem. You should never have been slow in the first place.
Its not the job of application design to come up with band-aids around OS deficiencies, most of the time. The basic model of what is happening with audio i/o has already been made perfectly clear in this thread: every M msecs, you have to process N frames of audio. If the kernel is butting in and making that hard to do reliably, then its the kernel that need fixing. Your proposal that JACK subdivides the period so that if the kernel messed with us on sub-period 1, we somehow make it up while processing sub-periods 2-n is really just saying "use more CPU cycles in the hope that it might just work out". Its a false hope, IMHO.
The reality is that the app code has to be RT-safe, and the kernel has to get the hell out of the way. A deficiency in either one can't be solved by the other.
Objective measurements exist as part of Ingo's patches. The reason that using them cannot really solve this issue is that what is being measured is reflection of the system hardware, kernel build and occasionally user-space configuration. People have built systems that *never* fail to meet Ingo's goal. Contrarily, there are many systems that almost never fail to meet them, and many systems where even with his patches, kernel time delays occur too often. So what is one to make of this? I certainly do not conclude that the solution is to modify the design of JACK to incur more CPU overhead in the common case.
Most people do not understand what Ingo's patches actually do. They actually transform "Unix" into a hard-RT-like OS by effectively threading all interrupt handlers. Modulo errors in the scheduler, *nothing* except the lowest level IRQ ack to the APIC, can interrupt code that should be executing. It doesn't matter what other activity is happening on the machine - if the highest priority interrupts (e.g. audio and the system timer) are raised, then *that* code path executes no matter what and cannot be interrupted by other things. Coupled with correct handling of the related SCHED_FIFO tasks from user space and you basically have a system that isn't remotely "Unix" like at all, even though the regular Unix-like system is running next to it. Effectively Ingo has implemented the design of several hard-realtime operating systems.
Its a real question whether a system that was targetted at pro-audio, not consumer use, should be designed to work a wide range of machinery at all. Your comment: "I see only small-block time faults, and not failures to meet the hard realtime constraint at the end of the latency period" makes no sense to me at all. You cannot "see" small-block time faults. There are deadlines, and the required code either executes within the deadline, or not.
I'm not going to continue to discuss this here because its an inconvenient medium. If you want to talk about it more, use the JACK mailing list or find me on IRC. I suspect I know your nick already, and you can find me in #ardour most of the time.