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

4 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.