Another Dumb Question for the Linux Heads

[Mike Rivers]

Do any of the current versions, or versions close to
release, support the full capabilities of 64-bit multi-core
processors? The sort of hotrod computers that people are
buying now to run the professional versions of Windows 7 and
which programs such as Sonar take advantage of?


--
"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

[Mr Soul]

On Aug 27, 6:26*am, Mike Rivers > wrote:
> Do any of the current versions, or versions close to
> release, support the full capabilities of 64-bit multi-core
> processors? The sort of hotrod computers that people are
> buying now to run the professional versions of Windows 7 and
> which programs such as Sonar take advantage of?
I believe that Linux supports 64-bit but you may have to run throuh
some Windows emulation mode (like you do on the Mac) and that's not
ideal. Are you completely opposed to getting Win 7? I just put it on
a new DAW and I rather like it. I just started using 64-bit Reaper.

Mike C

[Arny Krueger]

"Mike Rivers" > wrote in message

> Do any of the current versions, or versions close to
> release, support the full capabilities of 64-bit
> multi-core processors? The sort of hotrod computers that
> people are buying now to run the professional versions of
> Windows 7 and which programs such as Sonar take advantage
> of?

Google seems to have answers such as:

http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/69585-should-you-choose-32-bit-64-bit-linux.html

[melkhorn]

On Aug 27, 2:04*pm, Mr Soul > wrote:
> On Aug 27, 6:26*am, Mike Rivers > wrote:> Do any of the current versions, or versions close to
> > release, support the full capabilities of 64-bit multi-core
> > processors? The sort of hotrod computers that people are
> > buying now to run the professional versions of Windows 7 and
> > which programs such as Sonar take advantage of?
>
> I believe that Linux supports 64-bit but you may have to run throuh
> some Windows emulation mode (like you do on the Mac) and that's not
> ideal. *Are you completely opposed to getting Win 7? *I just put it on
> a new DAW and I rather like it. *I just started using 64-bit Reaper.
>
> Mike C

It's not necessary to run through any sort of Windows emulation mode
on either Linux or OSX (Mac) to utilize multi-core or 64-bit processor
capabilities.

Unless you're suggesting actually running Sonar or Reaper in Linux
(which may or may not be possible with WINE, for example), but that
wasn't what the OP was asking.

Further, just to be clear, a 64-bit processor is not necessary to
process 64-bit audio like that found in Sonar and Reaper.

[Mike Rivers]

Mr Soul wrote:

> I believe that Linux supports 64-bit but you may have to run throuh
> some Windows emulation mode (like you do on the Mac) and that's not
> ideal. Are you completely opposed to getting Win 7?

At the moment I'm in no hurry to go with Win7 because I'm
still running my audio applications on a single Pentium 4
under WinXP Pro and I'm happy. I'm really not even
interested in running Linux for my DAW, but I'm trying to
keep up with the state of the art. My question was academic.
If someone were looking for advantages (or disadvantages) of
using Linux, this could be one. For example, in order to get
64-bit CPU support in Windows, you need to buy a premium
version, but since Linux is "free," the cost of a 32-bit and
64-bit operating system is the same. (not counting hair
transplants and blood pressure medicine <g>)

And, yes, I realize that there's a difference between
running a program that performs 64-bit internal arithmetic
and running an operating system that's capable of moving
data around in 64-bit gulps.

Arny, thanks for that link. That answers the question - yes,
Linux comes in both 32-bit and 64-bit versions. And, like
with Windows applications, some are unhappy running on a
64-bit system.



--
"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

[Mr Soul]

> Further, just to be clear, a 64-bit processor is not necessary to
> process 64-bit audio like that found in Sonar and Reaper.
Correct but I am talking about running the 64-bit version of Reaper
which would not work on a 32-bit processor. I assumed Mike was
talking about the 64-bit version of Sonor.

Mike C

[Mr Soul]

> 64-bit operating system is the same. (not counting hair
> transplants and blood pressure medicine <g>)
And you touch on an important issue here. Perhaps everything might
just work on Linux - I really don't know. The problem is most
software manufacturers may not test on Linux and therefore provide no
real support, but usually you can count on Windows.

When I installed the 64-bit Windows 7, everything just worked after I
had installed 32-bit versions of my audio card driver and my other
audio software (which was also 32-bit).

I barely have time to do audio stuff and I surely don't want to be
fiddling around with getting Linux working correctly. I might
consider a dual-boot someday but the OEM Win 7 I put on my machine
cost less than $200 so it was worth it to me.

Mike C

[Scott Dorsey]

Mike Rivers > wrote:
>Do any of the current versions, or versions close to
>release, support the full capabilities of 64-bit multi-core
>processors? The sort of hotrod computers that people are
>buying now to run the professional versions of Windows 7 and
>which programs such as Sonar take advantage of?

Yes, and they have for years. Applications, though, may not.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[melkhorn]

On Aug 27, 12:26*pm, Mike Rivers > wrote:
> Do any of the current versions, or versions close to
> release, support the full capabilities of 64-bit multi-core
> processors? The sort of hotrod computers that people are
> buying now to run the professional versions of Windows 7 and
> which programs such as Sonar take advantage of?
>
> --
> "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


In a word, yes. Most all current Linux distros (including the audio
specific versions like Ubuntu Studio and Fedora/CCRMA) have a version
that supports 64-bit multi-core processors. With some you'll have to
download a specific .iso to burn and boot from, depending on your
architecture, but many now are all-inclusive and will accommodate both
64-bit memory addressing and symmetric multi-processing.

As to whether or not a given application supports either is perhaps
the more important question. Ardour, perhaps the Linux DAW most
similar to your example of Sonar, and its underlying audio server Jack
(as jackdmp), both take advantage of multi-core processors.

With regard to the 64-bit question, I think the general consensus at
this point is that the only real performance gain is with greater than
4 gigs or RAM, but again, Linux can take advantage of that memory when
it's there.

[melkhorn]

On Aug 27, 4:15*pm, melkhorn > wrote:

> With regard to the 64-bit question, I think the general consensus at
> this point is that the only real performance gain is with greater than
> 4 gigs or RAM, but again, Linux can take advantage of that memory when
> it's there.

Sorry! Typo! I meant "4 gigs of RAM."

[Scott Dorsey]

melkhorn > wrote:
>With regard to the 64-bit question, I think the general consensus at
>this point is that the only real performance gain is with greater than
>4 gigs or RAM, but again, Linux can take advantage of that memory when
>it's there.

That is really the case with all x86 systems, be they Linux or Windows.
What you get by going to "64-bit" mode is 64-bit addresses... you don't
get any additional data throughput, really. This may or may not be the
case with other system architectures.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Mike Rivers]

Mr Soul wrote:

> And you touch on an important issue here. Perhaps everything might
> just work on Linux - I really don't know. The problem is most
> software manufacturers may not test on Linux and therefore provide no
> real support, but usually you can count on Windows.

Linux advocates like to think that their software is just as
good as any written for Windows or Mac platforms, and much
of it is. But it really doesn't get broad testing and
support might be the author of the program sending you some
new source code and telling you to compile it and try it.
There's a real positive side to that. But for someone (and
I'm thinking of the musician who needs to record) who isn't
a computer scientist, you can be more productive with
something that, although it may not be exactly what you
dream of, just works out of the box.

And one really important weakness is with support for audio
hardware. Nobody yet prints on their data sheet "Requires
Windows, Mac OS or Linux."

> I barely have time to do audio stuff and I surely don't want to be
> fiddling around with getting Linux working correctly.

My sentiments exactly. But in a better world, Linux would
work as well as Windows on as many different systems as
Windows does, and you could devote more time to recording
your music than building your tools.


--
"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]

melkhorn wrote:

> As to whether or not a given application supports either is perhaps
> the more important question. Ardour, perhaps the Linux DAW most
> similar to your example of Sonar, and its underlying audio server Jack
> (as jackdmp), both take advantage of multi-core processors.

Thanks. That's a good data point. I've played with Ardour
but I didn't look specifically for 64-bit support since I
don't have a 64-bit CPU.



--
"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

[philicorda[_9_]]

On Fri, 27 Aug 2010 06:26:51 -0400, Mike Rivers wrote:

> Do any of the current versions, or versions close to release, support
> the full capabilities of 64-bit multi-core processors? The sort of
> hotrod computers that people are buying now to run the professional
> versions of Windows 7 and which programs such as Sonar take advantage
> of?

Linux supports 64bit. Earlier 64bit processors like Sparc, Alpha and MIPS
R4000 have been around for quite a while. The nice thing is that the
drivers are compiled for 64bit along with the kernel, and so all my more
ancient bits of hardware are still supported.

My Linux computer has all the audio software compiled under a 64bit
environment. There is also a ready made audio distribution called
64Studio.

I'm not sure if it makes any difference or not. I suspect any differences
between Linux and Windows on a new processor would depend much more on
the compiler. Compilers can use auto vectorisation to use the extended
features such as MMX, SSE, 3dNow etc. Programmers can also write this
code by hand, but it's a little obscure.

Most Windows software I believe is compiled with Intel's ICC, and most
Linux software with GCC. ICC generally creates more efficient code than
GCC, but supports only x86 processors. GCC supports many processors, and
is generally little less efficient on x86. Open source programmers tend
to avoid hand writing processor specific optimisations such as AMD's
3dnow, as it's a lot of work and not portable. So unless there is a very
big efficiency gain, it's left up to GCC's auto vectorisation.

[[email protected]]

Mike Rivers writes:

<snip>

>> I barely have time to do audio stuff and I surely don't want to be
>> fiddling around with getting Linux working correctly.
>My sentiments exactly. But in a better world, Linux would
>work as well as Windows on as many different systems as
>Windows does, and you could devote more time to recording
>your music than building your tools.
tHis is true, but if your needs are more suited to
customizing some aspects of the way you must work with your
tools you might have no choice but to build them, then linux
is your answer possibly.
THe only advantage to building your tools if you must is
that once you've got them stable you can just work, fire the
box up and record when you intend to record.

Just as in the days when studio owners built and serviced
their own gear building your tools has some advantages. YOu
*know* a good bit about how they work.

I've gone stand alone for multi tracker for the very reason
that all the file conversion wrestling match stuff can
happen when the chips aren't down and it must happen now,
because of my specific needs. SPeech screen access and a
daw don't coexist well in high track count environments, and
speech screen access doesn't coexist well with location
recording where you want to concentrate the job of the ears
on listening to the audio you're capturing.

TO be honest, I have high hopes for the newer macs with
built-in accessibility. WIth that and a good control
surface I just might be able to migrate over in the next few
years. I've thrown out a couple queries on the net, but no
bounce back yet. wOuld sure be easier to hand the client pt
sessions right at the end of the job if that's what he
needs.
Until then though I"ll be customizing some of my tools, that
means a linux box here at the house to grab hd-24 data,
convert to a standard format anybody can import in their
daw, transfer to usb hd, convey to client.

Fwiw I've had to learn more about this infernal damned
machines than I ever wanted, just because of what I have to
do with the tools to make them usable. Two decades or so
ago when I first sat down at one the old fart blind man just
wanted to be able to type a letter without hiring a
secretary to do a retype, especially true if I had children
underfoot while working.


Regards,




Richard webb,

replace anything before at with elspider
ON site audio in the southland: see www.gatasound.com

[Mike Rivers]

wrote:

> if your needs are more suited to
> customizing some aspects of the way you must work with your
> tools you might have no choice but to build them, then linux
> is your answer possibly.

