Music Sequencing Software for Unix? 141
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?"
Rosegarden and Ardour (Score:5, Informative)
Re:Rosegarden and Ardour (Score:5, Informative)
JACK will generally give you much lower latency, and it will handle synching between multiple audio apps.
Re:Rosegarden and Ardour (Score:4, Informative)
Jack is poor, based on a flawed timing design (Score:2, Interesting)
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 inte
Re: (Score:1, Informative)
From the manual:
-n, --nperiods int
Specify the number of periods of playback latency. In seconds,
this corresponds to --nperiods times --period divided by --rate.
Nope, --nperiods is not a (working) solution (Score:1, Informative)
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 ava
Re:Nope, --nperiods is not a (working) solution (Score:5, 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.
Re: (Score:3, Informative)
This is all wrong. It takes A(nframes) + B cycles to process nframes of audio. This is an invariant, unrelated to period size or count (although period size may affect B). The only things that can really change A(nframes) + B are:
If you were slow on one of
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2, Informative)
"delay model is buffersize-based"
In audio, is there any other model *if* you wish to maintain sample-accurate sync which is criticial for pro-audio work?
"and so it req
Re: (Score:1)
What a nice way to start your response, just like a typical Jack developer. Do you intend to become a professional some day?
I was neither trolling, nor am I an idiot -- I understand very well how this system works, but I also see that in far too many situations it fails to work with adequate quality. You in contrast answered like a defensive fanboy, and your reply was full of straw men. A personal confrontation doesn't help, nor does an
Re:Jack is poor, based on a flawed timing design (Score:5, 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
Re: (Score:2)
First off, I am not a JACK developer. Second, I use more than just Linux, and perhaps most importantly I do audio for living (and yes, use JACK in time-critical situations), so I guess that by definition qualifies me as a "professional."
"It's all working perfectly".
Well, yes, in a nutshell it works when configured right. On my hardware I have had no problems on 3 different laptops an
Re: (Score:1)
Excellent snipe. I don't see any professionals in this thread laughing at the JACK folks. I do see an Anonymous Coward taking a snipe behind inflated cover, however.
What are your credentials, here, Mr. AC? Care to share your production experience with designing and implementing these systems?
Re: (Score:1)
Agreed. However, saying stuff that even I, as a user of digital audio recording software (both as a home user on a PC and (granted only a few times) in genuine studios) can sniff a fundamental misunderstanding on, does not recommend your opinion to me, especially when you post as an AC. By my experience, Jack does a stunningly good job, and given the same hardware, I greatly doubt that the (?
Re: (Score:3, Informative)
(1) realtime-lsm doesn't do anything performance related at all. It is an old solution to a permissions problem, namely allowing non-root users to run threads in the SCHED_FIFO scheduling class and allowing them to use mlock() to pin memory in physical RAM. how well a SCHED_FIFO thread performs is 100% orthogonal to the existence of realtime-lsm. it is also now a deprecated solution for 2.6 kerne
patched kernels (Score:2)
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 f
Re: (Score:2)
MOD UP, please (Score:2)
Re: (Score:1, Interesting)
Plus: xruns occour from time to time but only if I start up critical Apps like Zynadd, load huge Projectfiles etc. So to be sure, that xruns do not cause any harm, I only need to avoid starting major apps while a Recording is running...
When I close a usual session after 3-5 h I have maybe 3-4 xruns and none of th
Re: (Score:2)
For windows if someone sticks in a CD into the CDROM drive often bad things happen to "real time".
That said, I've had lots more problems with Linux sound than with Windows. Apps not being able to play sounds at the same time etc.
Re: (Score:1, Interesting)
We're very pleased for you. But since Ingo's patch isn't in the mainstre
Re: (Score:2, Informative)
Most of Ingo's realtime/preempt work is already merged into the mainstream kernel. Full merge by 2.6.21 or thereabouts.
Also, most jack users are using a realtime kernel, so it is a relevant point.
Re: (Score:1, Informative)
The realtime-lsm module is deprecated since 2.6.18 (at least). No patching or extra modules are needed to allow RT scheduling for normal users in recent kernels (which is what realtime-lsm did), meaning that anyone can get
Re:Rosegarden and Ardour (Score:5, Informative)
Re:Rosegarden and Ardour (Score:5, Informative)
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 [grc4.org]'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.
Re: (Score:1)
Hear, hear! I know that feeling very well.
P.S. Did you know that VGMusic.com [vgmusic.com] turned 10 years old at the end of 2006?
Re:Rosegarden and Ardour (Score:5, Informative)
Re: (Score:2)
Re: (Score:2, Insightful)
It's nice to notice OS X is supported better now. After all, OS X completely avoids the two most prevalent problems that makes Linux unsuitable for real music pr
no real competition .. (Score:1)
Linux as DAW is a breath of fresh air
Re: (Score:2)
There really aren't any... (Score:5, Interesting)
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 [rosegardenmusic.com].
Re: (Score:1)
Re: (Score:3, Insightful)
Re: (Score:1)
Re: (Score:2, Insightful)
You're confusing the operating system with the applications. Yes, there are many professional applications that run on Windows, but that doesn't make Windows a professional O/S. It's basically an unreliable pile of junk with a glossy coat. That contrasts with Linux and the various Unixes, which are professional operating systems but unfortunately wearing a somewhat shabby coat (professionals don't need eye candy).
The term "Windoze" embodi
Re: (Score:2, Informative)
Re:There really aren't any... (Score:5, Informative)
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?
Re: (Score:1)
And RME is not professional? Most of their cards have full support in linux thanks to ALSA.
Re:There really aren't any... (Score:4, Informative)
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.
Re: (Score:1)
I have low latency hardware ( say < 5msec ) with good S/N, good mics and premamps and I use ardour + jack + ladspa to record. I actually prefer Ardour to protools for basic multitrack recording and if my input and monitoring are adequate, so is the data I produce.
So if I stumble across some new sound that has that certain something and want to recor
Re: (Score:2)
What I was saying with the Pro Tools thing was a large generalization. Almost all of the major studios out there use Pro Tools, and because of that market share, most of them will continue to use Pro Tools until something else comes out that interfaces 100% and does a better job. There are already plenty of tools out there that do a better job, b
Re:There really aren't any... (Score:5, Informative)
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.
Re: (Score:3, Insightful)
Its a little wierd that if its a hobby toy, major mixing desk manufacturers like Solid State Logic, Harrison and others would support the development of the application. Even wierder that Harrison would demo Ardour on one of their latest high digital consoles at the National Association of Broadcasters last year.
As the author of Ardour, I tend to think that its an unreliable, cumbersome, hard to use and flaky piece of crap. And then I either actually get a chance to play with one of the proprietary DAWs
Re: (Score:1)
Before dismissing it again, I will have to give it a decent try. I didn't know you had MTC support. If your V2.0 release supports OMF and Mackie HUI, I will give it a try on a non-critical film mix project. At least then, I will have a decent basis for any criticisms or accolades.
If you
Let's have a public Ardour API (Score:1, Interesting)
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
Re: (Score:1)
Slight digression - checked out VSTs? (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:1)
Linux software synths... (Score:2)
These are just two. There's ZynAddSubFX (which isn't DSSI, but is good), qsynth/fluidsynth, which
Re: (Score:2)
As a previous poster mentioned, this guy should check out Rosegarden and Ardour.
Not Linux but... (Score:1)
Re: (Score:2)
ChucK (Score:3, Interesting)
Linux MultiMedia Studio (Score:5, Informative)
Re: (Score:1)
Re: (Score:3, Informative)
*It's hard to get VST. I haven't gotten it working yet, but it may work if you know more about compiling than me or use another distro.
*It doesn't (seem to?) have effects, HOWEVER, it controls filters (low pass, high pass, etc) at the sample level. Using the tools it does have,
Real men.. (Score:3, Funny)
Mellotron (Score:1)
Isn't this how the Mellotron [wikipedia.org] worked?
Re: (Score:2, Funny)
Why do I get a sudden urge to download it and write some death metal with satanic themes after seeing that page?
Re: (Score:1)
LMMS (Score:2, Informative)
an audio workstation distro: PlanetCCRMA w/ FC5 (Score:2, Informative)
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 kerne
A good starting place. . . (Score:4, Informative)
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)
It depends on you (Score:4, 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.
big list (Score:5, Informative)
http://linux-sound.org/one-page.html [linux-sound.org]
Re: (Score:1)
Jokosher (Score:2, Informative)
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...
64 Studio (Score:2, Informative)
Further sequencing: Muse
http://www.muse-sequencer.org/ [muse-sequencer.org]
wired looks promising but seems a bit hard to get it running
http://wired.epitech.net/ [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 oth
Trackers (Score:3, Interesting)
For Linux, there's (among plenty others, these are just the most prominent ones) MilkyTracker [milkytracker.net], ChibiTracker [chibitracker.com] (which is the successor to Cheese Tracker [freshmeat.net]), and -- don't mind if I spam my own program
TamTam (Score:1)
http://wiki.laptop.org/go/TamTam [laptop.org]
It's not done yet, but will be very soon due to necessity.
Protection from content. (Score:1, Offtopic)
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.
Wikipedia articles (Score:1, Informative)
http://en.wikipedia.org/wiki/List_of_Linux_audio_s oftware [wikipedia.org]
http://en.wikipedia.org/wiki/Category:Free_audio_s oftware [wikipedia.org]
http://en.wikipedia.org/wiki/Hydrogen_(software) [wikipedia.org]
energyXT 2 (Score:2)
The first beta release of 'core' functionality was released in early December, and the most recent beta is only a couple of
Wired - http://wired.epitech.net/index.php (Score:1)
What about generators. (Score:1)
VMWare? (Score:2)
Why do people use the word UNIX? (Score:1)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)