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

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

  4. big list by mossmann · · Score: 5, Informative

    Everything Linux audio/music is listed here:

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

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

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