I really didn't want this to go the route of "why is Linux
better than ...whatever... Sure, there are certain custom
applications that involve audio. I heard about someone who
was using Ardour to control what goes to 125 speakers (but
he didn't say why). But that's science, maybe audio art, or
exhibit design, not multitrack music production. For that,
sure, whatever makes it easier to customize or write
software that suits your needs is a good thing.

> Just as in the days when studio owners built and serviced
> their own gear building your tools has some advantages. YOu
> *know* a good bit about how they work.

But back in that day, you could see what you built (sorry -
figure of speech) and you could troubleshoot any circuit
that was simple enough for you to build and package. You can
diagnose nearly any problem with a voltmeter, a scope, a
generator, and maybe a pair of headphones. But with
software, you can write what you think is good code and you
don't have any idea what the compiler does with it - unless
of course you wrote the compiler too. Somebody has to do that.

> Two decades or so
> ago when I first sat down at one the old fart blind man just
> wanted to be able to type a letter without hiring a
> secretary to do a retype

For someone with that sort of requirement (and today I'd add
surf the web) I wouldn't quibble with anyone who wanted to
set up a Linux system rather than a Mac or Windows.


--
"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

[[email protected]]

Mike Rivers writes:
>> if your needs are more suited to
>> customizing some aspects of the way you must work with your
>> tools you might have no choice but to build them, then linux
>> is your answer possibly.
>I really didn't want this to go the route of "why is Linux
>better than ...whatever... Sure, there are certain custom
>applications that involve audio. I heard about someone who
>was using Ardour to control what goes to 125 speakers (but
>he didn't say why). But that's science, maybe audio art, or
>exhibit design, not multitrack music production. For that,
>sure, whatever makes it easier to customize or write
>software that suits your needs is a good thing.
YEp, in my case the standard user interface of a lot of this
stuff is cumbersome at best, detrimental at worst, see
example previous article on screen access and higher track
counts, even 4 8 16 etc. with gui etc.

>> Just as in the days when studio owners built and serviced
>> their own gear building your tools has some advantages. YOu
>> *know* a good bit about how they work.
>But back in that day, you could see what you built (sorry -
>figure of speech) and you could troubleshoot any circuit
>that was simple enough for you to build and package. You can
>diagnose nearly any problem with a voltmeter, a scope, a
>generator, and maybe a pair of headphones. But with
>software, you can write what you think is good code and you
>don't have any idea what the compiler does with it - unless
>of course you wrote the compiler too. Somebody has to do that.
YEp, which is my problem too. I can build a gimmick to tell
me that this is x volts coming out that end cause it rings
the buzzer, etc. I can troubleshoot analog. DOes what goes
in this end come out at the appropriate level at that end,
etc. Blind electronics techs have been doing that for
decades, until drop in the whole circuit board and replace
it anyway <g>.

>> Two decades or so
>> ago when I first sat down at one the old fart blind man just
>> wanted to be able to type a letter without hiring a
>> secretary to do a retype
>For someone with that sort of requirement (and today I'd add
>surf the web) I wouldn't quibble with anyone who wanted to
>set up a Linux system rather than a Mac or Windows.
YEp, and for moving those hd24 files around it works. AS I
noted, I've got high hopes for pt and the newer macs with
built in screen access, and a decent control surface. But,
so far everybody I talk to who's singing the praises of the
newer mac os with built in accessibility is doing the same
old crap that I wouldn't bother to buy a new mac for, i.e.
the internet, word processing, regular office type chores.
YEs, they're singing the praises of no longer having to sing
the screen access upgrade high dollar blues. A good thing,
if you're in the market for an Ipad or a new machine. But
for those of us who dumpster dive our machines ...





Richard webb,

replace anything before at with elspider
ON site audio in the southland: see www.gatasound.com

[gjsmo]

On Aug 27, 6:26*am, Mike Rivers > wrote:
> Do any of the current versions, or versions close to
> release, support the full capabilities of 64-bit multi-core
> processors? The sort of hotrod computers that people are
> buying now to run the professional versions of Windows 7 and
> which programs such as Sonar take advantage of?
>
> --
> "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

Sure. Get the 64-bit kernel and you're good to go. Even better would
be a distro like 64 Studio, specifically for Audio/Video.
If you really want performance, and you're up to it, build a custom
kernel, and MAKE SURE you use the realtime scheduler. I believe 64
Studio (an misnomer, as it is available as 32 and 64-bit I think) is
by default realtime. I'd have to look to be sure.

However, ANY distro can be 64-bit. If you install a new kernel which
is compiled for 64-bit, it will be (slightly oversimplified).

[Mike Rivers]

gjsmo wrote:

> Sure. Get the 64-bit kernel and you're good to go. Even better would
> be a distro like 64 Studio, specifically for Audio/Video.

> If you really want performance, and you're up to it, build a custom
> kernel, and MAKE SURE you use the realtime scheduler. I believe 64
> Studio (an misnomer, as it is available as 32 and 64-bit I think) is
> by default realtime. I'd have to look to be sure.

This is not something that I would expect that someone who
is primarily a musician or recording engineer would be
expected to know how to do without considerable study. At
the risk of sounding like someone who asks here "Can someone
here send me the schematic for a balanced mic cable?," I
would need a step by step procedure in order to build a
custom kernel. And even if you were nice enough to type it
up for me, what works on your system might not work on my
system because they diverged after about the first five
minutes. <g>

--
"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

[gjsmo]

On Aug 27, 6:14*pm, Mike Rivers > wrote:
> gjsmo wrote:
> > Sure. Get the 64-bit kernel and you're good to go. Even better would
> > be a distro like 64 Studio, specifically for Audio/Video.
> > If you really want performance, and you're up to it, build a custom
> > kernel, and MAKE SURE you use the realtime scheduler. I believe 64
> > Studio (an misnomer, as it is available as 32 and 64-bit I think) is
> > by default realtime. I'd have to look to be sure.
>
> This is not something that I would expect that someone who
> is primarily a musician or recording engineer would be
> expected to know how to do without considerable study. At
> the risk of sounding like someone who asks here "Can someone
> here send me the schematic for a balanced mic cable?," I
> would need a step by step procedure in order to build a
> custom kernel. And even if you were nice enough to type it
> up for me, what works on your system might not work on my
> system because they diverged after about the first five
> minutes. <g>
>
> --
> "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

Not to worry... although like I said, there is sometimes a prebuilt
kernel with real-time capabilities.

Rebuilding the kernel is not entirely necessary if there is a suitable
realtime version available, use it. I'd suggest installing SuSE, as it
is fairly straightforward.
You can install a relatively default configuration, then configure RT
later. Or it may be simpler to install the RT kernel to begin with. If
you can navigate your way through the install program (it's simple
enough), and find the kernels (package names start with kernel),
install the realtime one. You obviously want the 64-bit install CD/
DVD. Go to the bootloader section, and configure that kernel to be the
default startup. You're done.

I could probably send screenshots of a SuSE install, as I'll be doing
one soon enough. If you can put together a patch bay, you can install
Linux.

[Mike Rivers]

gjsmo wrote:

> Not to worry... although like I said, there is sometimes a prebuilt
> kernel with real-time capabilities.

There's a continuing discussion on the Ubuntu Studio forum
about either adding or replacing (not sure which) a real
time kernel because the one in whatever version they're
talking about wasn't very good.

> Rebuilding the kernel is not entirely necessary if there is a suitable
> realtime version available, use it. I'd suggest installing SuSE, as it
> is fairly straightforward.

Yeah, maybe this week, but then someting will get upgraded
and break. If someone really wanted to prove to the audio
community that Linux was ready for prime time, they'd make a
distribution that had a suitable realtime kernel, and a
wider hardware support for both USB and Firewire devices.
And maybe customize Ardour to look more like contemporary
Windows or Mac DAWs (more hardware-looking graphics on the
EQs and dynamics, for example). And then test the heck out
of it, and don''t go "improving" it unless it needs
improvement.

> You can install a relatively default configuration, then configure RT
> later. Or it may be simpler to install the RT kernel to begin with.

Why isn't it just there? Isn't that what a 'distro' is
supposed to be? Everything you need to get going with where
you're going?

> If
> you can navigate your way through the install program (it's simple
> enough), and find the kernels (package names start with kernel),
> install the realtime one.

Maybe "kernel" means something different than it did 40
years ago when I studied this stuff in college. That was an
essential part of the operating system and you don't just
stick another one in there. I'm making an example of myself
here. I really wouldn't have any idea that I needed a real
time kernel (or even that I didn't have one) and where to
look for it and how to install it, particularlly if
installation involved compiling it first. I tried to install
something that, when troubleshooting a more basic problem,
someone said I needed. I couldn't find it in a directly
installable version from the Package Manager so I got the
source code and followed the instructions to compile it,
then install it. First error message I got was that there
didn't seem to be a C++ compiler on this system, and
suggested where to get one. Who knew? I thought every Linux
system had a compiler.

> You obviously want the 64-bit install CD/
> DVD. Go to the bootloader section, and configure that kernel to be the
> default startup. You're done.

You'd have to tell me what to type. I have no idea where the
bootloader section is nor how to configure a default
startup. I'm sure it's a matter of editing a text file, but
which file? A seasoned Linux user would probalby be able to
figure that out pretty easily, not a recording engineer though.

> I could probably send screenshots of a SuSE install, as I'll be doing
> one soon enough. If you can put together a patch bay, you can install
> Linux.

No thanks. I've set it aside for another year. Maybe there
will be a SuSE Studio distribution by then. Maybe you'll be
inspired to assemble one.



--
"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

[gjsmo]

> Yeah, maybe this week, but then someting will get upgraded
> and break. If someone really wanted to prove to the audio
> community that Linux was ready for prime time, they'd make a
> distribution that had a suitable realtime kernel, and a
> wider hardware support for both USB and Firewire devices.
> And maybe customize Ardour to look more like contemporary
> Windows or Mac DAWs (more hardware-looking graphics on the
> EQs and dynamics, for example). And then test the heck out
> of it, and don''t go "improving" it unless it needs
> improvement.
>
> > You can install a relatively default configuration, then configure RT
> > later. Or it may be simpler to install the RT kernel to begin with.
>
> Why isn't it just there? Isn't that what a 'distro' is
> supposed to be? Everything you need to get going with where
> you're going?
>
> > If
> > you can navigate your way through the install program (it's simple
> > enough), and find the kernels (package names start with kernel),
> > install the realtime one.
>
> Maybe "kernel" means something different than it did 40
> years ago when I studied this stuff in college. That was an
> essential part of the operating system and you don't just
> stick another one in there. I'm making an example of myself
> here. I really wouldn't have any idea that I needed a real
> time kernel (or even that I didn't have one) and where to
> look for it and how to install it, particularlly if
> installation involved compiling it first. I tried to install
> something that, when troubleshooting a more basic problem,
> someone said I needed. I couldn't find it in a directly
> installable version from the Package Manager so I got the
> source code and followed the instructions to compile it,
> then install it. First error message I got was that there
> didn't seem to be a C++ compiler on this system, and
> suggested where to get one. Who knew? *I thought every Linux
> system had a compiler.
>
> > You obviously want the 64-bit install CD/
> > DVD. Go to the bootloader section, and configure that kernel to be the
> > default startup. You're done.
>
> You'd have to tell me what to type. I have no idea where the
> bootloader section is nor how to configure a default
> startup. I'm sure it's a matter of editing a text file, but
> which file? A seasoned Linux user would probalby be able to
> figure that out pretty easily, not a recording engineer though.
>
> > I could probably send screenshots of a SuSE install, as I'll be doing
> > one soon enough. If you can put together a patch bay, you can install
> > Linux.
>

>
> --
> "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



> There's a continuing discussion on the Ubuntu Studio forum
> about either adding or replacing (not sure which) a real
> time kernel because the one in whatever version they're
> talking about wasn't very good.

Dunno about Ubuntu studio. 64 Studio is a different distro.

> Yeah, maybe this week, but then someting will get upgraded
> and break. If someone really wanted to prove to the audio
> community that Linux was ready for prime time, they'd make a
> distribution that had a suitable realtime kernel, and a
> wider hardware support for both USB and Firewire devices.
> And maybe customize Ardour to look more like contemporary
> Windows or Mac DAWs (more hardware-looking graphics on the
> EQs and dynamics, for example). And then test the heck out
> of it, and don''t go "improving" it unless it needs
> improvement.

Well... then don't upgrade it. Didn't have a problem before I knew a
lot about Linux, and I still don't. Sort of like a Mac - once it's
running, it stays running.
There is a suitable realtime kernel, though it's not ALWAYS included
by default. There are reasons not to use it.
USB/Firewire support is becoming VERY good.
Learning Ardour should be like learning The GIMP after you know
Photoshop. It's like a wood shop, with the tools in different places.
You'll get used to it.
Community is the testbed. Find a bug, report it. Repeat.

> Why isn't it just there? Isn't that what a 'distro' is
> supposed to be? Everything you need to get going with where
> you're going?

Well... yeah. But do you really expect every distro to contain every
package out there?

> Maybe "kernel" means something different than it did 40
> years ago when I studied this stuff in college. That was an
> essential part of the operating system and you don't just
> stick another one in there.

No, it means the same thing. But when you upgrade/recompile/replace
your kernel, they're the same kernel, but certain features are
implemented differently.
The RT kernel makes absolutely certain things happen with a minimum
delay. You need that for audio.

> I'm making an example of myself
> here. I really wouldn't have any idea that I needed a real
> time kernel (or even that I didn't have one) and where to
> look for it and how to install it, particularlly if
> installation involved compiling it first. I tried to install
> something that, when troubleshooting a more basic problem,
> someone said I needed. I couldn't find it in a directly
> installable version from the Package Manager so I got the
> source code and followed the instructions to compile it,
> then install it. First error message I got was that there
> didn't seem to be a C++ compiler on this system, and
> suggested where to get one. Who knew? I thought every Linux
> system had a compiler.

This is the kind of thing that tends to set people away from Linux. If
you have a local LUG, go to it. You might not understand it, but start
asking questions and explain your situation - they'll understand.

> You'd have to tell me what to type. I have no idea where the
> bootloader section is nor how to configure a default
> startup. I'm sure it's a matter of editing a text file, but
> which file? A seasoned Linux user would probalby be able to
> figure that out pretty easily, not a recording engineer though.

Not to make it sound TOO easy... but the installation for SuSE is a
GUI. Unless you specifically say otherwise, then it's a text-based
GUI. Hard to beat.
I fully understand the resistance (maybe I'm trying to be too
helpful), but nowadays it really is easy.
If you did try installing SuSE... this would actually be REALLY
intuitive. I did it on my first try.

> No thanks. I've set it aside for another year. Maybe there
> will be a SuSE Studio distribution by then. Maybe you'll be
> inspired to assemble one.

Not a bad idea. Would you at least consider trying it in a virtual
machine?

[Mike Rivers]

gjsmo wrote:

> Well... then don't upgrade it. Didn't have a problem before I knew a
> lot about Linux, and I still don't. Sort of like a Mac - once it's
> running, it stays running.

"Running" is relative, as is "upgrade." I could probably
live with what gets installed if all I wanted to do was
browse the web and write in a word processor and never have
to change anything. But I never got Linux to work with any
audio hardware I had that would offer the same capabilities
that I have with Windows.

> There is a suitable realtime kernel, though it's not ALWAYS included
> by default. There are reasons not to use it.
> USB/Firewire support is becoming VERY good.

Sure, if you're happy with a short list of devices. The
problem is that when new devices come on the market, they
don't come with Linux drivers (as they do with Windows
drivers) and you either have to have the experience to
develop one yourself or wait for one of the communal
developers to do it.

> Learning Ardour should be like learning The GIMP after you know
> Photoshop. It's like a wood shop, with the tools in different places.

Sure, but sometimes you need to go out and get new tools
that aren't in this shop that you had in the other shop.
It's rumored that, for example, Waves plug-ins will run
under Wine (I don't have any to try). For the professional
engineer, what's available under LADSPA and LV2 doesn't cut
it, particularly when you have clients who expect specific
plug-ins (like they expect Pro Tools - which I've never head
anyone mention running under Linux). I know that it used to
be that you could compile Ardour to support VST plug-ins. I
don't know (nor do I know how to find out) whether the
current versions that come pre-compiled are available like
that. This may not be a big deal to someone who eats Linxu
for breakfast, but it is for your typical audio engineer.

>> Why isn't it just there? Isn't that what a 'distro' is
>> supposed to be? Everything you need to get going with where
>> you're going?
>
> Well... yeah. But do you really expect every distro to contain every
> package out there?

No, but it would be nice if there was one that was designed
with the guidance of an experienced audio engineer who has
used other programs and knows what functions are important
and the kind of user interface that makes sense to a user of
audio applications. For example, the version of Ardour
supplied should have VST support built in without requiring
the user to compile a new version. There's no disadvantage
to this. Why not include it? Same for FFADO and JACK. And if
a real time kernel is required, why not include it? What
would it hurt?

And how about support for more than two or three
multi-channel I/O boxes? And how about support for the DSP
mixers that're built into many of them? I know what it would
take. It would take either for the hardware manufacturers to
supply their own drivers for Linux like they do for Windows.
But there's no evidence that there are enough Linux users
who would buy their products to pay for the effort.

>> Maybe "kernel" means something different than it did 40
>> years ago when I studied this stuff in college.

> No, it means the same thing. But when you upgrade/recompile/replace
> your kernel, they're the same kernel, but certain features are
> implemented differently.
> The RT kernel makes absolutely certain things happen with a minimum
> delay. You need that for audio.

OK, then it should be a part of any distribution that is
targeted to audio users.

> This is the kind of thing that tends to set people away from Linux. If
> you have a local LUG, go to it. You might not understand it, but start
> asking questions and explain your situation - they'll understand.

But you see, this is a 25 year setback. Back then I would
occasionally go to a local DOS user's group because there
was a lot to learn that was necessary to do what i wanted to
do with a computer back then. But in the last 15 years, when
I installed a Windows system, it just worked and I didn't
have to re-compile anything, edit a config.sys file, or
write batch files. This is what "we" expect from a computer
today, not a do-it-yourself project. The collective "we"
wants to be able to use off-the-shelf software that works
with our off-the-shelf operating systems. In order to go
back to the DIY days, there has to be a better reason than
that the software is free and can be modified at will. It
hasn't always been so, but today there's plenty of good
audio software off the shelf. And some of it is even free.

> If you did try installing SuSE... this would actually be REALLY
> intuitive. I did it on my first try.

I installed Ubuntu on my first try, too. I could even figure
out how to get around in it. But it was when I actually
started trying to do what I could do with my other computers
that I ran into trouble.




--
"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

[gjsmo]

> "Running" is relative, as is "upgrade." I could probably
> live with what gets installed if all I wanted to do was
> browse the web and write in a word processor and never have
> to change anything. But I never got Linux to work with any
> audio hardware I had that would offer the same capabilities
> that I have with Windows.

I can't honestly respond to this, as I have no pro audio gear.

> Sure, if you're happy with a short list of devices. The
> problem is that when new devices come on the market, they
> don't come with Linux drivers (as they do with Windows
> drivers) and you either have to have the experience to
> develop one yourself or wait for one of the communal
> developers to do it.

Seems like a lot of things are supported. Ethernet and printer support
is ubiquitous, wifi has improved dramatically and I tend to install
less drivers than I would with Windows. Maybe it's just the type of
equipment I'm using, but I've ALWAYS had good support for my stuff,
and it's only getting better.

> Sure, but sometimes you need to go out and get new tools
> that aren't in this shop that you had in the other shop.
> It's rumored that, for example, Waves plug-ins will run
> under Wine (I don't have any to try). For the professional
> engineer, what's available under LADSPA and LV2 doesn't cut
> it, particularly when you have clients who expect specific
> plug-ins (like they expect Pro Tools - which I've never head
> anyone mention running under Linux). *I know that it used to
> be that you could compile Ardour to support VST plug-ins. I
> don't know (nor do I know how to find out) whether the
> current versions that come pre-compiled are available like
> that. This may not be a big deal to someone who eats Linxu
> for breakfast, but it is for your typical audio engineer.

Just out of curiosity, what did you do before the plugins existed? Did
you have a substitute, or did you make do without them? I realize they
make life easier... but how much easier?

> No, but it would be nice if there was one that was designed
> with the guidance of an experienced audio engineer who has
> used other programs and knows what functions are important
> and the kind of user interface that makes sense to a user of
> audio applications. For example, the version of Ardour
> supplied should have VST support built in without requiring
> the user to compile a new version. There's no disadvantage
> to this. Why not include it? Same for FFADO and JACK. And if
> a real time kernel is required, why not include it? What
> would it hurt?

Nothing. Lots of distributions have the RT kernel as a package - but
not every single one. Pick a major one (or an AV-specific one), it'll
have an RT kernel. Simple as that.

> And how about support for more than two or three
> multi-channel I/O boxes? And how about support for the DSP
> mixers that're built into many of them? I know what it would
> take. It would take either for the hardware manufacturers to
> supply their own drivers for Linux like they do for Windows.
> But there's no evidence that there are enough Linux users
> who would buy their products to pay for the effort.

Like I said, I have no pro audio equipment, so I don't have an opinion
there.

> OK, then it should be a part of any distribution that is
> targeted to audio users.

It is.

> > This is the kind of thing that tends to set people away from Linux. If
> > you have a local LUG, go to it. You might not understand it, but start
> > asking questions and explain your situation - they'll understand.
>
> But you see, this is a 25 year setback. Back then I would
> occasionally go to a local DOS user's group because there
> was a lot to learn that was necessary to do what i wanted to
> do with a computer back then. But in the last 15 years, when
> I installed a Windows system, it just worked and I didn't
> have to re-compile anything, edit a config.sys file, or
> write batch files. This is what "we" expect from a computer
> today, not a do-it-yourself project. The collective "we"
> wants to be able to use off-the-shelf software that works
> with our off-the-shelf operating systems. In order to go
> back to the DIY days, there has to be a better reason than
> that the software is free and can be modified at will. It
> hasn't always been so, but today there's plenty of good
> audio software off the shelf. And some of it is even free.

I agree there has to be a better reason - though free is hard to beat.
The main reason for me is that I'm not locked into anything
proprietary, I don't have the security and stability issues of
Windows, and Linux is FAR more customizable.

> I installed Ubuntu on my first try, too. I could even figure
> out how to get around in it. *But it was when I actually
> started trying to do what I could do with my other computers
> that I ran into trouble.

Any specific reason that you needed Linux, then? If your other
computers fit your needs, then you don't need to switch.

Of course, I always tell people why Windows has 95% market share. It's
because IBM bundled DOS (which Microsoft bought, not wrote originally)
with the PC, then kept putting Windows with their PCs. DOS/Windows was
the only choice... so people went with it. Also, Linux can't be a
closed-source product since it's under the GPL.

If you don't use Linux that's fine. It's always available, though, and
it's getting better every day.

[Mike Rivers]

gjsmo wrote:

> I can't honestly respond to this, as I have no pro audio gear.

Nothing personal intended here, but this is another example
of "my Linux problem." The advice that I receive about
things that would make my life easier nearly all comes from
people who are not using professional audio applications or
hardware. I know they're out there, but I suspect that those
who are getting a lot of mileage out of a Linux audio
production system who didn't first have a computer
technology background have had the assistance of someone who
does. I don't mean to state categorically that Linux isn't
suitable for professional audio work, just that there's a
much longer path from inception to productivity with Linux
than with the more do-it-yourself oriented "kits" that are
based on Windows or Mac OS platforms.

> Seems like a lot of things are supported. Ethernet and printer support
> is ubiquitous, wifi has improved dramatically and I tend to install
> less drivers than I would with Windows.

Funny that you mention WiFi. Last week I picked up a $15 USB
WiFi adapter to see if it would work in my TiVo to replace
the Ethernet cable I need to string down the hall when I
want to allow it to phone home (I use it just as a recorder,
I'm not a subscriber). The TiVo told me that this WiFi
adapter was unsupported. So before returning it, I plugged
it into the Linux computer to see if it would be
automagically recognized. It wasn't.

Last night I was having dinner with my Unix-head friend and
mentioned it. He went to his keyboard, did an on-line
search, came up with a web page with Linux support for USB
WiFi devices. (tom-cat or something like that?) Then he
started describing what I would have to do. It started with
compiling a test program to identify the chipset in the
device. Then, I could compile the driver using the option to
support that chipset, or all known chipsets if I prefer, or
if I wanted to take a chance that an unknown chipset would
be supported anyway.

The Windows CD installs a Windows driver that unquestionably
supports that device. In my friend's computer scientist
mode, he prefers making a driver that he knows about what
goes into it. From my user perspective, I'd much rather
click on a SETUP file supplied by the hardware manufacturer
and get exactly what will work (which, at least these days,
it does, nearly all the time). But of course they don't have
a SETUP (or equivalent) for Linux, as is the case with audio
I/O hardware.

> Just out of curiosity, what did you do before the plugins existed? Did
> you have a substitute, or did you make do without them? I realize they
> make life easier... but how much easier?

Oh, I hardly ever use software plug-ins. I use real hardware
with analog inputs and ouitputs, and a patchbay with real
jacks and patch cables which I can plug in. But I'm not
looking just for myself. Heck, I pretty much only use
computers only for editing. But I'm looking out for my
fellowmen here. Software plug-ins are a way of life. In
fact, these days a multi-channel audio I/O box isn't just
used to record the whole band playing together with multiple
mics, it's used to create "hardware plug-ins" that configure
an in/out pair so that it can be inserted on a track just
like a software plug-in, and send the audio out to an
external processor and back into the computer.

> Lots of distributions have the RT kernel as a package - but
> not every single one. Pick a major one (or an AV-specific one), it'll
> have an RT kernel. Simple as that.

It turned out, when sent off to look for it, that the Ubuntu
Studio distribution that I had installed had a RT kernel,
and in fact, it even had what seemed to be considered the
right one to have. But there were a lot of diversions, that
this RT kernel didn't work with that Firewire stack, and (at
some unclear date) a new Firewire stack would be released
that would solve all problems. The information is out there,
but it's not easy to sort out. Eventually I decided that my
problems weren't with the RT kernel, but at that point,
nobody really had any good solutions for getting my 1200F
interface working. In the FFADO forum, the first comment in
the 1200F section was an announcement in 2007 that it might
work. My comment yesterday is the second one. So I don't
exepct a lot of support or encouragement.

> I agree there has to be a better reason - though free is hard to beat.
> The main reason for me is that I'm not locked into anything
> proprietary, I don't have the security and stability issues of
> Windows, and Linux is FAR more customizable.

If I was more able, or more interested in customizing things
in any way I could imagine, I would indeed look for a system
that allows me to do that. But I don't mind being somewhat
restricted because I'm able to find what I need, that works
reliablly, and has a usually good single source of support
and current knowledge. And what's "locked in" anyway? If I
have Windows, I can (and do) run software from Cakewalk,
Steinberg, Sony and a lot of free or cheapware, and use
audio hardware from Mackie, Behringer, PreSonus, Allen &
Heath, M-Audio.

And, truth be told, I've never directly purchased a copy of
Windows - it's come pre-installed on all of the computers
I've purchased. I would, of course, have to purchase a copy
of Windows (or bootleg one of my existing copies) if I was
building a computer from scratch, but since my computer
needs are fairly modest, I've always found that when it's
time to upgrade, I can do better with a last-year's model
off the shelf than deciding what parts I want, figuring out
what will work together, ordering them, usually on line,
assembling them, and then start with the software build-up.
Some people get off on that. Some feel that it's the only
way to go. I just want to get something working as quickly
as possible and get back to work.

> Any specific reason that you needed Linux, then? If your other
> computers fit your needs, then you don't need to switch.

Absolutely none. I wanted to find out what a user who might
be considering Linux for the reasons you mentioned, and who
didn't have a computer science background or orientation
would encounter. My conclusion was that switching to, or
building an initial system under Linux was probably not a
very sensible thing to do. But the question comes up every
couple of years, so every couple of years I stick a toe in
the water and see if it's warmed up enough to go in.



--
"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

[gjsmo]

> Absolutely none. I wanted to find out what a user who might
> be considering Linux for the reasons you mentioned, and who
> didn't have a computer science background or orientation
> would encounter. My conclusion was that switching to, or
> building an initial system under Linux was probably not a
> very sensible thing to do. But the question comes up every
> couple of years, so every couple of years I stick a toe in
> the water and see if it's warmed up enough to go in.

Good point. Keep it in mind, though - I have never encountered a
problem that I couldn't eventually work out. And I started out with no
knowledge of Linux whatsoever.

Take into consideration the LUG - I know they'll be helpful (unless
you somehow run into a group made of jerks).

[Scott Dorsey]

Mike Rivers > wrote:
>
>But you see, this is a 25 year setback. Back then I would
>occasionally go to a local DOS user's group because there
>was a lot to learn that was necessary to do what i wanted to
>do with a computer back then. But in the last 15 years, when
>I installed a Windows system, it just worked and I didn't
>have to re-compile anything, edit a config.sys file, or
>write batch files. This is what "we" expect from a computer
>today, not a do-it-yourself project. The collective "we"
>wants to be able to use off-the-shelf software that works
>with our off-the-shelf operating systems. In order to go
>back to the DIY days, there has to be a better reason than
>that the software is free and can be modified at will. It
>hasn't always been so, but today there's plenty of good
>audio software off the shelf. And some of it is even free.

Clearly you've had much better luck with Windows than I have then.

At least with Linux you can look inside and see what is failing when
things don't work, rather than just flail around trying different things
at random as seems standard for Windows diagnosis.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Tachin]

On Aug 29, 5:21*am, gjsmo > wrote:
> > Yeah, maybe this week, but then someting will get upgraded
> > and break. If someone really wanted to prove to the audio
> > community that Linux was ready for prime time, they'd make a
> > distribution that had a suitable realtime kernel, and a
> > wider hardware support for both USB and Firewire devices.
> > And maybe customize Ardour to look more like contemporary
> > Windows or Mac DAWs (more hardware-looking graphics on the
> > EQs and dynamics, for example). And then test the heck out
> > of it, and don''t go "improving" it unless it needs
> > improvement.
>
> > > You can install a relatively default configuration, then configure RT
> > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > Why isn't it just there? Isn't that what a 'distro' is
> > supposed to be? Everything you need to get going with where
> > you're going?
>
> > > If
> > > you can navigate your way through the install program (it's simple
> > > enough), and find the kernels (package names start with kernel),
> > > install the realtime one.
>
> > Maybe "kernel" means something different than it did 40
> > years ago when I studied this stuff in college. That was an
> > essential part of the operating system and you don't just
> > stick another one in there. I'm making an example of myself
> > here. I really wouldn't have any idea that I needed a real
> > time kernel (or even that I didn't have one) and where to
> > look for it and how to install it, particularlly if
> > installation involved compiling it first. I tried to install
> > something that, when troubleshooting a more basic problem,
> > someone said I needed. I couldn't find it in a directly
> > installable version from the Package Manager so I got the
> > source code and followed the instructions to compile it,
> > then install it. First error message I got was that there
> > didn't seem to be a C++ compiler on this system, and
> > suggested where to get one. Who knew? *I thought every Linux
> > system had a compiler.
>
> > > You obviously want the 64-bit install CD/
> > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > default startup. You're done.
>
> > You'd have to tell me what to type. I have no idea where the
> > bootloader section is nor how to configure a default
> > startup. I'm sure it's a matter of editing a text file, but
> > which file? A seasoned Linux user would probalby be able to
> > figure that out pretty easily, not a recording engineer though.
>
> > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > one soon enough. If you can put together a patch bay, you can install
> > > Linux.
>
> > --
> > "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
> > There's a continuing discussion on the Ubuntu Studio forum
> > about either adding or replacing (not sure which) a real
> > time kernel because the one in whatever version they're
> > talking about wasn't very good.
>
> Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > Yeah, maybe this week, but then someting will get upgraded
> > and break. If someone really wanted to prove to the audio
> > community that Linux was ready for prime time, they'd make a
> > distribution that had a suitable realtime kernel, and a
> > wider hardware support for both USB and Firewire devices.
> > And maybe customize Ardour to look more like contemporary
> > Windows or Mac DAWs (more hardware-looking graphics on the
> > EQs and dynamics, for example). And then test the heck out
> > of it, and don''t go "improving" it unless it needs
> > improvement.
>
> Well... then don't upgrade it. Didn't have a problem before I knew a
> lot about Linux, and I still don't. Sort of like a Mac - once it's
> running, it stays running.
> There is a suitable realtime kernel, though it's not ALWAYS included
> by default. There are reasons not to use it.
> USB/Firewire support is becoming VERY good.
> Learning Ardour should be like learning The GIMP after you know
> Photoshop. It's like a wood shop, with the tools in different places.
> You'll get used to it.
> Community is the testbed. Find a bug, report it. Repeat.
>
> > Why isn't it just there? Isn't that what a 'distro' is
> > supposed to be? Everything you need to get going with where
> > you're going?
>
> Well... yeah. But do you really expect every distro to contain every
> package out there?
>
> > Maybe "kernel" means something different than it did 40
> > years ago when I studied this stuff in college. That was an
> > essential part of the operating system and you don't just
> > stick another one in there.
>
> No, it means the same thing. But when you upgrade/recompile/replace
> your kernel, they're the same kernel, but certain features are
> implemented differently.
> The RT kernel makes absolutely certain things happen with a minimum
> delay. You need that for audio.
>
> > I'm making an example of myself
> > here. I really wouldn't have any idea that I needed a real
> > time kernel (or even that I didn't have one) and where to
> > look for it and how to install it, particularlly if
> > installation involved compiling it first. I tried to install
> > something that, when troubleshooting a more basic problem,
> > someone said I needed. I couldn't find it in a directly
> > installable version from the Package Manager so I got the
> > source code and followed the instructions to compile it,
> > then install it. First error message I got was that there
> > didn't seem to be a C++ compiler on this system, and
> > suggested where to get one. Who knew? *I thought every Linux
> > system had a compiler.
>
> This is the kind of thing that tends to set people away from Linux. If
> you have a local LUG, go to it. You might not understand it, but start
> asking questions and explain your situation - they'll understand.
>
> > You'd have to tell me what to type. I have no idea where the
> > bootloader section is nor how to configure a default
> > startup. I'm sure it's a matter of editing a text file, but
> > which file? A seasoned Linux user would probalby be able to
> > figure that out pretty easily, not a recording engineer though.
>
> Not to make it sound TOO easy... but the installation for SuSE is a
> GUI. Unless you specifically say otherwise, then it's a text-based
> GUI. Hard to beat.
> I fully understand the resistance (maybe I'm trying to be too
> helpful), but nowadays it really is easy.
> If you did try installing SuSE... this would actually be REALLY
> intuitive. I did it on my first try.
>
> > No thanks. I've set it aside for another year. Maybe there
> > will be a SuSE Studio distribution by then. Maybe you'll be
> > inspired to assemble one.
>
> Not a bad idea. Would you at least consider trying it in a virtual
> machine?- Hide quoted text -
>
> - Show quoted text -

I think you are making it sound TOO easy.

[Tachin]

On Aug 29, 5:21*am, gjsmo > wrote:
> > Yeah, maybe this week, but then someting will get upgraded
> > and break. If someone really wanted to prove to the audio
> > community that Linux was ready for prime time, they'd make a
> > distribution that had a suitable realtime kernel, and a
> > wider hardware support for both USB and Firewire devices.
> > And maybe customize Ardour to look more like contemporary
> > Windows or Mac DAWs (more hardware-looking graphics on the
> > EQs and dynamics, for example). And then test the heck out
> > of it, and don''t go "improving" it unless it needs
> > improvement.
>
> > > You can install a relatively default configuration, then configure RT
> > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > Why isn't it just there? Isn't that what a 'distro' is
> > supposed to be? Everything you need to get going with where
> > you're going?
>
> > > If
> > > you can navigate your way through the install program (it's simple
> > > enough), and find the kernels (package names start with kernel),
> > > install the realtime one.
>
> > Maybe "kernel" means something different than it did 40
> > years ago when I studied this stuff in college. That was an
> > essential part of the operating system and you don't just
> > stick another one in there. I'm making an example of myself
> > here. I really wouldn't have any idea that I needed a real
> > time kernel (or even that I didn't have one) and where to
> > look for it and how to install it, particularlly if
> > installation involved compiling it first. I tried to install
> > something that, when troubleshooting a more basic problem,
> > someone said I needed. I couldn't find it in a directly
> > installable version from the Package Manager so I got the
> > source code and followed the instructions to compile it,
> > then install it. First error message I got was that there
> > didn't seem to be a C++ compiler on this system, and
> > suggested where to get one. Who knew? *I thought every Linux
> > system had a compiler.
>
> > > You obviously want the 64-bit install CD/
> > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > default startup. You're done.
>
> > You'd have to tell me what to type. I have no idea where the
> > bootloader section is nor how to configure a default
> > startup. I'm sure it's a matter of editing a text file, but
> > which file? A seasoned Linux user would probalby be able to
> > figure that out pretty easily, not a recording engineer though.
>
> > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > one soon enough. If you can put together a patch bay, you can install
> > > Linux.
>
> > --
> > "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
> > There's a continuing discussion on the Ubuntu Studio forum
> > about either adding or replacing (not sure which) a real
> > time kernel because the one in whatever version they're
> > talking about wasn't very good.
>
> Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > Yeah, maybe this week, but then someting will get upgraded
> > and break. If someone really wanted to prove to the audio
> > community that Linux was ready for prime time, they'd make a
> > distribution that had a suitable realtime kernel, and a
> > wider hardware support for both USB and Firewire devices.
> > And maybe customize Ardour to look more like contemporary
> > Windows or Mac DAWs (more hardware-looking graphics on the
> > EQs and dynamics, for example). And then test the heck out
> > of it, and don''t go "improving" it unless it needs
> > improvement.
>
> Well... then don't upgrade it. Didn't have a problem before I knew a
> lot about Linux, and I still don't. Sort of like a Mac - once it's
> running, it stays running.
> There is a suitable realtime kernel, though it's not ALWAYS included
> by default. There are reasons not to use it.
> USB/Firewire support is becoming VERY good.
> Learning Ardour should be like learning The GIMP after you know
> Photoshop. It's like a wood shop, with the tools in different places.
> You'll get used to it.
> Community is the testbed. Find a bug, report it. Repeat.
>
> > Why isn't it just there? Isn't that what a 'distro' is
> > supposed to be? Everything you need to get going with where
> > you're going?
>
> Well... yeah. But do you really expect every distro to contain every
> package out there?
>
> > Maybe "kernel" means something different than it did 40
> > years ago when I studied this stuff in college. That was an
> > essential part of the operating system and you don't just
> > stick another one in there.
>
> No, it means the same thing. But when you upgrade/recompile/replace
> your kernel, they're the same kernel, but certain features are
> implemented differently.
> The RT kernel makes absolutely certain things happen with a minimum
> delay. You need that for audio.
>
> > I'm making an example of myself
> > here. I really wouldn't have any idea that I needed a real
> > time kernel (or even that I didn't have one) and where to
> > look for it and how to install it, particularlly if
> > installation involved compiling it first. I tried to install
> > something that, when troubleshooting a more basic problem,
> > someone said I needed. I couldn't find it in a directly
> > installable version from the Package Manager so I got the
> > source code and followed the instructions to compile it,
> > then install it. First error message I got was that there
> > didn't seem to be a C++ compiler on this system, and
> > suggested where to get one. Who knew? *I thought every Linux
> > system had a compiler.
>
> This is the kind of thing that tends to set people away from Linux. If
> you have a local LUG, go to it. You might not understand it, but start
> asking questions and explain your situation - they'll understand.
>
> > You'd have to tell me what to type. I have no idea where the
> > bootloader section is nor how to configure a default
> > startup. I'm sure it's a matter of editing a text file, but
> > which file? A seasoned Linux user would probalby be able to
> > figure that out pretty easily, not a recording engineer though.
>
> Not to make it sound TOO easy... but the installation for SuSE is a
> GUI. Unless you specifically say otherwise, then it's a text-based
> GUI. Hard to beat.
> I fully understand the resistance (maybe I'm trying to be too
> helpful), but nowadays it really is easy.
> If you did try installing SuSE... this would actually be REALLY
> intuitive. I did it on my first try.
>
> > No thanks. I've set it aside for another year. Maybe there
> > will be a SuSE Studio distribution by then. Maybe you'll be
> > inspired to assemble one.
>
> Not a bad idea. Would you at least consider trying it in a virtual
> machine?- Hide quoted text -
>
> - Show quoted text -

I think you are making it sound TOO easy.

[gjsmo]

On Aug 30, 5:48*pm, Tachin > wrote:
> On Aug 29, 5:21*am, gjsmo > wrote:
>
>
>
> > > Yeah, maybe this week, but then someting will get upgraded
> > > and break. If someone really wanted to prove to the audio
> > > community that Linux was ready for prime time, they'd make a
> > > distribution that had a suitable realtime kernel, and a
> > > wider hardware support for both USB and Firewire devices.
> > > And maybe customize Ardour to look more like contemporary
> > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > EQs and dynamics, for example). And then test the heck out
> > > of it, and don''t go "improving" it unless it needs
> > > improvement.
>
> > > > You can install a relatively default configuration, then configure RT
> > > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > > Why isn't it just there? Isn't that what a 'distro' is
> > > supposed to be? Everything you need to get going with where
> > > you're going?
>
> > > > If
> > > > you can navigate your way through the install program (it's simple
> > > > enough), and find the kernels (package names start with kernel),
> > > > install the realtime one.
>
> > > Maybe "kernel" means something different than it did 40
> > > years ago when I studied this stuff in college. That was an
> > > essential part of the operating system and you don't just
> > > stick another one in there. I'm making an example of myself
> > > here. I really wouldn't have any idea that I needed a real
> > > time kernel (or even that I didn't have one) and where to
> > > look for it and how to install it, particularlly if
> > > installation involved compiling it first. I tried to install
> > > something that, when troubleshooting a more basic problem,
> > > someone said I needed. I couldn't find it in a directly
> > > installable version from the Package Manager so I got the
> > > source code and followed the instructions to compile it,
> > > then install it. First error message I got was that there
> > > didn't seem to be a C++ compiler on this system, and
> > > suggested where to get one. Who knew? *I thought every Linux
> > > system had a compiler.
>
> > > > You obviously want the 64-bit install CD/
> > > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > > default startup. You're done.
>
> > > You'd have to tell me what to type. I have no idea where the
> > > bootloader section is nor how to configure a default
> > > startup. I'm sure it's a matter of editing a text file, but
> > > which file? A seasoned Linux user would probalby be able to
> > > figure that out pretty easily, not a recording engineer though.
>
> > > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > > one soon enough. If you can put together a patch bay, you can install
> > > > Linux.
>
> > > --
> > > "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
> > > There's a continuing discussion on the Ubuntu Studio forum
> > > about either adding or replacing (not sure which) a real
> > > time kernel because the one in whatever version they're
> > > talking about wasn't very good.
>
> > Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > > Yeah, maybe this week, but then someting will get upgraded
> > > and break. If someone really wanted to prove to the audio
> > > community that Linux was ready for prime time, they'd make a
> > > distribution that had a suitable realtime kernel, and a
> > > wider hardware support for both USB and Firewire devices.
> > > And maybe customize Ardour to look more like contemporary
> > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > EQs and dynamics, for example). And then test the heck out
> > > of it, and don''t go "improving" it unless it needs
> > > improvement.
>
> > Well... then don't upgrade it. Didn't have a problem before I knew a
> > lot about Linux, and I still don't. Sort of like a Mac - once it's
> > running, it stays running.
> > There is a suitable realtime kernel, though it's not ALWAYS included
> > by default. There are reasons not to use it.
> > USB/Firewire support is becoming VERY good.
> > Learning Ardour should be like learning The GIMP after you know
> > Photoshop. It's like a wood shop, with the tools in different places.
> > You'll get used to it.
> > Community is the testbed. Find a bug, report it. Repeat.
>
> > > Why isn't it just there? Isn't that what a 'distro' is
> > > supposed to be? Everything you need to get going with where
> > > you're going?
>
> > Well... yeah. But do you really expect every distro to contain every
> > package out there?
>
> > > Maybe "kernel" means something different than it did 40
> > > years ago when I studied this stuff in college. That was an
> > > essential part of the operating system and you don't just
> > > stick another one in there.
>
> > No, it means the same thing. But when you upgrade/recompile/replace
> > your kernel, they're the same kernel, but certain features are
> > implemented differently.
> > The RT kernel makes absolutely certain things happen with a minimum
> > delay. You need that for audio.
>
> > > I'm making an example of myself
> > > here. I really wouldn't have any idea that I needed a real
> > > time kernel (or even that I didn't have one) and where to
> > > look for it and how to install it, particularlly if
> > > installation involved compiling it first. I tried to install
> > > something that, when troubleshooting a more basic problem,
> > > someone said I needed. I couldn't find it in a directly
> > > installable version from the Package Manager so I got the
> > > source code and followed the instructions to compile it,
> > > then install it. First error message I got was that there
> > > didn't seem to be a C++ compiler on this system, and
> > > suggested where to get one. Who knew? *I thought every Linux
> > > system had a compiler.
>
> > This is the kind of thing that tends to set people away from Linux. If
> > you have a local LUG, go to it. You might not understand it, but start
> > asking questions and explain your situation - they'll understand.
>
> > > You'd have to tell me what to type. I have no idea where the
> > > bootloader section is nor how to configure a default
> > > startup. I'm sure it's a matter of editing a text file, but
> > > which file? A seasoned Linux user would probalby be able to
> > > figure that out pretty easily, not a recording engineer though.
>
> > Not to make it sound TOO easy... but the installation for SuSE is a
> > GUI. Unless you specifically say otherwise, then it's a text-based
> > GUI. Hard to beat.
> > I fully understand the resistance (maybe I'm trying to be too
> > helpful), but nowadays it really is easy.
> > If you did try installing SuSE... this would actually be REALLY
> > intuitive. I did it on my first try.
>
> > > No thanks. I've set it aside for another year. Maybe there
> > > will be a SuSE Studio distribution by then. Maybe you'll be
> > > inspired to assemble one.
>
> > Not a bad idea. Would you at least consider trying it in a virtual
> > machine?- Hide quoted text -
>
> > - Show quoted text -
>
> I think you are making it sound TOO easy.

Ever tried it?

[Tachin]

On Aug 30, 3:00*pm, gjsmo > wrote:
> On Aug 30, 5:48*pm, Tachin > wrote:
>
>
>
>
>
> > On Aug 29, 5:21*am, gjsmo > wrote:
>
> > > > Yeah, maybe this week, but then someting will get upgraded
> > > > and break. If someone really wanted to prove to the audio
> > > > community that Linux was ready for prime time, they'd make a
> > > > distribution that had a suitable realtime kernel, and a
> > > > wider hardware support for both USB and Firewire devices.
> > > > And maybe customize Ardour to look more like contemporary
> > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > EQs and dynamics, for example). And then test the heck out
> > > > of it, and don''t go "improving" it unless it needs
> > > > improvement.
>
> > > > > You can install a relatively default configuration, then configure RT
> > > > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > supposed to be? Everything you need to get going with where
> > > > you're going?
>
> > > > > If
> > > > > you can navigate your way through the install program (it's simple
> > > > > enough), and find the kernels (package names start with kernel),
> > > > > install the realtime one.
>
> > > > Maybe "kernel" means something different than it did 40
> > > > years ago when I studied this stuff in college. That was an
> > > > essential part of the operating system and you don't just
> > > > stick another one in there. I'm making an example of myself
> > > > here. I really wouldn't have any idea that I needed a real
> > > > time kernel (or even that I didn't have one) and where to
> > > > look for it and how to install it, particularlly if
> > > > installation involved compiling it first. I tried to install
> > > > something that, when troubleshooting a more basic problem,
> > > > someone said I needed. I couldn't find it in a directly
> > > > installable version from the Package Manager so I got the
> > > > source code and followed the instructions to compile it,
> > > > then install it. First error message I got was that there
> > > > didn't seem to be a C++ compiler on this system, and
> > > > suggested where to get one. Who knew? *I thought every Linux
> > > > system had a compiler.
>
> > > > > You obviously want the 64-bit install CD/
> > > > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > > > default startup. You're done.
>
> > > > You'd have to tell me what to type. I have no idea where the
> > > > bootloader section is nor how to configure a default
> > > > startup. I'm sure it's a matter of editing a text file, but
> > > > which file? A seasoned Linux user would probalby be able to
> > > > figure that out pretty easily, not a recording engineer though.
>
> > > > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > > > one soon enough. If you can put together a patch bay, you can install
> > > > > Linux.
>
> > > > --
> > > > "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
> > > > There's a continuing discussion on the Ubuntu Studio forum
> > > > about either adding or replacing (not sure which) a real
> > > > time kernel because the one in whatever version they're
> > > > talking about wasn't very good.
>
> > > Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > > > Yeah, maybe this week, but then someting will get upgraded
> > > > and break. If someone really wanted to prove to the audio
> > > > community that Linux was ready for prime time, they'd make a
> > > > distribution that had a suitable realtime kernel, and a
> > > > wider hardware support for both USB and Firewire devices.
> > > > And maybe customize Ardour to look more like contemporary
> > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > EQs and dynamics, for example). And then test the heck out
> > > > of it, and don''t go "improving" it unless it needs
> > > > improvement.
>
> > > Well... then don't upgrade it. Didn't have a problem before I knew a
> > > lot about Linux, and I still don't. Sort of like a Mac - once it's
> > > running, it stays running.
> > > There is a suitable realtime kernel, though it's not ALWAYS included
> > > by default. There are reasons not to use it.
> > > USB/Firewire support is becoming VERY good.
> > > Learning Ardour should be like learning The GIMP after you know
> > > Photoshop. It's like a wood shop, with the tools in different places.
> > > You'll get used to it.
> > > Community is the testbed. Find a bug, report it. Repeat.
>
> > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > supposed to be? Everything you need to get going with where
> > > > you're going?
>
> > > Well... yeah. But do you really expect every distro to contain every
> > > package out there?
>
> > > > Maybe "kernel" means something different than it did 40
> > > > years ago when I studied this stuff in college. That was an
> > > > essential part of the operating system and you don't just
> > > > stick another one in there.
>
> > > No, it means the same thing. But when you upgrade/recompile/replace
> > > your kernel, they're the same kernel, but certain features are
> > > implemented differently.
> > > The RT kernel makes absolutely certain things happen with a minimum
> > > delay. You need that for audio.
>
> > > > I'm making an example of myself
> > > > here. I really wouldn't have any idea that I needed a real
> > > > time kernel (or even that I didn't have one) and where to
> > > > look for it and how to install it, particularlly if
> > > > installation involved compiling it first. I tried to install
> > > > something that, when troubleshooting a more basic problem,
> > > > someone said I needed. I couldn't find it in a directly
> > > > installable version from the Package Manager so I got the
> > > > source code and followed the instructions to compile it,
> > > > then install it. First error message I got was that there
> > > > didn't seem to be a C++ compiler on this system, and
> > > > suggested where to get one. Who knew? *I thought every Linux
> > > > system had a compiler.
>
> > > This is the kind of thing that tends to set people away from Linux. If
> > > you have a local LUG, go to it. You might not understand it, but start
> > > asking questions and explain your situation - they'll understand.
>
> > > > You'd have to tell me what to type. I have no idea where the
> > > > bootloader section is nor how to configure a default
> > > > startup. I'm sure it's a matter of editing a text file, but
> > > > which file? A seasoned Linux user would probalby be able to
> > > > figure that out pretty easily, not a recording engineer though.
>
> > > Not to make it sound TOO easy... but the installation for SuSE is a
> > > GUI. Unless you specifically say otherwise, then it's a text-based
> > > GUI. Hard to beat.
> > > I fully understand the resistance (maybe I'm trying to be too
> > > helpful), but nowadays it really is easy.
> > > If you did try installing SuSE... this would actually be REALLY
> > > intuitive. I did it on my first try.
>
> > > > No thanks. I've set it aside for another year. Maybe there
> > > > will be a SuSE Studio distribution by then. Maybe you'll be
> > > > inspired to assemble one.
>
> > > Not a bad idea. Would you at least consider trying it in a virtual
> > > machine?- Hide quoted text -
>
> > > - Show quoted text -
>
> > I think you are making it sound TOO easy.
>
> Ever tried it?- Hide quoted text -
>
> - Show quoted text -

Yes, I've used linux for the past 6 years aproximately, and spent
about a year using nothing but open source software on my computer
because I believe it is important, and while my programming skills are
practically nonexistent, I started doing documentation for Ubuntu as a
way to give back to the community.

for a long time i tried to put together a DAW using linux, but it
never delivered in terms of productivity, I was always distracted by
the OS.

And it is not easy.

But I know i have not convinced you. You, after all do not understand
why its so hard for other people when its so easy for you.
But I bet that its not easy for you either, maybe you just have more
tolerance for dealing with the OS, I have no time for it.

[gjsmo]

On Aug 30, 6:47*pm, Tachin > wrote:
> On Aug 30, 3:00*pm, gjsmo > wrote:
>
>
>
> > On Aug 30, 5:48*pm, Tachin > wrote:
>
> > > On Aug 29, 5:21*am, gjsmo > wrote:
>
> > > > > Yeah, maybe this week, but then someting will get upgraded
> > > > > and break. If someone really wanted to prove to the audio
> > > > > community that Linux was ready for prime time, they'd make a
> > > > > distribution that had a suitable realtime kernel, and a
> > > > > wider hardware support for both USB and Firewire devices.
> > > > > And maybe customize Ardour to look more like contemporary
> > > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > > EQs and dynamics, for example). And then test the heck out
> > > > > of it, and don''t go "improving" it unless it needs
> > > > > improvement.
>
> > > > > > You can install a relatively default configuration, then configure RT
> > > > > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > > supposed to be? Everything you need to get going with where
> > > > > you're going?
>
> > > > > > If
> > > > > > you can navigate your way through the install program (it's simple
> > > > > > enough), and find the kernels (package names start with kernel),
> > > > > > install the realtime one.
>
> > > > > Maybe "kernel" means something different than it did 40
> > > > > years ago when I studied this stuff in college. That was an
> > > > > essential part of the operating system and you don't just
> > > > > stick another one in there. I'm making an example of myself
> > > > > here. I really wouldn't have any idea that I needed a real
> > > > > time kernel (or even that I didn't have one) and where to
> > > > > look for it and how to install it, particularlly if
> > > > > installation involved compiling it first. I tried to install
> > > > > something that, when troubleshooting a more basic problem,
> > > > > someone said I needed. I couldn't find it in a directly
> > > > > installable version from the Package Manager so I got the
> > > > > source code and followed the instructions to compile it,
> > > > > then install it. First error message I got was that there
> > > > > didn't seem to be a C++ compiler on this system, and
> > > > > suggested where to get one. Who knew? *I thought every Linux
> > > > > system had a compiler.
>
> > > > > > You obviously want the 64-bit install CD/
> > > > > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > > > > default startup. You're done.
>
> > > > > You'd have to tell me what to type. I have no idea where the
> > > > > bootloader section is nor how to configure a default
> > > > > startup. I'm sure it's a matter of editing a text file, but
> > > > > which file? A seasoned Linux user would probalby be able to
> > > > > figure that out pretty easily, not a recording engineer though.
>
> > > > > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > > > > one soon enough. If you can put together a patch bay, you can install
> > > > > > Linux.
>
> > > > > --
> > > > > "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
> > > > > There's a continuing discussion on the Ubuntu Studio forum
> > > > > about either adding or replacing (not sure which) a real
> > > > > time kernel because the one in whatever version they're
> > > > > talking about wasn't very good.
>
> > > > Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > > > > Yeah, maybe this week, but then someting will get upgraded
> > > > > and break. If someone really wanted to prove to the audio
> > > > > community that Linux was ready for prime time, they'd make a
> > > > > distribution that had a suitable realtime kernel, and a
> > > > > wider hardware support for both USB and Firewire devices.
> > > > > And maybe customize Ardour to look more like contemporary
> > > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > > EQs and dynamics, for example). And then test the heck out
> > > > > of it, and don''t go "improving" it unless it needs
> > > > > improvement.
>
> > > > Well... then don't upgrade it. Didn't have a problem before I knew a
> > > > lot about Linux, and I still don't. Sort of like a Mac - once it's
> > > > running, it stays running.
> > > > There is a suitable realtime kernel, though it's not ALWAYS included
> > > > by default. There are reasons not to use it.
> > > > USB/Firewire support is becoming VERY good.
> > > > Learning Ardour should be like learning The GIMP after you know
> > > > Photoshop. It's like a wood shop, with the tools in different places.
> > > > You'll get used to it.
> > > > Community is the testbed. Find a bug, report it. Repeat.
>
> > > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > > supposed to be? Everything you need to get going with where
> > > > > you're going?
>
> > > > Well... yeah. But do you really expect every distro to contain every
> > > > package out there?
>
> > > > > Maybe "kernel" means something different than it did 40
> > > > > years ago when I studied this stuff in college. That was an
> > > > > essential part of the operating system and you don't just
> > > > > stick another one in there.
>
> > > > No, it means the same thing. But when you upgrade/recompile/replace
> > > > your kernel, they're the same kernel, but certain features are
> > > > implemented differently.
> > > > The RT kernel makes absolutely certain things happen with a minimum
> > > > delay. You need that for audio.
>
> > > > > I'm making an example of myself
> > > > > here. I really wouldn't have any idea that I needed a real
> > > > > time kernel (or even that I didn't have one) and where to
> > > > > look for it and how to install it, particularlly if
> > > > > installation involved compiling it first. I tried to install
> > > > > something that, when troubleshooting a more basic problem,
> > > > > someone said I needed. I couldn't find it in a directly
> > > > > installable version from the Package Manager so I got the
> > > > > source code and followed the instructions to compile it,
> > > > > then install it. First error message I got was that there
> > > > > didn't seem to be a C++ compiler on this system, and
> > > > > suggested where to get one. Who knew? *I thought every Linux
> > > > > system had a compiler.
>
> > > > This is the kind of thing that tends to set people away from Linux. If
> > > > you have a local LUG, go to it. You might not understand it, but start
> > > > asking questions and explain your situation - they'll understand.
>
> > > > > You'd have to tell me what to type. I have no idea where the
> > > > > bootloader section is nor how to configure a default
> > > > > startup. I'm sure it's a matter of editing a text file, but
> > > > > which file? A seasoned Linux user would probalby be able to
> > > > > figure that out pretty easily, not a recording engineer though.
>
> > > > Not to make it sound TOO easy... but the installation for SuSE is a
> > > > GUI. Unless you specifically say otherwise, then it's a text-based
> > > > GUI. Hard to beat.
> > > > I fully understand the resistance (maybe I'm trying to be too
> > > > helpful), but nowadays it really is easy.
> > > > If you did try installing SuSE... this would actually be REALLY
> > > > intuitive. I did it on my first try.
>
> > > > > No thanks. I've set it aside for another year. Maybe there
> > > > > will be a SuSE Studio distribution by then. Maybe you'll be
> > > > > inspired to assemble one.
>
> > > > Not a bad idea. Would you at least consider trying it in a virtual
> > > > machine?- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > I think you are making it sound TOO easy.
>
> > Ever tried it?- Hide quoted text -
>
> > - Show quoted text -
>
> Yes, I've used linux for the past 6 years aproximately, and spent
> about a year using nothing but open source software on my computer
> because I believe it is important, and while my programming skills are
> practically nonexistent, I started doing documentation for Ubuntu as a
> way to give back to the community.
>
> for a long time i tried to put together a DAW using linux, but it
> never delivered in terms of productivity, I was always distracted by
> the OS.
>
> And it is not easy.
>
> But I know i have not convinced you. You, after all do not understand
> why its so hard for other people when its so easy for you.
> But I bet that its not easy for you either, maybe you just have more
> tolerance for dealing with the OS, I have no time for it.

Well, no... I have less money. But close.
I also happen to like building things - anything. So that's nice.
Again, your reasons are your own. I happen to find it easy, not only
because many things are available for free, somewhere, but also
because I've shot myself in the foot enough times to know not to push
the red button.
Literally right now, I'm installing SuSE on a VM. It's working like a
charm. Almost second nature now, I've done it at least 20 times
because I messed something up.

I do understand why it's so hard for some, especially when certain
people are more likely to think the computer has a built-in cupholder
rather than a state-of-the-art Blu-ray burner. But I digress.
Most people don't want to deal with it - they are conditioned to
Windows (or sometimes Mac) and being able to buy a fix to their
problem. Whatever it is, you can fix it if you've got the money. I
prefer having the skills to fix it. Just me.

Consider this: if Linux was bundled with the original IBM PC (not
something that would have passed marketing, but just for the sake of
argument), would it be easy(er) to use, and would Microsoft have lost
out on the market?

[Tachin]

On Aug 30, 6:11*pm, gjsmo > wrote:
> On Aug 30, 6:47*pm, Tachin > wrote:
>
>
>
>
>
> > On Aug 30, 3:00*pm, gjsmo > wrote:
>
> > > On Aug 30, 5:48*pm, Tachin > wrote:
>
> > > > On Aug 29, 5:21*am, gjsmo > wrote:
>
> > > > > > Yeah, maybe this week, but then someting will get upgraded
> > > > > > and break. If someone really wanted to prove to the audio
> > > > > > community that Linux was ready for prime time, they'd make a
> > > > > > distribution that had a suitable realtime kernel, and a
> > > > > > wider hardware support for both USB and Firewire devices.
> > > > > > And maybe customize Ardour to look more like contemporary
> > > > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > > > EQs and dynamics, for example). And then test the heck out
> > > > > > of it, and don''t go "improving" it unless it needs
> > > > > > improvement.
>
> > > > > > > You can install a relatively default configuration, then configure RT
> > > > > > > later. Or it may be simpler to install the RT kernel to begin with.
>
> > > > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > > > supposed to be? Everything you need to get going with where
> > > > > > you're going?
>
> > > > > > > If
> > > > > > > you can navigate your way through the install program (it's simple
> > > > > > > enough), and find the kernels (package names start with kernel),
> > > > > > > install the realtime one.
>
> > > > > > Maybe "kernel" means something different than it did 40
> > > > > > years ago when I studied this stuff in college. That was an
> > > > > > essential part of the operating system and you don't just
> > > > > > stick another one in there. I'm making an example of myself
> > > > > > here. I really wouldn't have any idea that I needed a real
> > > > > > time kernel (or even that I didn't have one) and where to
> > > > > > look for it and how to install it, particularlly if
> > > > > > installation involved compiling it first. I tried to install
> > > > > > something that, when troubleshooting a more basic problem,
> > > > > > someone said I needed. I couldn't find it in a directly
> > > > > > installable version from the Package Manager so I got the
> > > > > > source code and followed the instructions to compile it,
> > > > > > then install it. First error message I got was that there
> > > > > > didn't seem to be a C++ compiler on this system, and
> > > > > > suggested where to get one. Who knew? *I thought every Linux
> > > > > > system had a compiler.
>
> > > > > > > You obviously want the 64-bit install CD/
> > > > > > > DVD. Go to the bootloader section, and configure that kernel to be the
> > > > > > > default startup. You're done.
>
> > > > > > You'd have to tell me what to type. I have no idea where the
> > > > > > bootloader section is nor how to configure a default
> > > > > > startup. I'm sure it's a matter of editing a text file, but
> > > > > > which file? A seasoned Linux user would probalby be able to
> > > > > > figure that out pretty easily, not a recording engineer though.
>
> > > > > > > I could probably send screenshots of a SuSE install, as I'll be doing
> > > > > > > one soon enough. If you can put together a patch bay, you can install
> > > > > > > Linux.
>
> > > > > > --
> > > > > > "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
> > > > > > There's a continuing discussion on the Ubuntu Studio forum
> > > > > > about either adding or replacing (not sure which) a real
> > > > > > time kernel because the one in whatever version they're
> > > > > > talking about wasn't very good.
>
> > > > > Dunno about Ubuntu studio. 64 Studio is a different distro.
>
> > > > > > Yeah, maybe this week, but then someting will get upgraded
> > > > > > and break. If someone really wanted to prove to the audio
> > > > > > community that Linux was ready for prime time, they'd make a
> > > > > > distribution that had a suitable realtime kernel, and a
> > > > > > wider hardware support for both USB and Firewire devices.
> > > > > > And maybe customize Ardour to look more like contemporary
> > > > > > Windows or Mac DAWs (more hardware-looking graphics on the
> > > > > > EQs and dynamics, for example). And then test the heck out
> > > > > > of it, and don''t go "improving" it unless it needs
> > > > > > improvement.
>
> > > > > Well... then don't upgrade it. Didn't have a problem before I knew a
> > > > > lot about Linux, and I still don't. Sort of like a Mac - once it's
> > > > > running, it stays running.
> > > > > There is a suitable realtime kernel, though it's not ALWAYS included
> > > > > by default. There are reasons not to use it.
> > > > > USB/Firewire support is becoming VERY good.
> > > > > Learning Ardour should be like learning The GIMP after you know
> > > > > Photoshop. It's like a wood shop, with the tools in different places.
> > > > > You'll get used to it.
> > > > > Community is the testbed. Find a bug, report it. Repeat.
>
> > > > > > Why isn't it just there? Isn't that what a 'distro' is
> > > > > > supposed to be? Everything you need to get going with where
> > > > > > you're going?
>
> > > > > Well... yeah. But do you really expect every distro to contain every
> > > > > package out there?
>
> > > > > > Maybe "kernel" means something different than it did 40
> > > > > > years ago when I studied this stuff in college. That was an
> > > > > > essential part of the operating system and you don't just
> > > > > > stick another one in there.
>
> > > > > No, it means the same thing. But when you upgrade/recompile/replace
> > > > > your kernel, they're the same kernel, but certain features are
> > > > > implemented differently.
> > > > > The RT kernel makes absolutely certain things happen with a minimum
> > > > > delay. You need that for audio.
>
> > > > > > I'm making an example of myself
> > > > > > here. I really wouldn't have any idea that I needed a real
> > > > > > time kernel (or even that I didn't have one) and where to
> > > > > > look for it and how to install it, particularlly if
> > > > > > installation involved compiling it first. I tried to install
> > > > > > something that, when troubleshooting a more basic problem,
> > > > > > someone said I needed. I couldn't find it in a directly
> > > > > > installable version from the Package Manager so I got the
> > > > > > source code and followed the instructions to compile it,
> > > > > > then install it. First error message I got was that there
> > > > > > didn't seem to be a C++ compiler on this system, and
> > > > > > suggested where to get one. Who knew? *I thought every Linux
> > > > > > system had a compiler.
>
> > > > > This is the kind of thing that tends to set people away from Linux. If
> > > > > you have a local LUG, go to it. You might not understand it, but start
> > > > > asking questions and explain your situation - they'll understand.
>
> > > > > > You'd have to tell me what to type. I have no idea where the
> > > > > > bootloader section is nor how to configure a default
> > > > > > startup. I'm sure it's a matter of editing a text file, but
> > > > > > which file? A seasoned Linux user would probalby be able to
> > > > > > figure that out pretty easily, not a recording engineer though.
>
> > > > > Not to make it sound TOO easy... but the installation for SuSE is a
> > > > > GUI. Unless you specifically say otherwise, then it's a text-based
> > > > > GUI. Hard to beat.
> > > > > I fully understand the resistance (maybe I'm trying to be too
> > > > > helpful), but nowadays it really is easy.
> > > > > If you did try installing SuSE... this would actually be REALLY
> > > > > intuitive. I did it on my first try.
>
> > > > > > No thanks. I've set it aside for another year. Maybe there
> > > > > > will be a SuSE Studio distribution by then. Maybe you'll be
> > > > > > inspired to assemble one.
>
> > > > > Not a bad idea. Would you at least consider trying it in a virtual
> > > > > machine?- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > I think you are making it sound TOO easy.
>
> > > Ever tried it?- Hide quoted text -
>
> > > - Show quoted text -
>
> > Yes, I've used linux for the past 6 years aproximately, and spent
> > about a year using nothing but open source software on my computer
> > because I believe it is important, and while my programming skills are
> > practically nonexistent, I started doing documentation for Ubuntu as a
> > way to give back to the community.
>
> > for a long time i tried to put together a DAW using linux, but it
> > never delivered in terms of productivity, I was always distracted by
> > the OS.
>
> > And it is not easy.
>
> > But I know i have not convinced you. You, after all do not understand
> > why its so hard for other people when its so easy for you.
> > But I bet that its not easy for you either, maybe you just have more
> > tolerance for dealing with the OS, I have no time for it.
>
> Well, no... I have less money. But close.
> I also happen to like building things - anything. So that's nice.
> Again, your reasons are your own. I happen to find it easy, not only
> because many things are available for free, somewhere, but also
> because I've shot myself in the foot enough times to know not to push
> the red button.
> Literally right now, I'm installing SuSE on a VM. It's working like a
> charm. Almost second nature now, I've done it at least 20 times
> because I messed something up.
>
> I do understand why it's so hard for some, especially when certain
> people are more likely to think the computer has a built-in cupholder
> rather than a state-of-the-art Blu-ray burner. But I digress.
> Most people don't want to deal with it - they are conditioned to
> Windows (or sometimes Mac) and being able to buy a fix to their
> problem. Whatever it is, you can fix it if you've got the money. I
> prefer having the skills to fix it. Just me.
>
> Consider this: if Linux was bundled with the original IBM PC (not
> something that would have passed marketing, but just for the sake of
> argument), would it be easy(er) to use, and would Microsoft have lost
> out on the market?- Hide quoted text -
>
> - Show quoted text -

If you make it work, thats good, more power to you, but you may be
wrong when you assume that having tech skills are the opposite of
being a naive, regular ol' computer user.

It takes time and effort to acquire those skills. It also takes time
to acquire skills on any and every other subject, for example, pro
audio.
I used to have time to try to do both, but now I don't, so I choose
what works. And since i stopped tinkering with my machine, suddenly, i
noticed i was improving because i spent more time working and less
tinkering.

So, sadly, Linux is ready for the mainstream only in those
applications where its users already need to have the necesary
technical skills to set it up, troubleshoot and code their own
solutions for it.

[Mike Rivers]

Tachin wrote:

> for a long time i tried to put together a DAW using linux, but it
> never delivered in terms of productivity, I was always distracted by
> the OS.
>
> And it is not easy.

That's been my experience too. But individuals are all
different. It's my belief that computer users should not
have to "deal with" an operating system. If updates are
required for security, to fix annoying bugs, or to be
compatible with updated hardware, they should go in
smoothly, there should be one version (or one appropriate
version), and it should be configuration-managed.

Linux is in a constant flux and you're never sure, when you
start with your Time Zero, just what you're getting. I was
just reading today in the ffado mailing list digest about
how "ffado-trunk" solves a lot of problems with some new
hardware. What the heck is that??? Well, doing some digging
around, I see that it's an in-progress release, and in
checking versions, I see that it came with the distribution
that I've installed. Guess it didn't solve my problem.



--
"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]

gjsmo wrote:

> Consider this: if Linux was bundled with the original IBM PC (not
> something that would have passed marketing, but just for the sake of
> argument), would it be easy(er) to use, and would Microsoft have lost
> out on the market?

That's kind of a far fetched question, but I think the
answer would have to be "no." There were a number of
hobbyist computers and operating systems before the IBM PC.
They were fun for people who liked to experiment with
computers, and some even managed to do productive things
with them. My Unix-head friend ran a small mailing list
business off a computer running OS-9.

But the IBM PC was a self-contained unit. Computer and
operating system as a package, and you could buy software
that was easy to install and use. That's what made it a
success, not MS-DOS, PC-DOS, or CP/M, however you decide was
the evolution.

There was a short period where you could buy a PC with Linux
installed. In fact, IBM even made some. Most were generic
boxes sold through Wal-Mart for about $100 less than a
generic PC with Windows (probably 95 at the time). It was an
attractive package for people who couldn't quite swing the
money for a PC, but it fell out of favor pretty quickly when
they discovered that you couldn't put AOL software on it.

The system did have an advantage over the way that people
use Linux today, though, and that's that it was the same
installation on every box. There was a tech support
department you could call if you needed help, and since the
market for these computers was people who wouldn't be
compiling the latest test versions of operating system
components, they didn't have to first figure out what was on
your system before helping you out.


--
"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]

Tachin wrote:

> It takes time and effort to acquire those skills. It also takes time
> to acquire skills on any and every other subject, for example, pro
> audio.

People use that argument on me, saying "Well, you had to
learn how to align a tape deck." The difference is that the
tape deck (and the amplifier that needs repair, and the
cable that needs to be constructed) are all physical. I can
use a voltmeter and an oscilloscope and, with the help of
the service manual or schematics, troubleshoot a problem,
make an adjustment, or perform a modification. There are
parallels in software - with source code and a debugger, you
can see what's going wrong in a system. But these skills are
learned in such different ways that because you take to one
doesn't necessarily mean you can easily adapt to the other.
There are people who never aligned their tape decks and were
so happy to be able to record with software because it never
changed or degraded with age.

> So, sadly, Linux is ready for the mainstream only in those
> applications where its users already need to have the necesary
> technical skills to set it up, troubleshoot and code their own
> solutions for it.

Clearly that's the best way to work with Linux in its
present state. I think it's certainly possible to make a
stable version and update it when it needs updating, in a
managed fashion. But that's not the way that people who work
for free operate. And who would BUY a version of Linux when
it can be had for free? And if you could buy it, would it
be cheaper than Windows?

Harrison builds digital consoles with Linux at their heart,
but they install the software on the computer that comes
with the console, they know what's there so they can support
it and update it, and the user doesn't need to know
anything but how to stick in a disk that he gets from the
company and follow the installation instructions.


--
"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

[Neil Gould]

Scott Dorsey wrote:
> Mike Rivers > wrote:
>>
>> But you see, this is a 25 year setback. Back then I would
>> occasionally go to a local DOS user's group because there
>> was a lot to learn that was necessary to do what i wanted to
>> do with a computer back then. But in the last 15 years, when
>> I installed a Windows system, it just worked and I didn't
>> have to re-compile anything, edit a config.sys file, or
>> write batch files. This is what "we" expect from a computer
>> today, not a do-it-yourself project. The collective "we"
>> wants to be able to use off-the-shelf software that works
>> with our off-the-shelf operating systems. In order to go
>> back to the DIY days, there has to be a better reason than
>> that the software is free and can be modified at will. It
>> hasn't always been so, but today there's plenty of good
>> audio software off the shelf. And some of it is even free.
>
> Clearly you've had much better luck with Windows than I have then.
>
> At least with Linux you can look inside and see what is failing when
> things don't work, rather than just flail around trying different
> things at random as seems standard for Windows diagnosis.
> --scott
>
It is no more necessary to "flail around..." in Windows than any other OS.
System-level troubleshooting is fairly easy to do if you understand systems,
and pinpointing the device that is not working doesn't require special
tools. That most people lack the knowledge and tools to troubleshoot an
application is not the fault of the OS, and flailing around is just bad
practice, anyway. ;-)

But, all of this misses the point: it is typically unnecessary to do
app-level troubleshooting with Windows or Mac applications, as the release
versions of the apps will work on almost any system they claim to on the
box.

--
best regards,

Neil

[gjsmo]

On Aug 31, 8:00*am, "Neil Gould" > wrote:
> Scott Dorsey wrote:
> > Mike Rivers > wrote:
>
> >> But you see, this is a 25 year setback. Back then I would
> >> occasionally go to a local DOS user's group because there
> >> was a lot to learn that was necessary to do what i wanted to
> >> do with a computer back then. But in the last 15 years, when
> >> I installed a Windows system, it just worked and I didn't
> >> have to re-compile anything, edit a config.sys file, or
> >> write batch files. This is what "we" expect from a computer
> >> today, not a do-it-yourself project. The collective "we"
> >> wants to be able to use off-the-shelf software that works
> >> with our off-the-shelf operating systems. In order to go
> >> back to the DIY days, there has to be a better reason than
> >> that the software is free and can be modified at will. It
> >> hasn't always been so, but today there's plenty of good
> >> audio software off the shelf. And some of it is even free.
>
> > Clearly you've had much better luck with Windows than I have then.
>
> > At least with Linux you can look inside and see what is failing when
> > things don't work, rather than just flail around trying different
> > things at random as seems standard for Windows diagnosis.
> > --scott
>
> It is no more necessary to "flail around..." in Windows than any other OS..
> System-level troubleshooting is fairly easy to do if you understand systems,
> and pinpointing the device that is not working doesn't require special
> tools. That most people lack the knowledge and tools to troubleshoot an
> application is not the fault of the OS, and flailing around is just bad
> practice, anyway. *;-)

I find it quite necessary. Windows is closed source, so if you want to
find out how something went wrong, you either have to flail around -
or give up and reinstall.
Linux can be poked at, you can recompile the kernel, you can install
different libraries, and do all sorts of things that aren't doable on
Windows.

> But, all of this misses the point: it is typically unnecessary to do
> app-level troubleshooting with Windows or Mac applications, as the release
> versions of the apps will work on almost any system they claim to on the
> box.

....yes, and if (BIG if) you have the ability to compile a program on
linux (often a matter of using the package manager, now) you can do
the same.

[Mike Rivers]

gjsmo wrote:

> Windows is closed source, so if you want to
> find out how something went wrong, you either have to flail around -
> or give up and reinstall.

Can you give an example? What sort of things go wrong that
you have found by "flailing around?" Now and then I find
things that used to work that break, but that's usually
traceable to having installed of changed something. And
sometimes new things simply don't work. But it's rare that
they can be fixed by "flailing around."



--
"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

[Scott Dorsey]

Mike Rivers > wrote:
>gjsmo wrote:
>
>> Consider this: if Linux was bundled with the original IBM PC (not
>> something that would have passed marketing, but just for the sake of
>> argument), would it be easy(er) to use, and would Microsoft have lost
>> out on the market?
>
>That's kind of a far fetched question, but I think the
>answer would have to be "no." There were a number of
>hobbyist computers and operating systems before the IBM PC.
>They were fun for people who liked to experiment with
>computers, and some even managed to do productive things
>with them. My Unix-head friend ran a small mailing list
>business off a computer running OS-9.
>
>But the IBM PC was a self-contained unit. Computer and
>operating system as a package, and you could buy software
>that was easy to install and use. That's what made it a
>success, not MS-DOS, PC-DOS, or CP/M, however you decide was
>the evolution.

Right. The thing is, what made MS-DOS popular was that it was cheap and
bundled with the PC. You could also order the original IBM PC without any
OS at all (just BASIC in ROM), or with CP/M-86, or with the UCSD P-System.

People bought MS-DOS because it was very very cheap and CP/M-96 and UCSD
cost a couple hundred dollars more. And that's why we have Windows today.

What would have happened if something else had been cheap?

Incidentally, you could have bought the IBM AT bundled with Xenix from IBM,
or you could have bought a Radio Shack Model 16 at about the same time, with
full multitasking Xenix. A lot of folks did, but they were too expensive for
consumer use. Xenix was somewhat eviscerated but it was mostly Unix.

>There was a short period where you could buy a PC with Linux
>installed. In fact, IBM even made some. Most were generic
>boxes sold through Wal-Mart for about $100 less than a
>generic PC with Windows (probably 95 at the time). It was an
>attractive package for people who couldn't quite swing the
>money for a PC, but it fell out of favor pretty quickly when
>they discovered that you couldn't put AOL software on it.

You can still buy lots of them from IBM and Dell, and lots of other
vendors, often with distributions that are supported by the vendor.

>The system did have an advantage over the way that people
>use Linux today, though, and that's that it was the same
>installation on every box. There was a tech support
>department you could call if you needed help, and since the
>market for these computers was people who wouldn't be
>compiling the latest test versions of operating system
>components, they didn't have to first figure out what was on
>your system before helping you out.

That still exists, if you're willing to pay money for it. The problem
is that too few people are willing to pay money for it. But I have a
bunch of SuSe and Red Hat machines with support contracts.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

Neil Gould > wrote:
>It is no more necessary to "flail around..." in Windows than any other OS.
>System-level troubleshooting is fairly easy to do if you understand systems,
>and pinpointing the device that is not working doesn't require special
>tools. That most people lack the knowledge and tools to troubleshoot an
>application is not the fault of the OS, and flailing around is just bad
>practice, anyway. ;-)

Give me a tool like Totalview for windows and I will agree with that.

>But, all of this misses the point: it is typically unnecessary to do
>app-level troubleshooting with Windows or Mac applications, as the release
>versions of the apps will work on almost any system they claim to on the
>box.

Ahh, if only this were the case. And it seems half my life is spent trying
to figure out how the apps actually work inside. ("Is that really a 32-bit
float.... am I getting truncating? Why does it do this when I set the
dither function to that?") On the Mac there are a bunch of really nice
tools for that sort of thing, starting with the lowly ktrace. Windows is
not so easily dealt with.
--scott

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

[Neil Gould]

gjsmo wrote:
> On Aug 31, 8:00 am, "Neil Gould" > wrote:
>> Scott Dorsey wrote:
>>> Mike Rivers > wrote:
>>
>>>> But you see, this is a 25 year setback. Back then I would
>>>> occasionally go to a local DOS user's group because there
>>>> was a lot to learn that was necessary to do what i wanted to
>>>> do with a computer back then. But in the last 15 years, when
>>>> I installed a Windows system, it just worked and I didn't
>>>> have to re-compile anything, edit a config.sys file, or
>>>> write batch files. This is what "we" expect from a computer
>>>> today, not a do-it-yourself project. The collective "we"
>>>> wants to be able to use off-the-shelf software that works
>>>> with our off-the-shelf operating systems. In order to go
>>>> back to the DIY days, there has to be a better reason than
>>>> that the software is free and can be modified at will. It
>>>> hasn't always been so, but today there's plenty of good
>>>> audio software off the shelf. And some of it is even free.
>>
>>> Clearly you've had much better luck with Windows than I have then.
>>
>>> At least with Linux you can look inside and see what is failing when
>>> things don't work, rather than just flail around trying different
>>> things at random as seems standard for Windows diagnosis.
>>> --scott
>>
>> It is no more necessary to "flail around..." in Windows than any
>> other OS. System-level troubleshooting is fairly easy to do if you
>> understand systems, and pinpointing the device that is not working
>> doesn't require special tools. That most people lack the knowledge
>> and tools to troubleshoot an application is not the fault of the OS,
>> and flailing around is just bad practice, anyway. ;-)
>
> I find it quite necessary. Windows is closed source, so if you want to
> find out how something went wrong, you either have to flail around -
> or give up and reinstall.
>
Unless you're a beta tester, this is a pointless exercise, and if you are a
beta tester, you've been provided with the tools and information to
eliminate flailing. So, one way to look at Linux with pro-anything
applications is that all users are actually beta testers.

> Linux can be poked at, you can recompile the kernel, you can install
> different libraries, and do all sorts of things that aren't doable on
> Windows.
>
That's because it's unnecessary to do such things in Windows. As far as pro
audio goes, there are probably more beta testers of any particular product
under Windows than the entire user base of that product under Linux.

>> But, all of this misses the point: it is typically unnecessary to do
>> app-level troubleshooting with Windows or Mac applications, as the
>> release versions of the apps will work on almost any system they
>> claim to on the box.
>
> ...yes, and if (BIG if) you have the ability to compile a program on
> linux (often a matter of using the package manager, now) you can do
> the same.
>
It appears that your experience differs from those of us that actually own
and use pro audio hardware and applications.

--
best regards,

Neil

[Neil Gould]

Scott Dorsey wrote:
> Neil Gould > wrote:
>> But, all of this misses the point: it is typically unnecessary to do
>> app-level troubleshooting with Windows or Mac applications, as the
>> release versions of the apps will work on almost any system they
>> claim to on the box.
>
> Ahh, if only this were the case. And it seems half my life is spent
> trying to figure out how the apps actually work inside. ("Is that
> really a 32-bit float.... am I getting truncating? Why does it do
> this when I set the dither function to that?") On the Mac there are
> a bunch of really nice tools for that sort of thing, starting with
> the lowly ktrace. Windows is not so easily dealt with.
>
When I have to deal with things on that level, I write my own tools, too.
That way, I'm not dealing with any "black box" situations. A byte reader
that logs information from a port is fairly easy to write, and will answer
such questions. However, I'd say that such uses are more related to app
development than audio production. The only thing the average user needs to
know is whether they get output from their input, and that seems to be the
point of failure for some Linux pro audio installations. ;-)

--
best regards,

Neil

[Mike Rivers]

Scott Dorsey wrote:

> Ahh, if only this were the case. And it seems half my life is spent trying
> to figure out how the apps actually work inside. ("Is that really a 32-bit
> float.... am I getting truncating? Why does it do this when I set the
> dither function to that?")

Ah, what a wonderful life you lead. <g>

I'm happy that there are people like you who care about why
something doesn't sound right. I'm content to recognize that
it doesn't sound right, and look for other options - either
different settings or a different program to do the job that
DOES sound right. I don't have any reservations about
telling a maker of some audio (or maybe you're talking about
data collection and processing) software that it sounds
wrong, but I don't feel it's my job to tell him what the
program is doing that makes it sound that way. You may be
able to fix the problem yourself if you're able to re-write
a part of the program, or help the manufacturer fix it, but
if a tool doesn't work for me, I look for a different tool.



--
"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

[gjsmo]

On Aug 31, 8:45*am, Mike Rivers > wrote:
> gjsmo wrote:
> > Windows is closed source, so if you want to
> > find out how something went wrong, you either have to flail around -
> > or give up and reinstall.
>
> Can you give an example? What sort of things go wrong that
> you have found by "flailing around?" Now and then I find
> things that used to work that break, but that's usually
> traceable to having installed of changed something. And
> sometimes new things simply don't work. But it's rare that
> they can be fixed by "flailing around."

Lots of driver issues seem to fix themselves after I mess with
everything, seemingly end up where I started, and I got it to work.

@Neil
> Unless you're a beta tester, this is a pointless exercise, and if you are a
> beta tester, you've been provided with the tools and information to
> eliminate flailing. So, one way to look at Linux with pro-anything
> applications is that all users are actually beta testers.

Technically, everyone's a beta tester, because it's been proven that
it's impossible to test every single situation (I can't remember who
proved it). So you can never know that ALL the bugs are out.

> That's because it's unnecessary to do such things in Windows.

No it's not. Apps tend to install their libraries and various helper
programs along with the base program. Like MS Visual C++
Redistributable - comes with probably everything. Or the .NET
framework. Libraries that install themselves. Easier, but then someone
needs an extra library. So they install it in the program folder.
Something else needs it, but because not many libraries are
standardized on Windows, it'll install another copy, possibly of a
different version. It's easier in the end to do everything through a
package manager, which will install everything without a hitch once
it's set up.

[Neil Gould]

gjsmo wrote:
> @Neil
>> Unless you're a beta tester, this is a pointless exercise, and if
>> you are a beta tester, you've been provided with the tools and
>> information to eliminate flailing. So, one way to look at Linux with
>> pro-anything applications is that all users are actually beta
>> testers.
>
> Technically, everyone's a beta tester, because it's been proven that
> it's impossible to test every single situation (I can't remember who
> proved it). So you can never know that ALL the bugs are out.
>
It is not a beta tester's responsiblity to get out all of the bugs. That's
what manufacturer's tech support is for.

>> That's because it's unnecessary to do such things in Windows.
>
> No it's not. Apps tend to install their libraries and various helper
> programs along with the base program. Like MS Visual C++
> Redistributable - comes with probably everything.
> Or the .NET
> framework. Libraries that install themselves. Easier, but then someone
> needs an extra library. So they install it in the program folder.
> Something else needs it, but because not many libraries are
> standardized on Windows, it'll install another copy, possibly of a
> different version. It's easier in the end to do everything through a
> package manager, which will install everything without a hitch once
> it's set up.
>
Programming languages are not the same as pro audio hardware, and do not
present the same issues to users. When one is setting up a computer as a
programming environment, they are expected to have a level of knowledge
sufficient to support such a system.

--
best regards,

Neil

[gjsmo]

On Aug 31, 3:26*pm, "Neil Gould" > wrote:
> gjsmo wrote:
> > @Neil
> >> Unless you're a beta tester, this is a pointless exercise, and if
> >> you are a beta tester, you've been provided with the tools and
> >> information to eliminate flailing. So, one way to look at Linux with
> >> pro-anything applications is that all users are actually beta
> >> testers.
>
> > Technically, everyone's a beta tester, because it's been proven that
> > it's impossible to test every single situation (I can't remember who
> > proved it). So you can never know that ALL the bugs are out.
>
> It is not a beta tester's responsiblity to get out all of the bugs. That's
> what manufacturer's tech support is for.

I never said that. But it IS a beta tester's responsibility to FIND
bugs.

> >> That's because it's unnecessary to do such things in Windows.
>
> > No it's not. Apps tend to install their libraries and various helper
> > programs along with the base program. Like MS Visual C++
> > Redistributable - comes with probably everything.
> > Or the .NET
> > framework. Libraries that install themselves. Easier, but then someone
> > needs an extra library. So they install it in the program folder.
> > Something else needs it, but because not many libraries are
> > standardized on Windows, it'll install another copy, possibly of a
> > different version. It's easier in the end to do everything through a
> > package manager, which will install everything without a hitch once
> > it's set up.
>
> Programming languages are not the same as pro audio hardware, and do not
> present the same issues to users. When one is setting up a computer as a
> programming environment, they are expected to have a level of knowledge
> sufficient to support such a system.

It's not a programming language (it's related, though). It's a set of
libraries that many other programs developed with Visual C++ use.

>
> --
> best regards,
>
> Neil

[Scott Dorsey]

Neil Gould > wrote:
>Scott Dorsey wrote:
>> Neil Gould > wrote:
>>> But, all of this misses the point: it is typically unnecessary to do
>>> app-level troubleshooting with Windows or Mac applications, as the
>>> release versions of the apps will work on almost any system they
>>> claim to on the box.
>>
>> Ahh, if only this were the case. And it seems half my life is spent
>> trying to figure out how the apps actually work inside. ("Is that
>> really a 32-bit float.... am I getting truncating? Why does it do
>> this when I set the dither function to that?") On the Mac there are
>> a bunch of really nice tools for that sort of thing, starting with
>> the lowly ktrace. Windows is not so easily dealt with.
>>
>When I have to deal with things on that level, I write my own tools, too.

Why should I have to write my own tools when a proper and reasonable OS
provides them for me?

>That way, I'm not dealing with any "black box" situations. A byte reader
>that logs information from a port is fairly easy to write, and will answer
>such questions. However, I'd say that such uses are more related to app
>development than audio production. The only thing the average user needs to
>know is whether they get output from their input, and that seems to be the
>point of failure for some Linux pro audio installations. ;-)

That's fine for the average user, but what if you want to do something the
average user doesn't want to do? Like care about bit-for-bit accuracy of an
application for mastering work?
--scott

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

[Neil Gould]

Scott Dorsey wrote:
> Neil Gould > wrote:
>> Scott Dorsey wrote:
>>> Neil Gould > wrote:
>>>> But, all of this misses the point: it is typically unnecessary to
>>>> do app-level troubleshooting with Windows or Mac applications, as
>>>> the release versions of the apps will work on almost any system
>>>> they claim to on the box.
>>>
>>> Ahh, if only this were the case. And it seems half my life is spent
>>> trying to figure out how the apps actually work inside. ("Is that
>>> really a 32-bit float.... am I getting truncating? Why does it do
>>> this when I set the dither function to that?") On the Mac there are
>>> a bunch of really nice tools for that sort of thing, starting with
>>> the lowly ktrace. Windows is not so easily dealt with.
>>>
>> When I have to deal with things on that level, I write my own tools,
>> too.
>
> Why should I have to write my own tools when a proper and reasonable
> OS provides them for me?
>
There are tons of tools available for most OSs, and Windows is no exception.

>> That way, I'm not dealing with any "black box" situations. A byte
>> reader that logs information from a port is fairly easy to write,
>> and will answer such questions. However, I'd say that such uses are
>> more related to app development than audio production. The only
>> thing the average user needs to know is whether they get output from
>> their input, and that seems to be the point of failure for some
>> Linux pro audio installations. ;-)
>
> That's fine for the average user, but what if you want to do
> something the average user doesn't want to do? Like care about
> bit-for-bit accuracy of an application for mastering work?
>
I hope you aren't implying that an OS will restrict you from doing that, or
that users of a particular OS don't care about bit-for-bit accuracy for
mastering work?

--
best regards,

Neil

[Neil Gould]

gjsmo wrote:
> On Aug 31, 3:26 pm, "Neil Gould" > wrote:
>> gjsmo wrote:
>>> @Neil
>>>> Unless you're a beta tester, this is a pointless exercise, and if
>>>> you are a beta tester, you've been provided with the tools and
>>>> information to eliminate flailing. So, one way to look at Linux
>>>> with pro-anything applications is that all users are actually beta
>>>> testers.
>>
>>> Technically, everyone's a beta tester, because it's been proven that
>>> it's impossible to test every single situation (I can't remember who
>>> proved it). So you can never know that ALL the bugs are out.
>>
>> It is not a beta tester's responsiblity to get out all of the bugs.
>> That's what manufacturer's tech support is for.
>
> I never said that. But it IS a beta tester's responsibility to FIND
> bugs.
>
I can understand why a Linux user would think that "Technically, everyone's
a beta tester...", because that's pretty much the nature of Open Source
software. Having been a beta tester for Windows-based pro audio apps, I can
tell you it is nothing like being a _user_ of Windows-based pro audio apps.
No flailing is necessary.

--
best regards,

Neil

[gjsmo]

On Aug 31, 6:39*pm, "Neil Gould" > wrote:
> gjsmo wrote:
> > On Aug 31, 3:26 pm, "Neil Gould" > wrote:
> >> gjsmo wrote:
> >>> @Neil
> >>>> Unless you're a beta tester, this is a pointless exercise, and if
> >>>> you are a beta tester, you've been provided with the tools and
> >>>> information to eliminate flailing. So, one way to look at Linux
> >>>> with pro-anything applications is that all users are actually beta
> >>>> testers.
>
> >>> Technically, everyone's a beta tester, because it's been proven that
> >>> it's impossible to test every single situation (I can't remember who
> >>> proved it). So you can never know that ALL the bugs are out.
>
> >> It is not a beta tester's responsiblity to get out all of the bugs.
> >> That's what manufacturer's tech support is for.
>
> > I never said that. But it IS a beta tester's responsibility to FIND
> > bugs.
>
> I can understand why a Linux user would think that "Technically, everyone's
> a beta tester...", because that's pretty much the nature of Open Source
> software. Having been a beta tester for Windows-based pro audio apps, I can
> tell you it is nothing like being a _user_ of Windows-based pro audio apps.
> No flailing is necessary.
>
> --
> best regards,
>
> Neil

