Slashdot Mirror
Music Sequencing Software for Unix?
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?"
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
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!
Before you dump a bunch of dough on hardware synths, have you checked out the quality of software synths? (VSTs for Linux appear to be hit or miss, but the ones for Windows are amazing).
Since when did you have to use Obj-C to write a program in Java? Did someone not get past printf?
oh just use your standard windows app, and use wine or crossover office 6.
sure beats waiting for someone to make a port for linux =/
The difference between a useful recording package and a relatively useless one, has to do with what hardware it will work with. (This is slightly offtopic, since the OP was asking about sequencing and not DAW, but it's related.)
One of the reason ProTools is the de facto standard is because it's compatible with virtually all the hardware available. There are lots of tools for free that will work with one or two channels pushed through a soundcard, which might be enough for guitar+vocals, but it's a bit short of what most people want to mic a band. Real problems start to happen when you get into FireWire audio interfaces or ADAT cards. They're expensive enough that generally, what hardware you have available is going to drive the software, and they're mostly made to work with ProTools, either on Mac or Windows.
The hardware manufacturers, MOTU in particular, are basically hostile towards Linux, which means that the interfaces aren't well supported in Ardour, which means most people are going to look elsewhere for software. The hardware is expensive enough that it drives everything else.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
I've been using FL Studio (formerely Fruity Loops) for years and it's great, plus it has many add ons available. I've looked for an equilvalent for linus but they don't really exist. I even tried running FLS under wine, but I couldnt get it to work. Someone who's a bit more savvy than me might be able to do it though :P.
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
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.
Real men use cat and a directory with one file for each possible note.
When information is power, privacy is freedom.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
Well, it's not a sequencing only software, but a synthesizer with sequencing capabilities (for its own internal instruments) to keep track of the storyboard.
You can check it out by yourself here: http://zynaddsubfx.sourceforge.net/ , and it is distribuited under GPL V2 license.
Mastering the English language is fucking easy: all you have to do is to put an f* word in every fucking sentence.
Not sure if it fits the bill, but when I was looking for something to play around with, I ended up using this.
He was probably pointing out that you don't have use Obj-C to write OS X apps. Thus Java, because you can use Java.
====
Crudely Drawn Games
dd if=/dev/urandom of=/dev/audio
Ah, good point. Overlooked that one. =P
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo!
PlanetCCRMA http://ccrma.stanford.edu/planetccrma/software/ is a collection of RPMs intended for audio workstation use that can be added to a Fedora Core 5 install (or 1-4, or RedHat9.) It includes a low-latency kernel, and apps for audio work.
Your hardware matters. RME's Hammerfall soundcards are very high quality, and designed with Linux compatibility in mind (kudos.)
For multi-track recording and work requiring low-latency, I believe you're stuck with Linux; AFAIK the BSDs will not provide real-time kernel access for non-root users.
Or he could get himself an old Amiga.
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)
You can also use the Carbon API (via C, C++, assembly, pascal, etc).
Do you even lift?
These aren't the 'roids you're looking for.
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/
Everything Linux audio/music is listed here:
http://linux-sound.org/one-page.html
http://jokosher.org/
Jokosher is described as "Audio production made simple".
Based on gstreamer and an attempt to make something that is much easier than Ardour to get in to (not as complex, and never will be). A music editing and mixing software targeted for garage bands and hobby podcasters and the like. 0.2 are more or less 1.0, which will be released any week now (when the gstreamer multi input soundcard bugs are taken care of). Will support Jack and such...
I've learned all I know about politics from
A nice distro is http://64studio.com/ for 64 bit cpus but also available for 32 bit. I get at least as low as 2ms latency which I never got either on Windows nor OS 9/ OSX, maybe less is possible but I didnt dare so far.
Further sequencing: Muse
http://www.muse-sequencer.org/
wired looks promising but seems a bit hard to get it running
http://wired.epitech.net/
Linux can do professional grade audio and is often used by academic musicians. The Jack audiosystem adds an flexibility which is missing on other platforms (except its now available for OSX and soon Windows).
For mastering Jamin do incredible things:
http://jamin.sourceforge.net/en/about.html
Cheers, Malte
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.
:) -- Schism Tracker.
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
Bears don't normally eat things that talk and move backwards.
You don't have to use C or C++ to use GTK+ or Qt, but that won't stop anyone from pointing out the obvious fact that if you don't use the language for which the toolkit was designed you'll not get the full worth of that toolkit.
How we know is more important than what we know.
You've totally gotta check out TamTam, the PyGTK C-sound based music tracker included with OLPC.
http://wiki.laptop.org/go/TamTam
It's not done yet, but will be very soon due to necessity.
Jack is as good as audio gets in Linux and BSD, but unfortunately it's quite severely broken by its design model.
... but it's far too late to do that now, as the current buffer model is engrained in a million Jack clients.
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
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.
"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."
Uh, huh. Well there goes the whole "do-it-yourself so we can have free music" oh, and "escape the music cartels" argument. Nice to know the "new and improved" business model crowd has all the details covered.
Will Windows Vista content protection features increase CPU resource consumption?
Yes. However, the use of additional CPU cycles is inevitable, as the PC provides consumers with additional functionality. Windows Vista's content protection features were developed to carefully balance the need to provide robust protection from commercial content while still enabling great new experiences such as HD-DVD or Blu-Ray playback.
Emphasis mine.
Too busy staying alive... ~ R.A.
.. the fact is, the DAW software realm is as incestuous and stagnant as fuck. witness the raping of the market constantly going on between developers like Ableton (Live) and the Fruity Loops guys .. not to mention the iron grip that the VST mess has on the world.
.. especially if the holy grail of "Full Source For Everything You're Running" gets fulfilled. I look forward to having a Linux based DAW in my setup so that, if theres' something I want, I code it up myself and contribute .. unlike the existing scene in the PC/Mac DAW world where everyone is suddenly a rockstar programmer coz they got a filter running ..
Linux as DAW is a breath of fresh air
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
http://trac.zeitherrschaft.org/aldrin/
A clone of Jeskola Buzz.
Its in Alpha stage, but it already works pretty well.
Isn't this exactly what the --nperiods option for JACK's ALSA driver is for?
Nope. Or if that's what it's intended for, then it's not what it actually does, so maybe we're merely looking at a coding bug --- I hope so. But if so, then the bug's been there forever.
The problem is easy to see. For example, with --nperiods == 4 (say), an XRUN occurs if the quarter-latency buffer isn't processed in 1/4 of the latency time, instead of allowing the instantaneous failure to slack over into the other 3/4 of the available time. In other words, if the instantaneous timing requirement isn't met, then the current implementation of --nperiods doesn't allow the CPU to catch up during the remainder of the overall latency period, even if the glitch was much shorter than the latency period and there is tons of CPU available. A hot-rod machine simply isn't given a chance to recover, regardless of the setting of --nperiods.
The --nperiods setting should be allowing us a tradoff between instantaneous responsiveness and system load average, because for a fixed value of latency we should be able to use smaller buffers (and so have more processing overheads) but have more time to recover from timing failures by applying CPU muscle "after the event". Well it ain't, sadly.
And I don't think that there's any interest in fixing the problem, because so many Linux audio developers have very efficient pro' interfaces and so the occurrence of timing faults isn't high enough to matter for them. YET, that is! -- it will matter as sample rates rise. Well, sure, a pro' user would almost always buy a pro' interface, but that's no reason for ignoring a problem in the implementation (or design) that affects everyone else. This issue still bites users with pro' interfaces, but it just does it a lot less often.
There's too much "we're already perfect" attitude around in Jack circles, and it's not helping. The fact is, we glitch audibly in circumstances when one other O/S that we regard as crappy (and rightly so) doesn't, on the same computer and using the same interfaces and with RT properly set up. We're not perfect. Swallow your pride, listen for glitches using a less efficient interface, and fix it if it's a bug. Or redesign the damn thing if it's a more fundamental problem.
http://en.wikipedia.org/wiki/Free_audio_softwares oftware
s oftware
http://en.wikipedia.org/wiki/List_of_Linux_audio_
http://en.wikipedia.org/wiki/Category:Free_audio_
http://en.wikipedia.org/wiki/Hydrogen_(software)
You could do far worse than have a look at energtXT2 by Jorgen Aase. Its a ground-up rewrite of his acclaimed energyXT sequencer which is now cross platform. EnergyXT was fairly innovative for being both a VST plugin host and a VST plugin itself (VST being the de facto standard for plugins on most Mac/Windows audio sequencers) as well as being a flexible 'modular' routing environment.
The first beta release of 'core' functionality was released in early December, and the most recent beta is only a couple of days old.
http://www.energy-xt.com/
free experimental electronic music netlabel at www.viablehybrid.com
This software looks great! Check out the screenshots...it reminds me of cubase. http://wired.epitech.net/index.php
Obligatory blog plug: http://www.caseybanner.ca/
please mod parent up, it's making it look like the JACK designer is commenting on the wrong person. What a stupid way of laying out arguments.
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.
Unlike fucktards like you who are too fucking stupid to even exist let alone use a computer. As such you should go slit your fucking wrists fucktard.
... can use DSSI or LV2 (although LV2 isn't quite mainstream yet). There are a lot of very good DSSI plugins out there, which might not look as polished as VSTis but far surpass them in quality and usability. Hexter, for instance, is a much better DX7 emulation than FM7 - cleaner and a lot closer to the original hardware. And of course modesty forbids that I mention nekobee, a TB-303-style bass synth plugin.
These are just two. There's ZynAddSubFX (which isn't DSSI, but is good), qsynth/fluidsynth, which plays back soundfonts for a cheap-and-cheesy sampler, Xsynth-DSSI which is a nice basic 2-osc polysynth, WhySynth which is too complicated for its own good, sineshaper which is just *bonkers* and many more.
It's great when a person sees a limitation in an existing popular system and just goes ahead and produces an alternative, as in jackdmp above.
Unfortunately, such lone efforts don't gain the huge benefit of the FOSS community power which underpins the old system, and if they try to remain compatible, they are always destined to play catchup as that old system evolves. And what's worse, this approach carries the implication that the designers of the old system are not willing to listen to technical reasons for evolving their design.
Kudos to the jackdmp designer for achieving progress under the hardships of going it alone. But how come that such alternative operating regimes haven't been integrated into mainstream Jack as switchable options, despite the benefits having been demonstrated in real code? Why is Jack resolutely stuck in the past and immoveable?
In my view, forking is extremely bad, and should be done only when a project is in dire straights and its community is stuck in the past and is now beyond the pale. That's NOT where Jack is today. But yes, the Jack community should definitely be embracing new core ideas, not arguing defensively against them and forcing people to make alternatives like jackdmp.
A newer Linux convert here I use it now for all my creative outputs except music, does anybody know a good all around music generator/virtual synth a'la Reason or Fruityloops.
I hear there's a bunch of programs that run under VMWare. ;)
No, I will not work for your startup
Rosegarden, Audacity, and the ALSA Modular Synth is what I used to make this album 3 years ago: http://www.melancolicocatrin.net/en/music.html#MON OFONICO
I still use those apps on the 2.4 kernel and the list keeps growing.
NO U
Tiger is rumored to be in the works of getting UNIX certified, so Mac OS X 10.5 can be called UNIX, not unix-like. But anyway, why do people use the word unix when they are obviously talking about Linux in discussions like this?
Preempt and low latency kernel work were patched in during the 2.4 kernel series. They were not part of the standard Linux distribution. After several cycles of working with them, they were eventually added under the experimental kernel config options, and then finally became a part of the standard kernel options.
If a few people want a kernel feature, they can write patches for it. That gets the ball rolling, and then if the patches are effective, demand rises and they eventually work their way in as a fully acknowledged feature. No reason for the grandparent to call it hopeless.
Isn't this how the Mellotron worked?