Hi happy Ardour users,
All is said in the title, I like to launch this little survey. What do you prefer in terms or ergonomics, CPU eating, possibilities of groups, sub-mix, workflow, your ideas…
Ardour2 is absolutely fine for simple multi-track recording and mixing (without too much editing), Ardour3 definitely feels as if it carries a lot more ‘weight’ around. It doesn’t seem much heavier on resources (like for like) once its actually running, but I could make and consume several cups of tea while just waiting for it to start up on at least one of my machines, whereas Ardour2 is quite nimble by comparison. I much prefer the look / feel / (more) professional features of A3 though.
A2 is great for capturing ideas, almost possible to use as a kind of ‘sketch pad’, whereas by the time A3 has started up, sometimes I’ve forgotten what I was going to do with it anyway 
I find A2 more stable and reliable.
I had to throw away a session that was completely screwed up with A3, restarting it from scratch with A2. The latest A3 release seems ok.
I do not use MIDI, so I switched to A3 just to keep up with the evolving of the product.
The look and feel is better with A3, especially the mixer window and the session select window, much smarter than before.
Regarding startup time & performance, on a core i7 PC I do not perceive any difference. Memory is not an issue, 2 GB are more than enough 99% of the times.
[for some unknown reason the preview of the message doubles the first line]
I don’t know the reason for the slow startup times, this is on a machine with similar amounts of memory, but quite an old CPU. More than enough power to run and mix a session once its loaded, there just seems to be a lot going on at startup. Could be lack of optimization in the debug builds I suppose. That said, A3 is a huge step forward, the look and feel is much better, and its great to have proper metering finally, not sure if I will ever have much use for the video timeline though.
I’ve started playing with Harrison Mixbus (ardour 2 based) recently for mixing and it is awesome… I do prefer the A3 interface in general excluding the mixer (mixbus is really really well designed) but at low latency the dsp usage goes up much higher compared to Ardour 2… As mixbus has a lot of DSP going on there isn’t much difference.
If I was pushing the boundaries of plugin usage and requiring really low latency at the mixing stage or on an older machine I would go with A2 but otherwise I would say go with A3… Me, I’m going with A3 at tracking stage and then mixing in mixbus…
Defintely A3, all new features compensate for me the startup speed, also A3 is much more easier on the CPU on larger sessions one multicore cpus, thing i cannot say about mixbus, so at the end i agree with allank, A3 for Recording and Editing, Mixbus for mixing (although the new meters in A3 are a great improvement and makes it way more useful when mixing)
I wonder how digital mixing desks achieve such low latency with all the features they pack . upto 64 channels all with EQ , gate , compression routing to buses and sends.
then theres fx you can assign to channels, .
graphic EQ’s on buses
Take the allen and heith ilive, its not exactly a powerfull computer.
Do they do GPU computer, are they like playstation 3 compared to PC type thing, where they have wicked gpus.
veda_sticks: if you carefully build a linux computer, and carefully pick your audio I/O chipset, you can get 8 samples for the period/buffer size. That’s one hint. The other hint that covers older digital desks is that traditional hardware DSP doesn’t use block-structured audio, it processes samples by sample, giving you close to zero latency. The cost of that is an inflexible architecture that doesn’t really benefit over time from the improvements we’ve seen to generic processors and generic operating systems.
Actually last I checked GPU processing means a fair amount more latency, not less.
the iLive is actually multiple computers. You have one in the mixrack, which is a custom designed computer for the purpose, much like Paul mentioned, with specifically picked parts down to the chips used, running a hard realtime OS (cOS). You also have a Linux computer running the touchscreen of the surface running essentially bog standard Linux on a C7, but all it is doing is acting as a remote control to the Mixrack.
Seablade@veda_sticks, Paul is correct about older digital desks (I have had direct experience of some of the processing designs used in professional digital consoles), and long before powerful enough ‘general purpose’ DSP devices were available it was commonplace for the circuitry to be composed of, for example, several dedicated math units hardwired to perform an ‘algorithm’ for each aspect of the console’s operation e.g. dynamics, or an EQ etc. Typically these assemblies will synchronously process sample data for many channels within a single I / O sample frame by time slicing the processing across the channels within one sample period. The result is that the latency through the system is very low, and absolutely predictable. The tradeoff is that you can’t change the core algorithm much, although for example EQs can be designed which can be configured for most filter functions by calculating suitable coefficients. Modern programmable DSP devices (such as those used in add-on PC interfaces or in modern digital consoles) can now achieve similar results, with greater flexibility, but the key thing is that they are specifically designed for the task. In terms of its relevance for audio processing, the general purpose PC architecture really isn’t that far removed from e.g. early 286 etc machines, so the idea that anyone can do any audio processing at all, on what was originally a spreadsheet / wordprocessing machine is actually very impressive, when you consider how ‘un-designed’ for audio the PC actually is.
It’s also worth noting that when you get to below maybe 50 samples latency, the conversion through the A / D - D / A converters starts to become the limiting factor.