It's an obscure reference... never mind.

Someone in the '60s or '70s proved that it was impossible to ever test
all possible combinations of hardware and software, and therefore it
was never possible to be sure that ALL the bugs were gone. I can't
remember who it was, I'd have to look it up. But I have encountered
major bugs in Windows programs before, and while these are not pro
audio apps, they are major, professional apps (specifically,
FlexiSIGN, a sign layout program).

Irrelevant it is. Forget I ever said it, you will.

[Mike Rivers]

gjsmo wrote:

> Lots of driver issues seem to fix themselves after I mess with
> everything, seemingly end up where I started, and I got it to work.

I hate when that happens, but that was the story when I was
trying to get JACK to recognize my Mackie mixer. I got
several directions from folks on a support forum, mostly to
verify that certain programs were present and were able to
run, and after trying all of them, the mixer was recognized.
Flailing around, indeed, but it got results.

> Technically, everyone's a beta tester, because it's been proven that
> it's impossible to test every single situation (I can't remember who
> proved it). So you can never know that ALL the bugs are out.

"Beta tester" isn't the right term for this, because it's
probably already been released. But indeed every system is
bound to be a little different. Sometimes a program is
robust enough to work through the differences, but often it
isn't. But what gripes me is that in some distributions, an
element that's critical to a certain kind of application is
either missing, configured so that it doesn't start
automatically when needed (or just run from boot-up), or, as
apparently was the case in the Ubuntu 10.04 release, the
raw1394 (Firewire host) driver doesn't automatically run as
a security measure (a newbie explanation) and it's necessary
to put it in a group with the right permission to run in
order to make anything that needs access to the Firewire
port work. There's some kernel stuff involved. Details at
eleven, or see https://help.ubuntu.com/community/FireWire if
you really want to know what I'm talking about. But the
bugger is that unless you know enough to look for a clue (or
stumble into the right place to ask your dumb quesiton, the
answer to which starts with "everyone knows that .... "),
you'll probably never find it.




