Mike Rivers wrote:

> Conceptually, you can say that any DAW is comparable to any other DAW,
> as long as you put some reasonable bounds on the minimum requirements
> of a DAW. ...

Ok. Ardour's feature list also can hold its own against (some?)
commercial DAW software. My point was that if you are able to work with
Brand X DAW software, the skills transfer to Brand Y, and back. Either
Brand X or Brand Y could be Ardour. What it comes down to, really, is
whether one package includes some feature(s) that really make a
difference to how the user works. That's what sets the different
software apart.

> Is Audacity a DAW? To some it is because it does everything they
> want it to.

Ok. I would have said "no" because it doesn't operate on the audio
files in the way I think of DAW software operating (non-destructively),
but ok, if some people want to think of it that way, fine. I think of
it more as an "editor" which isn't the same at all.

> Is ProTools a DAW? Most definitely.

Sure. Is ProToolsLE?

> The thing about Ardour, particularly for a non-Linux user, or a Linux
> user who is unfamiliar with audio interfacing on the software side, is
> that it can be difficult to get working, and impossible to get working
> with certain fairly common and useful interface hardware, simply
> because nobody has written support for it yet.

I'd be interested in specific examples, because I haven't run into
that myself. Certainly, though, this leads to another advantage that
free, open-source software packages such as Ardour can have over
the commercial proprietary packages: peer support can have a much
greater depth of coverage, because the people helping are able to
understand the innards of the software (even if they don't, though,
they actually have a chance to, and that counts for more than whether
they take advantage of the opportunity). When someone writes on the
Ardour website forum with a question, they usually get a response from
the lead developer. Do people using commercial DAW software get that
kind of support? Ardour users don't have to pay for that level of
support, though some choose to (Ardour development accepts donations).

> I've been told that you don't need to know Jack about JACK in order to
> use Ardour, and I think that's true if you're content to use your PC
> motherboard's built in audio hardware.

I don't think it's true even if you do use the onboard hardware. You
need to at least know enough to configure it. You need to know that
JACK needs to be running in order for Ardour to work. Do you need to
understand *how* JACK accomplishes what it does? I don't think so. I
certainly haven't studied JACK at all.

> But pick up a $200 8x8 USB2.0 I/O box from your local Guitar Center
> and try to get it up and running and you'll be running back to Guitar
> Center looking for a $1500 RME (or a refund).

Have you tried that? Did you properly research the I/O box (check it
against the ALSA compatibility list) before purchasing?

For years I used Ardour with a mid-level sound card that is better than
the onboard audio on the computer I use as an audio workstation, but not
quite as good as some others. Eventually I upgraded to an RME Digi9652
that has worked amazingly well for me, though I didn't pay nearly as
much for it as you seem to suggest above. Perhaps that's the price for
a different model, though? Still, my point is that one need not make
that price jump from a USB2.0 interface. What you probably *do* want to
avoid, though from iwhat I've been reading recently, perhaps even this is
starting to no longer be an issue, is firewire.

One should research the interface prior to making the purchase, though.
If the interface you're looking at won't work easily with Linux, perhaps
another one will? Take the money you save on software, and apply it
towards better hardware, such as the RME?

>> As I note above, I've been able to take files recorded on a ProTools
>> system, and import them into an Ardour session, and mix in Ardour.
>
> That's pretty easy since for mixing already-recorded tracks you don't
> need any inputs and you only need a stereo output. But that doesn't
> make a DAW, at least not in my concept.

