Slashdot Mirror

← Back to Stories (view on slashdot.org)

Music Sequencing Software for Unix?

Posted by Cliff on from the a-virtuoso-arrangement dept.

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?"

7 of 141 comments (clear)

  1. There really aren't any... by Thalagyrt · · Score: 5, Interesting

    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!
  2. ChucK by TheUser0x58 · · Score: 3, Interesting

    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
  3. Trackers by Storlek · · Score: 2, Interesting

    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.

    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 :) -- Schism Tracker.

    --
    Bears don't normally eat things that talk and move backwards.
  4. Jack is poor, based on a flawed timing design by Anonymous Coward · · Score: 2, Interesting

    Jack is as good as audio gets in Linux and BSD, but unfortunately it's quite severely broken by its design model.

    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 ... but it's far too late to do that now, as the current buffer model is engrained in a million Jack clients.

    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.

    1. Re:Jack is poor, based on a flawed timing design by Anonymous Coward · · Score: 1, Interesting

      I can run jackd with ardour at 2.3ms stable and reliable on a 2.5 year old PIV 2.8 with a 6 year old Terratec Audiocard, while having Firefox browsing the Internet and with a Desktop Preempt Kernel.

      Plus: xruns occour from time to time but only if I start up critical Apps like Zynadd, load huge Projectfiles etc. So to be sure, that xruns do not cause any harm, I only need to avoid starting major apps while a Recording is running...
      When I close a usual session after 3-5 h I have maybe 3-4 xruns and none of them influenced the recorded material in any way. Even if I run into real trouble with jackd (by playing a problematic Zynadd-Patch with too much polyphony or the like), the session recovers usually without need to restart, when stopping the apps, that had caused the trouble.

      So I fail to get your point: what are you doing with your system and your other-side-of-the-globe Musicians that a single xrun can destroy your work??

      zettberlin linuxuse.de/snd

    2. Re:Jack is poor, based on a flawed timing design by Anonymous Coward · · Score: 1, Interesting
      I'm one of the early adopters of ingo's realtime preemption patches (not to be confused with the realtime module which simply let's ordinary users run processes with SCHED_FIFO scheduling). And with my precious M-Audio Delta 66 i can use buffersizes down to 8 frames. Which results in a roundtrip latency of

      (8/48000)*2 = 0.00033333

      That's 0.3 ms, suckers.. glitchfree (of course irq load and context switching load gets a bit costly then)..
      We're very pleased for you. But since Ingo's patch isn't in the mainstream Linux kernel, let alone available in any other O/S's where Jack is used, it's not exactly relevant to a discussion about normal Jack timing problems, is it.

      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.
  5. Let's have a public Ardour API by Anonymous Coward · · Score: 1, Interesting

    Well said, Paul.

    However, by the same standards that we would like to apply to others, Ardour should define its own public API + protocols/formats so that third parties can interoperate with it without needing to read the full source code.

    I don't mean that Ardour is *closed* of course, but simply that an official API for doing programmatically many of the things that can be done using keyboard and mouse simply hasn't been provided. That makes interoperating with Ardour beyond simple Jack routing and effects pretty hard.

    "Read the source" is not a helpful response --- a third-party developer is different to an Ardour developer, and should only be looking at Ardour API details, not its implementation. And what's worse, the lack of a public API effectively says that Ardour's goalposts are in complete flux. Well, by version 2 that should no longer be the case.

    What we demand of third parties in respect of documented formats and APIs also applies to us. Give Ardour an official public API, independent of its source code. Then the whole world can create bindings and cooperative applications and extend the use of Ardour far beyond its current niche.