--
"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]

gjsmo wrote:

>>> it's impossible to test every single situation (I can't remember who
>>> proved it). So you can never know that ALL the bugs are out.

> I never said that. But it IS a beta tester's responsibility to FIND
> bugs.

That's if he's really a beta tester. But if he's a user, he
expects that most of the bugs have been found. You might
have a handful of users with system-specific problems, but
not a whole community of users that have the same problem
because of the way a program was written.




--
"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]

Scott Dorsey wrote:

> Why should I have to write my own tools when a proper and reasonable OS
> provides them for me?

Depends on the tools you need. You don't have to write
anything when working in Windows to see if two files are
exactly alike.

> but what if you want to do something the
> average user doesn't want to do? Like care about bit-for-bit accuracy of an
> application for mastering work?

We of the audio community, at any working level from musical
duffer to mastering engineer are not "the average user." Not
the average Windows user, and not the average Linux user
either. At some point, we all want to test our working tools
to see if they're doing what we expect of them. It might be
simply by listening, or it might be doing a bit-by-bit,
word-by-word comparison. Depends on what you're trying to
learn.

--
"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]

gjsmo wrote:

> Someone in the '60s or '70s proved that it was impossible to ever test
> all possible combinations of hardware and software, and therefore it
> was never possible to be sure that ALL the bugs were gone.