Right, but as I also noted in that message, the projects I've worked on
with this system have _included_ working that way. It's not the only
way I've worked with Ardour. I can record 16 tracks simultaneously, and
use 16 simultaneous outputs (the Digi9652 can do more than that, but
that's all I have converters for). In the interest of full disclosure,
I've done 8 tracks at once.

> The biggest disadvantage that Ardour has is that nobody has written
> Ardour for Dummies, because when it comes to Ardour, most musicians,
> producers, and audio engineers ARE dummies.

There's a decent chapter on Ardour in the recently published "Crafting
Digital Media", by Daniel James on Apress (ISBN13: 978-1-4302-1887-6;
http://www.apress.com/book/view/1430218878) I've found the book useful
for other (not necessarily audio-related) software it discusses as well.

--
----------------------------------------------------------------------
Sylvain Robitaille (E-Mail Removed)

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

hank alrich wrote:

> ... if this or that distribution is critical to successful operation,
> and that depends on a specific hardware configuration, ...

Anybody who gave you the impression that a particular distribution was
critical, or that a specific hardware configuration was a dependancy
either hasn't used Linux for audio work, or doesn't understand
enough about the process to be providing that kind of feedback.
I have always run my audio workstation on Slackware (not an audio or
multimedia specific distribution) or Slamd64 (a Slackware derivative
tuned for working on 64-bit AMD based systems, before Slackware had
its own 64-bit version; also not audio or multimedia specific), on a
number of different systems over the years (originally a hot-rodded
486, currently a dual-core Athlon). I've paid some attention to
the audio/multimedia targetted Linux distributions, but either had
limitted success with them, or preferred the much more familiar
(to me) Slackware system.

> I use NeoOffice, which brings one the typical "office" suite for very
> little money (or none, depending on one's situation). The deal there
> is that it works with most hardware, and does so just like most other
> apps of that type.

What exactly hardware-specific issues are there likely to be with
"office" type software? (and have you tried OpenOffice.org?)

> That's where pro auido on Linux hits the rocks, still. I look forward
> to hearing someday that it navigates around the rocks easily, but I'm
> not reading that yet.

When you buy an interface to work with (insert commercial audio software
package here), do you buy the interface just hoping that it will work
with the software you use, or do you evaluate several and find one that
will work best with that software?

> .... If I set out to get pro audio running for me under Linux, I might
> as well sell the guitars.

That's not necessarily true, though as with any unfamiliar software
environment, there's a learning curve, and that requires some
investment in time.

You'll ("you" generally; not necessarily "you" personally, but perhaps
....) invest about the same amount of time the next time you upgrade
your Windows PC (whether because you bought a new PC, or because you
got tired of the problems with the version of Windows currently on
your PC; substitute "OS-X" for "Windows" above, if you use a Mac) and
find you need to purchase new versions of your favourite applications,
which are incompatible with the new version of the OS, with a couple
no longer available, but you'll be prepared for that, and will believe
it to be a good use of your time, because it's professionally produced
software that you paid good money for.

My point is that either way, you're spending more time, for some
period of time, learning your way around a new system and new (or
"new to you") software. Exact mileage varies ...

--
----------------------------------------------------------------------
Sylvain Robitaille (E-Mail Removed)

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

Mike Rivers wrote:

> Ardour started out (at least when I first saw it) as a copy of the
> Mackie HDR24/96. I don't think that anyone at the time ever tested it,
> or even defined it, for 24 channels of simultaneous input and output.
> ...

The author? He wrote it so he could use his RME Digi9652, after all ...

--
----------------------------------------------------------------------
Sylvain Robitaille (E-Mail Removed)

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

Actually, I was very surprised to find the DIY-DJ radio station automation
software is actually becoming very popular. It runs on a Linux platform and
seems relatively stable (compared with the other automation systems anyway).
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Sylvain Robitaille wrote:

> Ok. Ardour's feature list also can hold its own against (some?)
> commercial DAW software. My point was that if you are able to work with
> Brand X DAW software, the skills transfer to Brand Y, and back.

Some do and some don't. What little I've managed to learn about Windows
through about 15 years of fumbling with it absolutely does not transfer to
Linux (and hence Ardour). I don't have another 15 years to learn what I need
to learn in order to be able to understand what I'm told about how to
solve a
problem.

Sure, the basic concepts are similar. The user interfaces are different.
You find
similar names for functions that do different things, you find different
screen
graphics, you can find what you're looking for most of the time but it
might be
under a different menu than you're accustomed to seeing it. If you don't
set aside
one and move to another, you (or at least I) don't learn these things
very well.

> Brand X or Brand Y could be Ardour. What it comes down to, really, is
> whether one package includes some feature(s) that really make a
> difference to how the user works. That's what sets the different
> software apart.

I have features, many many features on my DAW program, that I've never used,
or have used once or twice and forgotten about. I doubt that there's any
feature
that would make or break a decision. After all [the great lie] "This is
software. It
can always be updated" gives us hope. But what can make or break a
program for
me is what limitations it has as far as working with the outside world.
These are
really "functions" rather than "features." And then there are
convenience issues.
For example, I can use some VST plug-ins with Audacity but because they
don't
have the license to suport the GUI they're more difficult to operate
than when I
can see on-screen representation of the device the plug-in emulates.

>> Is Audacity a DAW? To some it is because it does everything they
>> want it to.
>
> Ok. I would have said "no" because it doesn't operate on the audio
> files in the way I think of DAW software operating (non-destructively),

You can make it non-destructive simply by copying what you want to work on
before you mess with it so you can always go back to the original. You may
not have successive un-dos, though I thought that was possible. I never make
mistakes so I don't have to worry about non-destructive operation anyway.

> but ok, if some people want to think of it that way, fine. I think of
> it more as an "editor" which isn't the same at all.

It's also a mixer, though a rather clumsy one.

>> Is ProTools a DAW? Most definitely.
> Sure. Is ProToolsLE?

Why not? What's missing, and do a large number of potential users need
what's missing? Initially, the most significant differences between LE and
RPT (Real Pro Tools) was a smaller maximum number of tracks (which has
expanded) and the lack of time code synchronization. What's the difference
today other than a division between the hardware you could use with it?

>> The thing about Ardour, particularly for a non-Linux user, or a Linux
>> user who is unfamiliar with audio interfacing on the software side, is
>> that it can be difficult to get working, and impossible to get working
>> with certain fairly common and useful interface hardware, simply
>> because nobody has written support for it yet.

> I'd be interested in specific examples, because I haven't run into
> that myself.

The Mackie 1200F. Most multi-channel USB and Firewire interfaces.

> Certainly, though, this leads to another advantage that
> free, open-source software packages such as Ardour can have over
> the commercial proprietary packages: peer support can have a much
> greater depth of coverage, because the people helping are able to
> understand the innards of the software (even if they don't, though,
> they actually have a chance to, and that counts for more than whether
> they take advantage of the opportunity).

The point is that they don't. Most of the Ardour users are more interested
in computing than audio. The hardware manufacturers aren't "open sourcing"
their hardware, either with documentation or the acutual hardware, so the
only time a new device becomes supported is when a Linux computer hobbyist
decides to buy a piece of hardware himself and dammit make it work. Then
they release the driver, and anyone who wants to use that same hardware
becomes a beta tester for a couple of years.

> When someone writes on the
> Ardour website forum with a question, they usually get a response from
> the lead developer.

That might be very helpful for some problem, but not others.

> Do people using commercial DAW software get that
> kind of support?

Not really, but then commercial software isn't usually released in the state
where the best person to help a user in trouble is the lead developer.

>> I've been told that you don't need to know Jack about JACK in order to
>> use Ardour, and I think that's true if you're content to use your PC
>> motherboard's built in audio hardware.

> I don't think it's true even if you do use the onboard hardware. You
> need to at least know enough to configure it. You need to know that
> JACK needs to be running in order for Ardour to work. Do you need to
> understand *how* JACK accomplishes what it does? I don't think so. I
> certainly haven't studied JACK at all.

As I've said, I haven't really had any experience with JACK other than with
the built-in sound hardware on my computer's motherboard because that's
all I had which was supported by Linux. I did manage to get sound out of it
without changing the defaults that it offered, but when I tried to look
deeper
into it, there were some "configuration" things about which I knew nothing.

> Have you tried that? Did you properly research the I/O box (check it
> against the ALSA compatibility list) before purchasing?

I did look through the ALSA list a year ago and didn't see anything that
I'd be inclined to buy for the purpose of experimenting with Ardour. I
might take another look at it one of these days and there may be something
on the list that I could borrow or mooch for the experiment. If I was
enthusiastic
enough about it, I probably could have hauled my Mackie mixer with the
Firewire
I/O into the workshop because I think that's supported.

OK, I just looked
(http://www.alsa-project.org/main/index.php/Matrix:Main) and
Mackie isn't even on the list. The only TASCAM interfaces supported are the
US-122 series. No PreSounus. No M-Audio multi-channel other than the Delta
series. Yeah, I know, I can get one of those for a song on eBay, but
what's the
point? I'm not really going to use it for real work. I have better already.

> For years I used Ardour with a mid-level sound card that is better than
> the onboard audio on the computer I use as an audio workstation, but not
> quite as good as some others. Eventually I upgraded to an RME Digi9652
> that has worked amazingly well for me, though I didn't pay nearly as
> much for it as you seem to suggest above.

My present position is that I don't want to invest new money in a system
that I don't really need and in which I haven't built confidence. I'm
willing
to spend a little time getting to know it, but it has to work first, and do
something beyond be a 2-track recorder/editor, or multi-track DAW one
or two tracks at a time.

> One should research the interface prior to making the purchase, though.
> If the interface you're looking at won't work easily with Linux, perhaps
> another one will?

This is a fundamental problem. The interfaces that I have will work with
practically any Windows XP DAW program. I can use what I have. As long
as the range of supported hardware is so limited, if I was building a new
system from scratch, I suppose I could pick out something that would
work, but in a couple of years when I wanted to expand or upgrade, would
support be there? I have no confidence in that based on the current track
record. Looking of the ALSA list I see brands that are no longer in
existence.
For the most part, this is old junk (today) that either had drivers
written for it
several years ago or that someone had laying around in his junk pile.

Don't get me wrong - RME is not junk. But I could find nothing in the
current
crop of modestly priced USB2 8-channel I/O box that's supported.

> Take the money you save on software, and apply it
> towards better hardware, such as the RME?

I can get Reaper for $60. Can I get a mult-channel RME for that? Of course
not. I could come out ahead if I was contemplating buying a Pro Tools HD
system, but then I wouldn't have the business advantage of having Pro
Tools.

> I can record 16 tracks simultaneously, and
> use 16 simultaneous outputs (the Digi9652 can do more than that, but
> that's all I have converters for). In the interest of full disclosure,
> I've done 8 tracks at once.

I can plug my Mackie 1640 mixer into my laptop PC and record 16 channels
too. But I can't apparently do that with Ardour.

> There's a decent chapter on Ardour in the recently published "Crafting
> Digital Media", by Daniel James on Apress (ISBN13: 978-1-4302-1887-6;
> http://www.apress.com/book/view/1430218878) I've found the book useful
> for other (not necessarily audio-related) software it discusses as well.

Wow! That sounds like a pretty impressive title for Ardour for Dummies.




--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio." - John Watkinson

Sylvain Robitaille wrote:

> Anybody who gave you the impression that a particular distribution was
> critical, or that a specific hardware configuration was a dependancy
> either hasn't used Linux for audio work, or doesn't understand
> enough about the process to be providing that kind of feedback.

Sadly, this is the type of person who tells you that he's been using
Linux for audio work for years and what's the matter with me? They aren't
using Linux for the same kind of audio work as me, and doesn't understand
enough about the process to provide useful feedback.

> What exactly hardware-specific issues are there likely to be with
> "office" type software? (and have you tried OpenOffice.org?)

It doesn't usually get any more difficult than interfacing a printer, and
those are far more standardized and uniform in their operating system
requirements than audio hardware.

> When you buy an interface to work with (insert commercial audio software
> package here), do you buy the interface just hoping that it will work
> with the software you use, or do you evaluate several and find one that
> will work best with that software?

I would buy one that has the features and audio performance that I want,
and assume that it will work with the software. This is a fair assumption
with Windows, and reasonable fair with Mac (though the latest versions
of both aren't supported for some hardware that works with older versions
of the OS. There are some devices which are supported only on one
platform or the other (Metric Halo, for instance, which Hank uses, only
runs
on Macs) and that's about as much research as you need to do.




--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio." - John Watkinson

Mike Rivers wrote:

>> When you buy an interface to work with (insert commercial audio
>> software package here), do you buy the interface just hoping that it
>> will work with the software you use, or do you evaluate several and
>> find one that will work best with that software?
>
> I would buy one that has the features and audio performance that I want,
> and assume that it will work with the software. ...

and that has never let you down?

> This is a fair assumption with Windows, ...

perhaps until you upgrade the OS, that is ...

> ... the latest versions of both aren't supported for some hardware
> that works with older versions of the OS. ...

My point, in part ...

> There are some devices which are supported only on one platform or the
> other ...

So it isn't just Linux?

> ... that's about as much research as you need to do.

Looks to me like you have to do about the same research for any of
the systems we're discussing.

That hardware vendors don't provide software drivers (in any form,
open-source or not) for Linux but they do for Windows and MacOS isn't
Linux's failing. That devices already supported in Linux remain
supported even after the devices are no longer current technology
and are considered "junk" isn't a failing either. I kind of like
knowing that my stuff will keep working after I upgrade the OS,
but maybe that's just me ...

--
----------------------------------------------------------------------
Sylvain Robitaille (E-Mail Removed)

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

"Sylvain Robitaille" wrote ...
> That hardware vendors don't provide software drivers (in any form,
> open-source or not) for Linux but they do for Windows and MacOS isn't
> Linux's failing.

Sure it is. If Linux were more user-friendly for the average
non-geek user, and less balkanized into dozens of flavors,
there would be a larger common customer base and vendors
of hardware and software would see the advantage in supporting
Linux. (Just as most of them see the advantage in supporting
both MSwin and Mac.)

Too bad there isn't a way to leverage the API of the Mac OS
based on their common heritage. But Steve probably wouldn't
like that.

> That devices already supported in Linux remain
> supported even after the devices are no longer current technology
> and are considered "junk" isn't a failing either. I kind of like
> knowing that my stuff will keep working after I upgrade the OS,
> but maybe that's just me ...

Indeed a clear advantage of Linux. That you can keep obsolete
hardware and software running via self-support. (Assuming some
adequate interface information).

On Sun, 24 Jan 2010 13:40:51 -0800, Richard Crowley wrote:

> "Sylvain Robitaille" wrote ...
>> That hardware vendors don't provide software drivers (in any form,
>> open-source or not) for Linux but they do for Windows and MacOS isn't
>> Linux's failing.
>
> Sure it is. If Linux were more user-friendly for the average non-geek
> user, and less balkanized into dozens of flavors, there would be a
> larger common customer base and vendors of hardware and software would
> see the advantage in supporting Linux. (Just as most of them see the
> advantage in supporting both MSwin and Mac.)

I think this situation is getting better, for the Firewire drivers at
least. Here's a quote from the FFADO site:

"Thanks go out to the vendors that provided us with gear to support for
the 2.0 release: Echo Digital Audio, Edirol, Ego Systems Inc, Focusrite,
Mackie and Terratec. Kudos for their early-bird support!

Special thanks also go to BridgeCo and TC Applied for providing us with
their development platforms and for helping with vendor contacts. Their
support makes that FFADO covers the most widely used platforms for
FireWire audio and that we can quickly implement support for new devices."

So it seems that some vendors are providing hardware and documentation.
I'm not entirely sure how this directly benefits them, perhaps they are
just nice.

For the standard ALSA drivers the vendor support generally seems to
concentrate on chipsets for embedded systems, where Linux is quite common.

I think that the variety of distributions confuses many people, who
assume that they all support different hardware. In reality, they are all
very similar at a kernel level (it is Linux after all), and so share much
the same drivers and hardware compatibility.

>
> Too bad there isn't a way to leverage the API of the Mac OS based on
> their common heritage. But Steve probably wouldn't like that.
>
>> That devices already supported in Linux remain supported even after the
>> devices are no longer current technology and are considered "junk"
>> isn't a failing either. I kind of like knowing that my stuff will keep
>> working after I upgrade the OS, but maybe that's just me ...
>
> Indeed a clear advantage of Linux. That you can keep obsolete hardware
> and software running via self-support. (Assuming some adequate interface
> information).

You don't really do any support of your own. The ALSA drivers are a
single project that comes with the kernel, so it's as easy for the
distribution maker to compile the drivers for all the ALSA compatible
soundcards as it is to compile just one.

So, stuff tends to keeps working by default as there is no pressure or
good reason to remove support for older devices.

Sylvain Robitaille wrote:

>> I would buy one that has the features and audio performance that I want,
>> and assume that it will work with the software. ...
>
> and that has never let you down?

"Never" is a pretty strong word.

>> This is a fair assumption with Windows, ...
> perhaps until you upgrade the OS, that is ...

Like, maybe, to Linux????

>> ... the latest versions of both aren't supported for some hardware
>> that works with older versions of the OS. ...
>
> My point, in part ...

In an ideal world, there would be no need to change operating systems.
Unfortunately, these things aren't fully under our control when we buy
computers as appliances. The upside is that they work out of the box.
The downside is that something what's in the box this year isn't what was
in the box last year. Many of the XP and Vista and Win7 and Snow Leopard
incompatbilities aren't a result of people changing operating systems
because they want to, it's because they buy a new computer and it
comes with a new operating system pre-installed. I'll grant you that
this rarely happens with Linux since you have to look pretty hard to
find a computer with a version of Linux pre-installed (though there
seems to be a path in that direction for Netbooks.

> Looks to me like you have to do about the same research for any of
> the systems we're discussing.

Thing is that with Linux, if you're looking for an audio application that,
qualifies as a DAW, you have a pretty small choice. Same with audio
hardware You make the decision that you WANT to run Linux and
then you find hardware that will work with it. I might decide that I WANT
to run Cakewalk or Logic and that determines the operating system
I need to run, which will in turn lead me to hardware.

> That hardware vendors don't provide software drivers (in any form,
> open-source or not) for Linux but they do for Windows and MacOS isn't
> Linux's failing.

Oh, but it very much is. If the vendors thought that there were enough
Linux users who would buy their hardware if there were drivers, (and
enough applications to support those wannabe users) then they
would supply drivers real quick. But there's just nothing that tells them
that money spent on Linux support would ever be recouperated.

> That devices already supported in Linux remain
> supported even after the devices are no longer current technology

Sure, but that doesn't attract any new users to Linux. That club will
survive, but it will never grow much bigger.

> I kind of like
> knowing that my stuff will keep working after I upgrade the OS,

But do you really know that? Have there been no changes to Linux
that have required changes to hardware drivers? Frankly, I would
feel uncomfortable if I had a system with repaceable parts that I
couldn't upgrade because I don't know if anyone will write a driver
for the "new" part.


--
"Today's production equipment is IT based and cannot be operated without
a passing knowledge of computing, although it seems that it can be
operated without a passing knowledge of audio." - John Watkinson