MusE is an extensive Open Source MIDI and audio sequencer for Linux, based on Qt. The developers have been interviewed by O'Reilly. For those interested in some background information about MusE, MIDI and audio development on Linux, be sure to check it out.
A progress report for the coming 0.7.2 and 1.0 releases has also been posted to the MusE website.

Comments

Rosegarden (www.rosegardenmusic.com) is another qt-based midi program. IME it is a bit more stable, and the notation editor is much nicer, however muse has much better jack integration. But it's definately worth trying both.

Personally, by judging from the screenies i think wired [http://bloodshed.net/wired/], is woking on something like Ableton Live, which currently gets more and more mindshare from the live performing musicians.

Well, I can't call rosegarden stable. In the last (quite a few ) tries I was quite dissapointed with rosegardens' stability. They added jack support, and since then I couldn't manage to get it working for more than a few minutes without freezing my machine completely. (while other similar software like muse didn't). The only real way I could figure out was disabling sound completely (not only jack). But then it would be rather useless, wouldn't it?

MusE had a score editor but it was removed since the author, Werner Schweer, found it to be a technical deadend. MScore is a redevelopment of a score editor for MusE. It does read MusE score files (or so it is planned anyway), it is still in it's infancy but already quite usable.
If technically possible it will make a return in a future version of MusE.

What I miss under Linux is a tool such as Band-in-a-BOx, a software which made it from the ATARI and covers what musicians really need. It has no clean design but all the features other solutions lack. It is a wasted effort to catch up with cubase and so on. Bazaars are bad for building cathedrals. At least when everybody knows how the ready cathedral shall look like.

It is nice to finally could say: "The state of Linux audio synthesis _was_ in need". Between MusE, Rosegarden, Audacity and Hydrogen, those so inclined could finally get down to the essence, instead of continually titubating between half-finished, feature-incomplete, not-quite-always-compiling tradition of things in this domain.

Congrats, MusE team!

I believe there's an important need inside KDE to coopt people like the MusE team (we already have a staunch supporter and contributor in Rosegarden's Guillaume Laurent).

Converging to a better choice of multimedia infrastructure and producing a set of native KDE apps that would cover the bases and fill the (few) remaining gaps could be the major tasks for a to-be-enhanced multimedia task force (see http://www.kde.org/areas/multimedia/).

There must be some misunderstanding. MusE does not require any kernel patch, though there are patches that enhance the realtime performance, lately the kernel has taken huge leaps in performance improvement, since 2.6.10 you get along quite well with a standard kernel.

As for MusE needing some work, yes of course, we are far from finished. But it is already stable enough to be able to comfortably create music (depending somewhat on your style of work).

I pretty agree with the parent comment. From my point of view, it is much more simpler to install and run a webserver than a simple music app like Muse (yeah, simple. Very simple. Reason is complex -but 1000000 times simpler to have running on win-). Have tried during hours to make the midi works, but it still f... Muse is interesting ; but if I could use it it would be much more interesting ! Sure, there are how-to, but at minimum a level of professionnal sys-admin is required to follow them. So there are much more improvements to do in this direction than having always more features. If you write apps for musicians and no musician is able to install it, then you lost. I don't know any musician that use Linux Apps ; however most of them know computers very good, but this is simply a nightmare to have an application working. Musicians are not Geeks, they don't want to patch their kernels and start module and install packages, they want to make music with the computer. Understand that and you will write the killer app.

KDE has a policy of being system-neutral. ALSA is Linux-specific. If KDE depended directly on ALSA, it wouldn't work on BSD, for instance. That's where aRts came in: to provide sound abstraction. KDE plugs in to aRts which plugs in to OSS (or whatever your system provides).

There is an ongoing debate about what sound system to use for KDE4, it seems. There was some hubbub about it at the last Konference. From memory, the idea is that aRts is deprecated: the sole developper that built it is gone, and it's difficult (actually, it bordered closer to "impossible", I think) to maintain. So they're either going to either rebuild it from scratch, or pickup Gstreamer. Scott Wheeler, author of JuK among other things, made some KDE bindings for Gstreamer.

Personnally, I think it'd be cool if KDE picked up Gstreamer. It's a very powerful multimedia framework with lots of activity around it, it has already been picked up by GNOME, and it remains desktop-neutral!

Unfortunately, because it's a framework, and not directly an audio sink (which ALSA and OSS are), the latency problems you had with arts are there to stay... As the KDE team will probably add an extra layer to it (to manage events for instance?), it's not going to get better :(

we also need codecs, among other media gadgets. ALSA doesn't provide those even if it were x-platform.

> they're either going to either rebuild it from scratch

this has a snowball's chance in hell of happening. it would make pretty much zero sense to repeat the same mistakes over again (trying to incubate a sound system within KDE) when viable solutions already exist (something that wasn't true with aRts came around).

> or pickup Gstreamer.

this is highly more plausible, though not the only option being considered at this time.

> As the KDE team will probably add an extra layer to it

seeing as where the layer will be and what it will be used for, i highly doubt this will matter

That said, it should be noted that things like ALSA *aren't* media frameworks and don't compete with things like aRts, GStreamer, NMM, etc. The latter are all high level frameworks to simplify dealing with the lower level more complicated issues like, well, dealing with output drivers directly.