I thought everyone understood that. The general policy for
commercial software release is that all "major" bugs are
gone and that there are few enough "annoyance" bugs so that
a significant percentage of the users will never encounter
them. In short, all software that's released has a certain
percentage of bugs.

But remember, every bag of flour also contains a certain
percentage of bugs. The better the processing, the fewer
remain alive before it's packaged. <g>




--
"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

[Bill Graham]

"Mike Rivers" > wrote in message
...
> gjsmo wrote:
>
>> Someone in the '60s or '70s proved that it was impossible to ever test
>> all possible combinations of hardware and software, and therefore it
>> was never possible to be sure that ALL the bugs were gone.
>
> I thought everyone understood that. The general policy for commercial
> software release is that all "major" bugs are gone and that there are few
> enough "annoyance" bugs so that a significant percentage of the users will
> never encounter them. In short, all software that's released has a certain
> percentage of bugs.
>
> But remember, every bag of flour also contains a certain percentage of
> bugs. The better the processing, the fewer remain alive before it's
> packaged. <g>
>
This reminds me of something.....Many years ago, when I was young and
working in San Francisco, there was a ketchup bottling company (whose name I
now forget) that I had as a customer in town. One day, I got off the
elevator at the wrong floor, and saw a small laboratory in the
building...."What are they doing in there" I asked. "Oh, that's where they
measure the worm content of the ketchup", someone told me.....