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

17 of 141 comments (clear)

  1. Rosegarden and Ardour by SocialEngineer · · Score: 5, Informative

    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
    1. Re:Rosegarden and Ardour by Anonymous Coward · · Score: 5, Informative

      Also, don't forget to install the JACK Audio Connection Kit first, optionally with a GUI front end.

      JACK will generally give you much lower latency, and it will handle synching between multiple audio apps.

    2. Re:Rosegarden and Ardour by Eideewt · · Score: 5, Informative

      Parent has given you about the best answer you could get. Seq24 is a neat little program if you're just looking to set up some MIDI loops to play with. Csound and CLM (Common Lisp Music) are worth a look if you'd like to do things programmatically. Also Pure Data, which does much the same thing graphically.

    3. Re:Rosegarden and Ardour by Eideewt · · Score: 3, Informative

      Yes! Jack is the way to go if you're looking to do any audio work in Linux. As a bonus, it's an amazing system by any measure. It will let you pipe audio between programs however you like with a "virtual patch bay".

    4. Re:Rosegarden and Ardour by Short+Circuit · · Score: 5, Informative

      If you're sequencing, you're going to want a decent sound font. I highly recommend Musica Theoria 2 (scroll down to just above mid-page), for personal use. (I've seen it listed as having a non-commercial license attached to it..) You can use Wine to unpack the SfArk file.

      You'll want to grab the Timidity configuration file, so Timidity will know how to use the sound font. A quick Google search isn't turning up the link, so here's the copy I use.

      Finally look at Timidity's MAN page. You're going to want to look at setting up the ALSA MIDI loopback, so that your MIDI software's output gets redirected to Timidity.

      I've never done much with MIDI sequencing, but I love my video game MIDI music. :-)

      --
      tasks(723) drafts(105) languages(484) examples(29106)
    5. Re:Rosegarden and Ardour by MrHanky · · Score: 4, Informative

      And for everything else, there's the Dyne:bolic distro. It's not slick or anything, but has lots of powerful multi-media tools that you can use without wasting resources on drop shadows and anti-aliased text. It's designed to run on an Xbox (64 MB RAM, etc.).

  2. 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!
    1. Re:There really aren't any... by Thalagyrt · · Score: 5, Informative

      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!
    2. Re:There really aren't any... by Thalagyrt · · Score: 3, Informative

      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!
    3. Re:There really aren't any... by littlerubberfeet · · Score: 5, Informative

      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)
  3. 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
  4. Linux MultiMedia Studio by Disharmony2012 · · Score: 5, Informative

    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.

  5. A good starting place. . . by munpfazy · · Score: 3, Informative

    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)

  6. It depends on you by Schraegstrichpunkt · · Score: 3, Insightful

    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/
  7. big list by mossmann · · Score: 5, Informative

    Everything Linux audio/music is listed here:

    http://linux-sound.org/one-page.html

  8. Re:Jack is poor, based on a flawed timing design by paulbd · · Score: 4, Informative

    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

  9. Re:Nope, --nperiods is not a (working) solution by paulbd · · Score: 4, Informative

    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.