[Scott Dorsey]

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

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

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

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

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

[Neil Gould]

gjsmo wrote:
On Aug 31, 8:00 am, "Neil Gould" wrote:
Scott Dorsey wrote:
Mike Rivers wrote:

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

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

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

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

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

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

Linux can be poked at, you can recompile the kernel, you can install
different libraries, and do all sorts of things that aren't doable on
Windows.

That's because it's unnecessary to do such things in Windows. As far as pro
audio goes, there are probably more beta testers of any particular product
under Windows than the entire user base of that product under Linux.

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

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

It appears that your experience differs from those of us that actually own
and use pro audio hardware and applications.

--
best regards,

Neil

[Neil Gould]

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

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

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

--
best regards,

Neil

[Mike Rivers]

Scott Dorsey wrote:

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

Ah, what a wonderful life you lead. g

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



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

[gjsmo]

On Aug 31, 8:45*am, Mike Rivers wrote:
gjsmo wrote:
Windows is closed source, so if you want to
find out how something went wrong, you either have to flail around -
or give up and reinstall.

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

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

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

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

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

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

[Neil Gould]

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

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

It is not a beta tester's responsiblity to get out all of the bugs. That's
what manufacturer's tech support is for.

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

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

Programming languages are not the same as pro audio hardware, and do not
present the same issues to users. When one is setting up a computer as a
programming environment, they are expected to have a level of knowledge
sufficient to support such a system.

--
best regards,

Neil

[gjsmo]

On Aug 31, 3:26*pm, "Neil Gould" wrote:
gjsmo wrote:
@Neil
Unless you're a beta tester, this is a pointless exercise, and if
you are a beta tester, you've been provided with the tools and
information to eliminate flailing. So, one way to look at Linux with
pro-anything applications is that all users are actually beta
testers.

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

It is not a beta tester's responsiblity to get out all of the bugs. That's
what manufacturer's tech support is for.

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

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

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

Programming languages are not the same as pro audio hardware, and do not
present the same issues to users. When one is setting up a computer as a
programming environment, they are expected to have a level of knowledge
sufficient to support such a system.

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


--
best regards,

Neil

[Scott Dorsey]

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

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

When I have to deal with things on that level, I write my own tools, too.

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

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

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

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

[Neil Gould]

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

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

When I have to deal with things on that level, I write my own tools,
too.

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

There are tons of tools available for most OSs, and Windows is no exception.

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

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

I hope you aren't implying that an OS will restrict you from doing that, or
that users of a particular OS don't care about bit-for-bit accuracy for
mastering work?

--
best regards,

Neil

[Neil Gould]

gjsmo wrote:
On Aug 31, 3:26 pm, "Neil Gould" wrote:
gjsmo wrote:
@Neil
Unless you're a beta tester, this is a pointless exercise, and if
you are a beta tester, you've been provided with the tools and
information to eliminate flailing. So, one way to look at Linux
with pro-anything applications is that all users are actually beta
testers.

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

It is not a beta tester's responsiblity to get out all of the bugs.
That's what manufacturer's tech support is for.

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

I can understand why a Linux user would think that "Technically, everyone's
a beta tester...", because that's pretty much the nature of Open Source
software. Having been a beta tester for Windows-based pro audio apps, I can
tell you it is nothing like being a _user_ of Windows-based pro audio apps.
No flailing is necessary.

--
best regards,

Neil

[gjsmo]

On Aug 31, 6:39*pm, "Neil Gould" wrote:
gjsmo wrote:
On Aug 31, 3:26 pm, "Neil Gould" wrote:
gjsmo wrote:
@Neil
Unless you're a beta tester, this is a pointless exercise, and if
you are a beta tester, you've been provided with the tools and
information to eliminate flailing. So, one way to look at Linux
with pro-anything applications is that all users are actually beta
testers.

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

It is not a beta tester's responsiblity to get out all of the bugs.
That's what manufacturer's tech support is for.

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

I can understand why a Linux user would think that "Technically, everyone's
a beta tester...", because that's pretty much the nature of Open Source
software. Having been a beta tester for Windows-based pro audio apps, I can
tell you it is nothing like being a _user_ of Windows-based pro audio apps.
No flailing is necessary.

--
best regards,

Neil

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

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

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

[Mike Rivers]

gjsmo wrote:

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

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

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

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




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

[Mike Rivers]

gjsmo wrote:

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

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

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




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

[Mike Rivers]

Scott Dorsey wrote:

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

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

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

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

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

[Mike Rivers]

gjsmo wrote:

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

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

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




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

[Bill Graham]

"Mike Rivers" wrote in message
...
gjsmo wrote:

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

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

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

This reminds me of something.....Many years ago, when I was young and
working in San Francisco, there was a ketchup bottling company (whose name I
now forget) that I had as a customer in town. One day, I got off the
elevator at the wrong floor, and saw a small laboratory in the
building...."What are they doing in there" I asked. "Oh, that's where they
measure the worm content of the ketchup", someone told me.....