Computer or USB Device Issue?

[[email protected]]

Greetings all,

We're having a strange problem with one of our audio production computers & so far, I've not had any luck finding the cause.

We're using Adobe Audition (version 3), with audio input via a Tascam US-122 mkII. The computer is fairly new and more than sufficient to be running Audition. We're not doing multi-track work here....just simple voice recording and editing. The system has been extremely stable and well-behaved over the past year....until now.

Over the last couple sessions, I've noticed strange artifacts appearing in the audio files, when playing them back. The artifacts are in the recorded file, as you hear them when playing the files on other computers, too.

While it's not a very technical sounding term, the best way to describe the artifacts, is that they sound like little "blurps" in the audio. It's not a pop or click....but you do hear it clearly. These will appear randomly scattered through the audio file, typically 30 or so seconds apart.

If you're familiar with Audition--and especially the time stretch function, these artifacts sound very similar to the type you get when trying to digitally time-stretch an audio file a little too far.

I've had our IT guys look at the computer, but both said they can find nothing wrong. It's operating normally and the CPU isn't even breaking a sweat..

The other obvious piece to check is the USB audio device...which I'll do today. Luckily, we do have an identical device I can swap & see if the problem goes away.

I thought I'd also post the question here & see if this type of problem sounds familiar to anyone? If so, what did you find to be the cause? Would a problem like this be more likely caused by the computer or USB device--typically speaking, anyway?

Granted, the Tascam USB device isn't the top of the line, but we've used them for years and have had very good luck. They do what we need to do and don't scare the bean counters--ha ha. I've never had a problem like this before.

Unfortunately, our organization no longer has sufficient tech support in this area. Our IT folks know absolutely nothing about audio production & associated tools & software. While I'm a pretty experienced user....I don't have much experience trouble shooting and solving problems like this. I guess I need to learn, eh?!?!?!

Any suggestions or tips would be most appreciated!

Thanks in advance,

Mike

[John Williamson]

On 12/02/2014 17:41, wrote:
> Greetings all,
>
> We're having a strange problem with one of our audio production computers & so far, I've not had any luck finding the cause.
>
> We're using Adobe Audition (version 3), with audio input via a Tascam US-122 mkII. The computer is fairly new and more than sufficient to be running Audition. We're not doing multi-track work here....just simple voice recording and editing. The system has been extremely stable and well-behaved over the past year....until now.
>
> Over the last couple sessions, I've noticed strange artifacts appearing in the audio files, when playing them back. The artifacts are in the recorded file, as you hear them when playing the files on other computers, too.
>
> While it's not a very technical sounding term, the best way to describe the artifacts, is that they sound like little "blurps" in the audio. It's not a pop or click....but you do hear it clearly. These will appear randomly scattered through the audio file, typically 30 or so seconds apart.
>
> If you're familiar with Audition--and especially the time stretch function, these artifacts sound very similar to the type you get when trying to digitally time-stretch an audio file a little too far.
>
> I've had our IT guys look at the computer, but both said they can find nothing wrong. It's operating normally and the CPU isn't even breaking a sweat.
>
> The other obvious piece to check is the USB audio device...which I'll do today. Luckily, we do have an identical device I can swap & see if the problem goes away.
>
> I thought I'd also post the question here & see if this type of problem sounds familiar to anyone? If so, what did you find to be the cause? Would a problem like this be more likely caused by the computer or USB device--typically speaking, anyway?
>
> Granted, the Tascam USB device isn't the top of the line, but we've used them for years and have had very good luck. They do what we need to do and don't scare the bean counters--ha ha. I've never had a problem like this before.
>
> Unfortunately, our organization no longer has sufficient tech support in this area. Our IT folks know absolutely nothing about audio production & associated tools & software. While I'm a pretty experienced user....I don't have much experience trouble shooting and solving problems like this. I guess I need to learn, eh?!?!?!
>
> Any suggestions or tips would be most appreciated!
>
The wifi or other network may be grabbing control for too long, if the
computer's networked. This can happen when the DHCP server or a network
switch is overloaded or faulty, and responds slowly enough to cause an
audible glitch. This wouldn't show up as a fault on the computer, as
it's only doing what it's been told to by the networking program and OS.


--
Tciao for Now!

John.

[Tom McCreadie]

(PST), wrote:

>Greetings all,
>
>We're having a strange problem with one of our audio production computers & so far, I've not had any luck finding the cause.
>
More info would be helpfiul - OS; memory, pagefile size etc.
Any wireless internet running. Is the Tascam a usb 1.1 or 2.0 device?

Have you already screened for latency issues, using the free utilities?:

1. DPC Latency Checker
http://www.thesycon.de/eng/latency_check.shtml

