[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/lin...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."