2. Latency Mon
http://www.resplendence.com/main



--
Tom McCreadie

[Tobiah]

> While it's not a very technical sounding term, the best way to describe the artifacts, is that they sound like little "blurps"

Do you know what a buffer overrun sounds like, and does this "blurp" sound
like that? You say it's not like a "click" but that's really what an overrun
sounds like. If not, then maybe a sample of the audio would be helpful.

Also, try recording with Audacity or Reaper to rule out the software package
you're using.

Tobiah

[Mike Rivers[_2_]]

On 2/12/2014 12:41 PM, wrote:
> Over the last couple sessions, I've noticed strange artifacts
> appearing in the audio files, when playing them back. The artifacts
> are in the recorded file, as you hear them when playing the files on
> other computers, too.
>
> While it's not a very technical sounding term, the best way to
> describe the artifacts, is that they sound like little "blurps" in
> the audio. It's not a pop or click....but you do hear it clearly.
> These will appear randomly scattered through the audio file,
> typically 30 or so seconds apart.

Get the computer off any networks. Disable the network adapter and the
WiFi adapter and then see if the blurps go away. Anything that's close
to periodic like that either has to do with the computer trying to do
something with a network or it's something built into a trial or
unregistered version of a program or plug-in that keeps you from using
it in an actual project (unless it's a very short project). Since you've
been using Audition for a while, it's probably not that. Have you
inserted a plug-in?

Other dumb things to do that sometimes fix problems like this:

Assuming you're using the ASIO driver for your USB interface, re-install
it. Check for an update first.

Defragment the disk drive

Turn off the computer, pull the power plug (don't skip this step), leave
it alone for 15-30 minutes to meditate in peace, then plug it in and
restart.



--
For a good time, visit http://mikeriversaudio.wordpress.com

[Frank Stearns]

Mike Rivers > writes:

snips

>Turn off the computer, pull the power plug (don't skip this step), leave
>it alone for 15-30 minutes to meditate in peace, then plug it in and
>restart.

This sounds nutty as hell, but it really does often help. Typically, though, 3-5
minutes should be okay using the "real off" switch on the back of the PSU (not the
soft-off of the OS).

Have not run into the 15-30 minute/plug pull idea before. Mike, have you run into
situations where the longer time and plug pull was needed "purge demons"?

(I can see the plug pull being useful if there is no hard break of the AC into the
PSU.)

Frank
Mobile Audio

[jason]

On Wed, 12 Feb 2014 16:08:44 -0500 "Mike Rivers" > wrote
in article >

>
> Turn off the computer, pull the power plug (don't skip this step), leave
> it alone for 15-30 minutes to meditate in peace, then plug it in and
> restart.

After you unplug the computer, press the power button too to discharge
what's left in the power supply caps.

[PStamler]

How do you have the buffering set in Audition? I've occasionally had it hiccup with buffering levels that were more than enough for other software.

Peace,
Paul

[Peter Larsen[_3_]]

wrote:

> Greetings all,

> We're having a strange problem with one of our audio production
> computers & so far, I've not had any luck finding the cause.

> We're using Adobe Audition (version 3), with audio input via a Tascam
> US-122 mkII. The computer is fairly new and more than sufficient to
> be running Audition. We're not doing multi-track work here....just
> simple voice recording and editing. The system has been extremely
> stable and well-behaved over the past year....until now.

Undefined variables: operating system, as others mentioned networking and as
others didn't mention last time I read this thread: grapnics card setup and
disk setup.

> Over the last couple sessions, I've noticed strange artifacts
> appearing in the audio files, when playing them back. The artifacts
> are in the recorded file, as you hear them when playing the files on
> other computers, too.

Undefined: is this about recorded audio or about processed audio or about
audio that is played back.

> While it's not a very technical sounding term, the best way to
> describe the artifacts, is that they sound like little "blurps" in
> the audio. It's not a pop or click....but you do hear it clearly.
> These will appear randomly scattered through the audio file,
> typically 30 or so seconds apart.

How do they look on screen? - what happens every 30 seconds on this
computer? - is this during recording, playback or after processing? - look
for either a hole in the file, that would be buffer underrun, or a
discontinuity that is caused by buffer overrun, ie. missing data. Both are
only possible during recording.

> If you're familiar with Audition--and especially the time stretch
> function, these artifacts sound very similar to the type you get when
> trying to digitally time-stretch an audio file a little too far.

Very long time ago I encountered distortion of processed audio files in Cool
Edit 2000 running on a P2-300. As I recall pulling the network cable solved
it. But that was not gulps, it was distortion on clarinet but not on drums
when processing a jazz recording.

> I've had our IT guys look at the computer, but both said they can
> find nothing wrong. It's operating normally and the CPU isn't even
> breaking a sweat.

Note: problem is mostly not described, OS is unknown, generally however what
will make the Windows OS wait for something is a network drive that should
show up but doesn't.

> The other obvious piece to check is the USB audio device...which I'll
> do today. Luckily, we do have an identical device I can swap & see
> if the problem goes away.

USB audio device? ... all bets are off and remain off in case it doesn't
work. Is scanner software installed, scanner software that checks for a
scanner that is turned off can behave very very very very very badly. What
is that device used for? - if for playback the internal sound card may be
quite acceptable.

> I thought I'd also post the question here & see if this type of
> problem sounds familiar to anyone? If so, what did you find to be
> the cause? Would a problem like this be more likely caused by the
> computer or USB device--typically speaking, anyway?

USB bus first suspect, it has all kinds of management things going on.

> Granted, the Tascam USB device isn't the top of the line, but we've
> used them for years and have had very good luck. They do what we
> need to do and don't scare the bean counters--ha ha. I've never had
> a problem like this before.

You also didn't tell us what bus-options there is inside the box, PCI audio
cards are not all that costly. USB audio playback usually is unproblematic,
USB audio recording problems AND nothing present on the USB bus other than
the audio card would have me looking for an alternative computer. There is
however the dark horse of indexing running on the computer, a "first thing"
with recent windows OS's is to disable indexing.

> Unfortunately, our organization no longer has sufficient tech support
> in this area. Our IT folks know absolutely nothing about audio
> production & associated tools & software. While I'm a pretty
> experienced user....I don't have much experience trouble shooting and
> solving problems like this. I guess I need to learn, eh?!?!?!

Well, do you at all have adminstrator access to the computer in question?

> Any suggestions or tips would be most appreciated!

Tell us what the conditions are for the problem to be triggered, ie. what
are you trying to do. Also answer question number one of all
troubleshooting: did it ever work?

> Thanks in advance,

> Mike

Kind regards

Peter Larsen

[Peter Larsen[_3_]]

Mike Rivers wrote:

> On 2/12/2014 12:41 PM, wrote:
>> Over the last couple sessions, I've noticed strange artifacts
>> appearing in the audio files, when playing them back. The artifacts
>> are in the recorded file, as you hear them when playing the files on
>> other computers, too.

>> While it's not a very technical sounding term, the best way to
>> describe the artifacts, is that they sound like little "blurps" in
>> the audio. It's not a pop or click....but you do hear it clearly.
>> These will appear randomly scattered through the audio file,
>> typically 30 or so seconds apart.

Mike is to the point here:

> Get the computer off any networks. Disable the network adapter and the
> WiFi adapter and then see if the blurps go away. Anything that's close
> to periodic like that either has to do with the computer trying to do
> something with a network or it's something built into a trial or
> unregistered version of a program or plug-in that keeps you from using
> it in an actual project (unless it's a very short project). Since
> you've been using Audition for a while, it's probably not that. Have
> you inserted a plug-in?

> Other dumb things to do that sometimes fix problems like this:

> Assuming you're using the ASIO driver for your USB interface,
> re-install it. Check for an update first.

> Defragment the disk drive

> Turn off the computer, pull the power plug (don't skip this step),
> leave it alone for 15-30 minutes to meditate in peace, then plug it
> in and restart.

AND then enter bios options and disable all mobo facilities that are not
used such as serial and/or parallel ports and - since external audio is
used - mobo audio facilities. Or perhaps first try loading factory defaults
.... O;-)

Kind regards

Peter Larsen

[Mike Rivers[_2_]]

On 2/12/2014 7:37 PM, Frank Stearns wrote:
> Have not run into the 15-30 minute/plug pull idea before. Mike, have you run into
> situations where the longer time and plug pull was needed "purge demons"?

No, but I try not to be too impatient when I'm frustrated with a
computer problem. So I pull the plug (most of my computers don't have a
real power switch) and go read the newspaper or eat lunch.

I suppose that if it's a laptop or some other battery powered computer,
you'd want to remove the battery. In fact, in the days when people were
first starting to use laptops for audio, one of the tricks to eliminate
skips and mutes was to remove the battery and operate it on AC, or
remove the AC power and operate it on battery only. When there's power
and a battery, they keep checking to see if the battery needs charging.
It's the same kind of effect as the WiFi continuously looking for a
connection (or a better connection) when the Windows Zero Configuration
Wireless service is enabled. This is on by default in a standard Windows
installation.



--
For a good time, visit http://mikeriversaudio.wordpress.com

[[email protected]]

On Wednesday, February 12, 2014 11:41:42 AM UTC-6, wrote:
> Greetings all,
>
>
>
> We're having a strange problem with one of our audio production computers & so far, I've not had any luck finding the cause.
>
>
>
> We're using Adobe Audition (version 3), with audio input via a Tascam US-122 mkII. The computer is fairly new and more than sufficient to be running Audition. We're not doing multi-track work here....just simple voice recording and editing. The system has been extremely stable and well-behaved over the past year....until now.
>
>
>
> Over the last couple sessions, I've noticed strange artifacts appearing in the audio files, when playing them back. The artifacts are in the recorded file, as you hear them when playing the files on other computers, too.
>
>
>
> While it's not a very technical sounding term, the best way to describe the artifacts, is that they sound like little "blurps" in the audio. It's not a pop or click....but you do hear it clearly. These will appear randomly scattered through the audio file, typically 30 or so seconds apart.
>
>
>
> If you're familiar with Audition--and especially the time stretch function, these artifacts sound very similar to the type you get when trying to digitally time-stretch an audio file a little too far.
>
>
>
> I've had our IT guys look at the computer, but both said they can find nothing wrong. It's operating normally and the CPU isn't even breaking a sweat.
>
>
>
> The other obvious piece to check is the USB audio device...which I'll do today. Luckily, we do have an identical device I can swap & see if the problem goes away.
>
>
>
> I thought I'd also post the question here & see if this type of problem sounds familiar to anyone? If so, what did you find to be the cause? Would a problem like this be more likely caused by the computer or USB device--typically speaking, anyway?
>
>
>
> Granted, the Tascam USB device isn't the top of the line, but we've used them for years and have had very good luck. They do what we need to do and don't scare the bean counters--ha ha. I've never had a problem like this before.
>
>
>
> Unfortunately, our organization no longer has sufficient tech support in this area. Our IT folks know absolutely nothing about audio production & associated tools & software. While I'm a pretty experienced user....I don't have much experience trouble shooting and solving problems like this. I guess I need to learn, eh?!?!?!
>
>
>
> Any suggestions or tips would be most appreciated!
>
>
>
> Thanks in advance,
>
>
>
> Mike




Thanks to everyone for your replies---much appreciated! It seems that the problem has revealed its self, more or less.

This morning....the computer won't respond to anything. No USB power coming out...keyboard, monitor and mouse dead, etc. Hard restart, complete with pulling the power....still nothing.

This is something our IT guys know how to deal with....and, I just have to suspect this is directly related to the audio blurps we were getting before the complete failure.

Thanks again!

Mike

[Les Cargill[_4_]]

wrote:
> On Wednesday, February 12, 2014 11:41:42 AM UTC-6,
<snip>
> This morning....the computer won't respond to anything.



> No USB power coming out...

Uh oh. So put a meter on 5V throughout the system. Somebody
had something like this recently, and it was still cap rot from 10+
years ago.

> keyboard, monitor and mouse dead, etc. Hard restart,
> complete with pulling the power....still nothing.
>
> This is something our IT guys know how to deal with....and, I just
> have to suspect this is directly related to the audio blurps we were
> getting before the complete failure.
>
> Thanks again!
>
> Mike
>

--
Les Cargill

[Mike Rivers[_2_]]

On 2/13/2014 1:21 PM, Les Cargill wrote:

>> No USB power coming out...

> Uh oh. So put a meter on 5V throughout the system. Somebody
> had something like this recently, and it was still cap rot from 10+
> years ago.

Since there's "IT guys" involved, I suspect the solution will be a new
computer or a new motherboard (many of them aren't smart enough to check
the power supply first).

--
For a good time, visit http://mikeriversaudio.wordpress.com

[Scott Dorsey]

Jason > wrote:
>On Wed, 12 Feb 2014 16:08:44 -0500 "Mike Rivers" > wrote
>in article >
>
>>
>> Turn off the computer, pull the power plug (don't skip this step), leave
>> it alone for 15-30 minutes to meditate in peace, then plug it in and
>> restart.
>
>After you unplug the computer, press the power button too to discharge
>what's left in the power supply caps.

Then apply a claymore fragmentation grenade!
--scott

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

[Scott Dorsey]

In article >, Mike Rivers > wrote:
>On 2/13/2014 1:21 PM, Les Cargill wrote:
>
>>> No USB power coming out...
>
>> Uh oh. So put a meter on 5V throughout the system. Somebody
>> had something like this recently, and it was still cap rot from 10+
>> years ago.
>
>Since there's "IT guys" involved, I suspect the solution will be a new
>computer or a new motherboard (many of them aren't smart enough to check
>the power supply first).

Q. How can you tell a DEC FE with a flat tire?

A. He's the one in the parking lot swapping all the tires with the spare
to see which one is flat.

Q. What if he has two flat tires?

A. He replaces the alternator.
--scott

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

[[email protected]]

On Thursday, February 13, 2014 3:56:40 PM UTC-6, Mike Rivers wrote:
> On 2/13/2014 1:21 PM, Les Cargill wrote:
>
>
>
> >> No USB power coming out...
>
>
>
> > Uh oh. So put a meter on 5V throughout the system. Somebody
>
> > had something like this recently, and it was still cap rot from 10+
>
> > years ago.
>
>
>
> Since there's "IT guys" involved, I suspect the solution will be a new
>
> computer or a new motherboard (many of them aren't smart enough to check
>
> the power supply first).
>
>
>
> --
>
> For a good time, visit http://mikeriversaudio.wordpress.com



Actually, it turned out to be a bad video card, of all things. Apparently, when the card failed, the computer killed USB power, too.

The computer is still under warranty, so a new card is on the way. We were lucky enough to have a compatible spare on hand & are back up and running.

So far....no more "blurps" in the audio, either.

Mike

[William Sommerwerck]

wrote in message ...

> Actually, it turned out to be a bad video card, of all things.
> Apparently, when the card failed, the computer killed USB power, too.

From experience, I know that sometimes the only way to fix something is to
"try everything". How did you isolate the video card?

[[email protected]]

On Friday, February 14, 2014 10:11:34 AM UTC-6, William Sommerwerck wrote:
> wrote in message ...
>
>
>
> > Actually, it turned out to be a bad video card, of all things.
>
> > Apparently, when the card failed, the computer killed USB power, too.
>
>
>
> From experience, I know that sometimes the only way to fix something is to
>
> "try everything". How did you isolate the video card?



That was our IT guy....not sure how he found it. Luckily, he's sharper than some IT folks I've worked with in the past....

Mike

[hank alrich]

Scott Dorsey > wrote:

> In article >, Mike Rivers >
> wrote: >On 2/13/2014 1:21 PM, Les Cargill wrote: > >>> No USB power coming
> out... > >> Uh oh. So put a meter on 5V throughout the system. Somebody >>
> had something like this recently, and it was still cap rot from 10+ >>
> years ago. > >Since there's "IT guys" involved, I suspect the solution
> will be a new >computer or a new motherboard (many of them aren't smart
> enough to check >the power supply first).
>
> Q. How can you tell a DEC FE with a flat tire?
>
> A. He's the one in the parking lot swapping all the tires with the spare
> to see which one is flat.
>
> Q. What if he has two flat tires?
>
> A. He replaces the alternator.
> --scott

Damn, that's good!

--
shut up and play your guitar * HankAlrich.Com
HankandShaidriMusic.Com
YouTube.Com/WalkinayMusic

[Scott Dorsey]

hank alrich > wrote:
>Scott Dorsey > wrote:
>>
>> Q. How can you tell a DEC FE with a flat tire?
>>
>> A. He's the one in the parking lot swapping all the tires with the spare
>> to see which one is flat.
>>
>> Q. What if he has two flat tires?
>>
>> A. He replaces the alternator.
>
>Damn, that's good!

It's not original, and sadly it's probably true.

Do a google search on "always mount a scratch monkey."
--scott

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

[hank alrich]

Scott Dorsey > wrote:

> hank alrich > wrote:
> >Scott Dorsey > wrote:
> >>
> >> Q. How can you tell a DEC FE with a flat tire?
> >>
> >> A. He's the one in the parking lot swapping all the tires with the spare
> >> to see which one is flat.
> >>
> >> Q. What if he has two flat tires?
> >>
> >> A. He replaces the alternator.
> >
> >Damn, that's good!
>
> It's not original, and sadly it's probably true.
>
> Do a google search on "always mount a scratch monkey."

http://edp.org/monkey.htm

--
shut up and play your guitar * HankAlrich.Com
HankandShaidriMusic.Com
YouTube.Com/WalkinayMusic

[Trevor]

Scott Dorsey > wrote:
> Q. How can you tell a DEC FE with a flat tire?
> A. He's the one in the parking lot swapping all the tires with the spare
> to see which one is flat.
> Q. What if he has two flat tires?
> A. He replaces the alternator.

Nah, he replaces the car.

Trevor.

[Mike Rivers[_2_]]

On 2/15/2014 10:44 PM, hank alrich wrote:

> http://edp.org/monkey.htm

"five monkeys were fitted with caps intended to sense brain waves, and
the caps were attached to various A-to-D and D-to-A converters (which
were US Army surplus from 1956) which were in turn connected to the VAX. "

Those must have been tube A/D and D/A converters. I'll bet someone paid
a lot of money for them in 1996.



--
For a good time, visit http://mikeriversaudio.wordpress.com

[William Sommerwerck]

>> http://edp.org/monkey.htm

>> "five monkeys were fitted with caps intended to sense brain waves, and
>> the caps were attached to various A-to-D and D-to-A converters (which
>> were US Army surplus from 1956) which were in turn connected to the VAX."

> Those must have been tube A/D and D/A converters. I'll bet someone paid a
> lot of money for them in 1996.

I often say I'd rather be wrong because I applied common sense, than be right
because I blindly believed something that made no sense at all.

Surplus vacuum-tube ADCs and DACs? Yeah. Sure. Especially when solid-state
versions would have been available, probably for a few dollars apiece.

As for the test software pumping so much voltage into the monkey's brains that
it killed three of them... It would have had to have come from the DACs,
right? Are you telling me that whoever designed the system was so stupid that
they didn't place a voltage divider across the DAC's output to keep the
stimulus to a safe level, even if the DAC went full-scale?

People will swallow anything. This is urban-legend crap from beginning to end.

[Les Cargill[_4_]]

William Sommerwerck wrote:
>>> http://edp.org/monkey.htm
>
>>> "five monkeys were fitted with caps intended to sense brain waves, and
>>> the caps were attached to various A-to-D and D-to-A converters (which
>>> were US Army surplus from 1956) which were in turn connected to the
>>> VAX."
>
>> Those must have been tube A/D and D/A converters. I'll bet someone
>> paid a lot of money for them in 1996.
>
> I often say I'd rather be wrong because I applied common sense, than be
> right because I blindly believed something that made no sense at all.
>
> Surplus vacuum-tube ADCs and DACs? Yeah. Sure. Especially when
> solid-state versions would have been available, probably for a few
> dollars apiece.
>

Mike's describing the numismatic value of them, not the real value
as machinery. This value is derived from the improbability that they
exist at all, not from functional utility.

It's like how people cut up Ampex tape machines for the "tube preamps".

> As for the test software pumping so much voltage into the monkey's
> brains that it killed three of them... It would have had to have come
> from the DACs, right? Are you telling me that whoever designed the
> system was so stupid that they didn't place a voltage divider across the
> DAC's output to keep the stimulus to a safe level, even if the DAC went
> full-scale?

They might have been. It's a classic error in engineering not to take
into account what happens when things crash.

We're all stupid. Some of us are just a bit better at hiding it than
others, or have built up experience that helps us find the rocks
under the water.

Experience is what you get when you don't get what you wanted in the
first place.

>
> People will swallow anything. This is urban-legend crap from beginning
> to end.

SO what's wrong with that? It's like a zen koan; there's a kernel
of truth to it whether it happened or not.

There is a Star Trek Next Generation episode titled "Darmok"; in it,
the crew encounters a species that only uses a phenomenally large array
of historical references as language. Picard, in the "explorer" mode
finally unravels this system. You and I are used to language that
doesn't work this way but I bet our hunter-gatherer ancestors *did*
work that way - I think Egyptian cartouches are a lot that way.

http://en.memory-alpha.org/wiki/Darmok_%28episode%29

Humans operate on stories, not facts. Facts are just stories that are
reproducible or have better-than-average provenance.

Indeed, in flight controls or in medical device engineering, the money
goes into maintaining the chains of evidence of how things were
designed. That's a story, albeit a very structured story.

--
Les Cargill

[William Sommerwerck]

"Les Cargill" wrote in message ...

<useful clarifications snipped>

>> People will swallow anything. This is urban-legend crap
>> from beginning to end.

> So what's wrong with that? It's like a zen koan; there's a kernel
> of truth to it whether it happened or not.

True.


> There is a Star Trek Next Generation episode titled "Darmok"; in it,
> the crew encounters a species that only uses a phenomenally large
> array of historical references as language. Picard, in the "explorer"
> mode finally unravels this system. You and I are used to language
> that doesn't work this way but I bet our hunter-gatherer ancestors
> *did* work that way --

http://en.memory-alpha.org/wiki/Darmok_%28episode%29

"Darmok" is generally considered one of the best TNG episodes. But it has a
fundamental error at its heart. All languages use metaphor or "figures of
speech" that aren't directly translatable. For a universal translator to work,
it would have to be able to handle these. That the Federation's universal
translator gets the Tamarian words right -- but not their deeper meaning --
makes no sense.


> I think Egyptian cartouches are a lot that way.

The cartouche indicated that the symbols within it represented a name.


> Humans operate on stories, not facts. Facts are just stories that
> are reproducible or have better-than-average provenance.

Interesting point. McKee makes a similar observation in "Story".


> Indeed, in flight controls or in medical device engineering, the money
> goes into maintaining the chains of evidence of how things were
> designed. That's a story, albeit a very structured story.

When I write user documentation, I often remind myself that I'm actually
telling a story.

[Les Cargill[_4_]]

William Sommerwerck wrote:
> "Les Cargill" wrote in message ...
>
> <useful clarifications snipped>
>
>>> People will swallow anything. This is urban-legend crap
>>> from beginning to end.
>
>> So what's wrong with that? It's like a zen koan; there's a kernel
>> of truth to it whether it happened or not.
>
> True.
>
>
>> There is a Star Trek Next Generation episode titled "Darmok"; in it,
>> the crew encounters a species that only uses a phenomenally large
>> array of historical references as language. Picard, in the "explorer"
>> mode finally unravels this system. You and I are used to language
>> that doesn't work this way but I bet our hunter-gatherer ancestors
>> *did* work that way --
>
> http://en.memory-alpha.org/wiki/Darmok_%28episode%29
>
> "Darmok" is generally considered one of the best TNG episodes. But it
> has a fundamental error at its heart.

Of course it does. All stories do :)

> All languages use metaphor or
> "figures of speech" that aren't directly translatable. For a universal
> translator to work, it would have to be able to handle these. That the
> Federation's universal translator gets the Tamarian words right -- but
> not their deeper meaning -- makes no sense.
>

http://www.spreadshirt.com/darmok-and-jalad-at-tanagra-C3376A10756347
My kids got me that t-shirt for xmas 20122 :)

The idea is that for some reason, they grew up as a species
with a language that retained the metaphoric quality beyond
the ability of the translator to pick it apart. Data and Troi
were identifying historical figures named in the exchanges, but
since the stories themselves were the most important part, and they
didn't know them, Picard's innovation was to work that out.

It is as if we adapted our language around things like the Iliad
without the other styles of prose that emerged.

Since we don't actually understand completely hows we "do" language,
I found the story compelling. *Our* way of doing it, although
the best we've ever seen, is probably extremely path-dependent.

>
>> I think Egyptian cartouches are a lot that way.
>
> The cartouche indicated that the symbols within it represented a name.
>

True enough, but they're also used to represent events. SFAIK.
I think Egyptian as written is some pictographic ( as Chinese is )
and some abstract, in mixture.

>
>> Humans operate on stories, not facts. Facts are just stories that
>> are reproducible or have better-than-average provenance.
>
> Interesting point. McKee makes a similar observation in "Story".
>

Huh. The Campbell myth books do to, although I think he invests
myth with qualities above it's use.

Mine's more a anthropological sort of point. *Our* emphasis on fact
and reason is fairly new. Stories are our base-layer.

>
>> Indeed, in flight controls or in medical device engineering, the money
>> goes into maintaining the chains of evidence of how things were
>> designed. That's a story, albeit a very structured story.
>
> When I write user documentation, I often remind myself that I'm actually
> telling a story.

--
Les Cargill

[Sean Conolly]

"Les Cargill" > wrote in message
...
> William Sommerwerck wrote:
>> "Les Cargill" wrote in message ...
>>
>> <useful clarifications snipped>
>>
>>>> People will swallow anything. This is urban-legend crap
>>>> from beginning to end.
>>
>>> So what's wrong with that? It's like a zen koan; there's a kernel
>>> of truth to it whether it happened or not.
>>
>> True.
>>
>>
>>> There is a Star Trek Next Generation episode titled "Darmok"; in it,
>>> the crew encounters a species that only uses a phenomenally large
>>> array of historical references as language. Picard, in the "explorer"
>>> mode finally unravels this system. You and I are used to language
>>> that doesn't work this way but I bet our hunter-gatherer ancestors
>>> *did* work that way --
>>
>> http://en.memory-alpha.org/wiki/Darmok_%28episode%29
>>
>> "Darmok" is generally considered one of the best TNG episodes. But it
>> has a fundamental error at its heart.
>
> Of course it does. All stories do :)
>
>> All languages use metaphor or
>> "figures of speech" that aren't directly translatable. For a universal
>> translator to work, it would have to be able to handle these. That the
>> Federation's universal translator gets the Tamarian words right -- but
>> not their deeper meaning -- makes no sense.
>>
>
> http://www.spreadshirt.com/darmok-and-jalad-at-tanagra-C3376A10756347
> My kids got me that t-shirt for xmas 20122 :)
>
> The idea is that for some reason, they grew up as a species
> with a language that retained the metaphoric quality beyond
> the ability of the translator to pick it apart. Data and Troi
> were identifying historical figures named in the exchanges, but
> since the stories themselves were the most important part, and they
> didn't know them, Picard's innovation was to work that out.
>
> It is as if we adapted our language around things like the Iliad
> without the other styles of prose that emerged.
>
> Since we don't actually understand completely hows we "do" language,
> I found the story compelling. *Our* way of doing it, although
> the best we've ever seen, is probably extremely path-dependent.
>
>>
>>> I think Egyptian cartouches are a lot that way.
>>
>> The cartouche indicated that the symbols within it represented a name.
>>
>
> True enough, but they're also used to represent events. SFAIK.
> I think Egyptian as written is some pictographic ( as Chinese is )
> and some abstract, in mixture.
>
>>
>>> Humans operate on stories, not facts. Facts are just stories that
>>> are reproducible or have better-than-average provenance.
>>
>> Interesting point. McKee makes a similar observation in "Story".
>>
>
> Huh. The Campbell myth books do to, although I think he invests
> myth with qualities above it's use.
>
> Mine's more a anthropological sort of point. *Our* emphasis on fact
> and reason is fairly new. Stories are our base-layer.
>
>>
>>> Indeed, in flight controls or in medical device engineering, the money
>>> goes into maintaining the chains of evidence of how things were
>>> designed. That's a story, albeit a very structured story.
>>
>> When I write user documentation, I often remind myself that I'm actually
>> telling a story.
>
> --
> Les Cargill

I'm having a hard time following this since English is a second language for
me. Is there anyone here who can translate to Redneck for me?

Sean

[Les Cargill[_4_]]

Sean Conolly wrote:
> "Les Cargill" > wrote in message
> ...
>> William Sommerwerck wrote:
>>> "Les Cargill" wrote in message ...
>>>
>>> <useful clarifications snipped>
>>>
>>>>> People will swallow anything. This is urban-legend crap
>>>>> from beginning to end.
>>>
>>>> So what's wrong with that? It's like a zen koan; there's a kernel
>>>> of truth to it whether it happened or not.
>>>
>>> True.
>>>
>>>
>>>> There is a Star Trek Next Generation episode titled "Darmok"; in it,
>>>> the crew encounters a species that only uses a phenomenally large
>>>> array of historical references as language. Picard, in the "explorer"
>>>> mode finally unravels this system. You and I are used to language
>>>> that doesn't work this way but I bet our hunter-gatherer ancestors
>>>> *did* work that way --
>>>
>>> http://en.memory-alpha.org/wiki/Darmok_%28episode%29
>>>
>>> "Darmok" is generally considered one of the best TNG episodes. But it
>>> has a fundamental error at its heart.
>>
>> Of course it does. All stories do :)
>>
>>> All languages use metaphor or
>>> "figures of speech" that aren't directly translatable. For a universal
>>> translator to work, it would have to be able to handle these. That the
>>> Federation's universal translator gets the Tamarian words right -- but
>>> not their deeper meaning -- makes no sense.
>>>
>>
>> http://www.spreadshirt.com/darmok-and-jalad-at-tanagra-C3376A10756347
>> My kids got me that t-shirt for xmas 20122 :)
>>
>> The idea is that for some reason, they grew up as a species
>> with a language that retained the metaphoric quality beyond
>> the ability of the translator to pick it apart. Data and Troi
>> were identifying historical figures named in the exchanges, but
>> since the stories themselves were the most important part, and they
>> didn't know them, Picard's innovation was to work that out.
>>
>> It is as if we adapted our language around things like the Iliad
>> without the other styles of prose that emerged.
>>
>> Since we don't actually understand completely hows we "do" language,
>> I found the story compelling. *Our* way of doing it, although
>> the best we've ever seen, is probably extremely path-dependent.
>>
>>>
>>>> I think Egyptian cartouches are a lot that way.
>>>
>>> The cartouche indicated that the symbols within it represented a name.
>>>
>>
>> True enough, but they're also used to represent events. SFAIK.
>> I think Egyptian as written is some pictographic ( as Chinese is )
>> and some abstract, in mixture.
>>
>>>
>>>> Humans operate on stories, not facts. Facts are just stories that
>>>> are reproducible or have better-than-average provenance.
>>>
>>> Interesting point. McKee makes a similar observation in "Story".
>>>
>>
>> Huh. The Campbell myth books do to, although I think he invests
>> myth with qualities above it's use.
>>
>> Mine's more a anthropological sort of point. *Our* emphasis on fact
>> and reason is fairly new. Stories are our base-layer.
>>
>>>
>>>> Indeed, in flight controls or in medical device engineering, the money
>>>> goes into maintaining the chains of evidence of how things were
>>>> designed. That's a story, albeit a very structured story.
>>>
>>> When I write user documentation, I often remind myself that I'm actually
>>> telling a story.
>>
>> --
>> Les Cargill
>
> I'm having a hard time following this since English is a second language for
> me. Is there anyone here who can translate to Redneck for me?
>
> Sean
>
>

Probably not. Andy Griffith is ... not available :)

--
Les Cargill