[[email protected]]

thanks for all the insight guys. 64 bit word length would be a "true"
64 bit processor to me. but i'm not half as smart as many people
around here. i'm excited about massive amounts of ram, so your drives
can stay idle. they even have some cool stuff like you can put a usb
mini storage stick into the computer and tell it to be ram. it's not
as fast as the dedicated system ram, but i like where the future is
headed (more cores, more bits, more based around ram)

since i'm in the market for a new computer, as of jan 29, literally
overnight, it all changed over to vista. i'm going to get a tablet pc
unless i can be convinced otherwise, and that market is now instantly
dominated by vista.

[Mogens V.]

Emiliano Grilli wrote:
On 10 Feb, 15:58, "Mogens V." wrote:

Thanks. I've cut the excess and kept your pointers for those who might
be interested in following them.


ALSA is powerful, but complicated to setup if you want to do something
different from the default. OTOH, once your soundcard is supported it
will work out of the box without installing drivers, and with ANY
linux distro. That if you ask me is a _great_ benefit, and a warranty
on your hardware purchase. I have soo bad experiences with closed
source drivers (namely gadgetlabs wave 824 and opcode studio64) that I
won't put my hard-earned money anymore into a peripheral that doesn't
have an open source driver.

Jack and realtime operation is even more demanding since it needs a
patched kernel to achieve the best performance for the lowest latency.

That's a minor problem for me, but might be for others, depending on
their kernel experiences.

Do give me a couple of pointers to the late progression using Linux for
a DAW installation, i.e. distro, apps, audio routing deamon et al, and
I'll take a fresh look.


The most "audio friendly" and up to date debian based distro is
64studio:

http://www.64studio.com

They have both 64 bit and 32 bit versions.

Use qjackctl to control jackd daemon and audio routing. Ardour as DAW.
Rosegarden or muse as sequencer (synced via jack_transport),
linuxsampler to play GIG files, zynaddsubfx as synth, jamin for
mastering, audacity or rezound as audio editors.

Need to do audio in batches? Try ecasound, sox, timidity, lame,
oggenc, ...

Then if you want to go experimental, try csound, puredata,
supercollider.

Apps are really not as mature as the windows commercial apps, but they
do their work fairly well. Ardour has been rock solid for me, and more
powerful than I ever needed.

LADSPA plugins do not have the eye candy (in fact, they don't have a
fixed GUI at all) but some are good sounding, and there are plenty of
them.
...snip..
Open formats are one of the main advantages of free software, as you
probably know. Ardour uses 32 bit broadcast wave files, and human
readable XML for the project file. Moreover, the app is free so
everyone can legally install it (it's also available for mac OS X) and
use your projects without problems, including effects, automation, and
so on. No windows version so far, though.

Speaking of other session interchange formats, Paul Davis (ardour's
author) said:

"We are slowly working on support for AAF, which is about the only
standard for session files worth paying attention to (OMF is
widespread because of ProTools but its also proprietary and is hard
for us to support)."
...snip..
Check http://ardour.org forums. They are plenty of people using
ardour... maybe they're not high end professionals, but the community
is growing, and the app in my opinion is well worth to keep an eye on.
...snip..
Try 64studio. You might be surprised :-)

I'd missed that one. Thanks for all pointers.
I'll take a fresh look sometime soon. Need to finish a new server, then
my current combined server/workstation will be free for trying it out.

--
Kind regards,
Mogens V.

[Arny Krueger]

"Romeo Rondeau" wrote in message
t
And this movie plays itself out every time a new OS is
introduced...

And it will again, but probably pretty slowly, becasue
XP is far more competent than any *obsolete* OS we ever
had before. There is a 64 bit flavor of XP on the
market, BTW.

I'll bet you it plays out exactly like it always has.
When folks buy new PC's, they will have Vista on them.

Right now they often have a choice.

That in itself will take care of it... like it always
has. There is nothing different about Vista than other
operating systems. Some users will wait a long time, some
will stand in line outside the store the night before the
launch (like they did this time), it happens every time.

Agreed.

[Arny Krueger]

wrote in message

wrote:
Hello,

This is sort of off-topic, but not.

I'm in the market for a new computer with Vista. I
can't for the life of me figure out if the Intel Core 2
Duo is a true 64 bit processor, a fake one, or nothing
at all to do with 32 bit.

Define "a true 64 bit processor"

64 bit datapaths?

or greater. For example, 32 bit processors with 64 and 128 bit data paths
are old hat.

64 bit addressing?

An absolute must. But, I'm not sure that anybody has a compelling reason to
go further for address space or main memory adressing with a mainstream
processor. IPV6 uses 128 bit addresses, but they are something different.

64 bit functional units?

or greater. For example, 32 bit processors with 64 and 128 bit functional
units are old hat.

[Romeo Rondeau]

Arny Krueger wrote:
"Romeo Rondeau" wrote in message
t
And this movie plays itself out every time a new OS is
introduced...
And it will again, but probably pretty slowly, becasue
XP is far more competent than any *obsolete* OS we ever
had before. There is a 64 bit flavor of XP on the
market, BTW.
I'll bet you it plays out exactly like it always has.
When folks buy new PC's, they will have Vista on them.

Right now they often have a choice.

It's only been out for a few days...

[Richard Crowley]

"Romeo Rondeau" wrote ...
Arny Krueger wrote:
"Romeo Rondeau" wrote
And this movie plays itself out every time a new OS is
introduced...
And it will again, but probably pretty slowly, becasue
XP is far more competent than any *obsolete* OS we ever
had before. There is a 64 bit flavor of XP on the
market, BTW.
I'll bet you it plays out exactly like it always has.
When folks buy new PC's, they will have Vista on them.

Right now they often have a choice.

It's only been out for a few days...

Thanks for the warning. if I'm going to get a new laptop, I'd
better do it soon while they are still bundling XP with them.

[tonewheel]

On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).


This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

TWJ

[Arny Krueger]

"tonewheel" wrote in message
ups.com...
On 9 Feb, 15:03, "Take Vos" wrote:

- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).

This is not a new feature of 64 bit architectures.

Agreed.

Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.


Win95 and Win98 did memory-mapped I/O. Memory-mapped I/O has major
performance implications for executable code.

[Take Vos]

Hello TWJ,

- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).
This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.
Yes, memory mapped I/O is incredibly old, but I meant it would be more
useful with a 64 bit address space when working on large audio files.

In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio
buffers and other application data structures, and you only have 2 GB
left for memory mapping the audio file(s).

In 64 bit you can map a large audio file in memory (think a single 6
hour, 48 channel polyphonic recording) and have enough room free for
the application itself.

Cheers,
Take

tonewheel wrote:
On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).


This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Actually I think the early VAX/VMS and MVS/XA systems did it on less
than 32 bits...

--
Aaron

Scott Dorsey wrote:
wrote:
wrote:
Hello,

This is sort of off-topic, but not.

I'm in the market for a new computer with Vista. I can't for the life
of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a
fake one, or nothing at all to do with 32 bit.

Define "a true 64 bit processor"

64 bit datapaths?
64 bit addressing?
64 bit functional units?

None of the above. It's all defined by the marketing department. If the
marketing department says the Z-80 is a 64-bit processor, it is.

As someone who worked as a design engineer in the CPU field for
several years I have to say: You're exactly right.

--
Aaron

Mogens V. wrote:
Scott Dorsey wrote:
wrote:

wrote:

Hello,

This is sort of off-topic, but not.

I'm in the market for a new computer with Vista. I can't for the life
of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a
fake one, or nothing at all to do with 32 bit.

Define "a true 64 bit processor"

64 bit datapaths?
64 bit addressing?
64 bit functional units?


None of the above. It's all defined by the marketing department. If the
marketing department says the Z-80 is a 64-bit processor, it is.
--scott

Not true, but I see your point
I'd say a processor with 64bit registers, ALU and so forth AND 64bit
addressing makes it 64bit, but without the bus and MMU it's pretty much
useless.

I'm pretty sure no such processor exists. As far as I know every 64
bit addressing processor is wider on the internal bus and MMU/FPU,
and MAY be narrower in the integer ALUs.

--
Aaron

anahata wrote:
wrote:

Define "a true 64 bit processor"

64 bit datapaths?
64 bit addressing?
64 bit functional units?

What the marketing department want it to be, of corse, but...
To qualify as any sort of 64 bit processor, it should support the
AMD/Intel 64 bit instruction set (which is different from x86.)

Well, the Intel x86-64 parts (at least the early ones) had 64 bit
addressing. Datapaths (depending on instruction) from 32-128 bits wide.
Functional units 32-128 bits wide. etc.

--
Aaron

Arny Krueger wrote:
wrote in message

wrote:
Hello,

This is sort of off-topic, but not.

I'm in the market for a new computer with Vista. I
can't for the life of me figure out if the Intel Core 2
Duo is a true 64 bit processor, a fake one, or nothing
at all to do with 32 bit.

Define "a true 64 bit processor"

64 bit datapaths?

or greater. For example, 32 bit processors with 64 and 128 bit data paths
are old hat.

....as are 64 bit processors with 32 bit datapaths - depending on
instruction.

64 bit addressing?

An absolute must. But, I'm not sure that anybody has a compelling reason to
go further for address space or main memory adressing with a mainstream
processor. IPV6 uses 128 bit addresses, but they are something different.

64 bit functional units?

or greater. For example, 32 bit processors with 64 and 128 bit functional
units are old hat.

....as are 64 bit processors with 64bit functional units...

--
Aaron

[Scott Dorsey]

In article ,
wrote:
tonewheel wrote:
On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).

This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Actually I think the early VAX/VMS and MVS/XA systems did it on less
than 32 bits...

Actually, lots of S-100 machines did it with only eight bits. With varying
degrees of success and reliability.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

wrote:

I'm pretty sure no such processor exists. As far as I know every 64
bit addressing processor is wider on the internal bus and MMU/FPU,
and MAY be narrower in the integer ALUs.

Vax 11/780 with an Floating Point Systems FPS-64 vector pipe. The CPU
itself does only 32 bit loads and stores, but the vector coprocessor
has full 64-bit float operations on vectors, and addresses local vector
memory in 64-bit chunks or the main memory over the 32-bit Unibus.

You can argue that an array processor is part of the CPU since it takes
over the memory buss and is controlled by the instruction decoder of
the CPU. You can argue that it isn't part of the CPU at all, too, since
it has no register access and isn't part of the CPU instruction set.
Which argument you makes depends on whether you work for CDC or FPS.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arny Krueger]

wrote in message
...
tonewheel wrote:
On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).


This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Actually I think the early VAX/VMS and MVS/XA systems did it on less
than 32 bits...

There was a 24 bit addressing limit in MVS until they tweaked the hardware
and software. I remember when it seemed ludicrously high!

The MVS 16 meg barrier fell first for hardware real memory, and then for
application address spaces. The letters "XA" were IBM's code for going
fully 32 bit.

VMS has been through a lot of changes. At one time it was restricted to 24
bit addressing, if I recall correctly. Appreantly there is now a VMS with 64
bit addressing.

Hey, IBM's AS/400 and System 38 systems had 128 bit addressing.

[Ben Bradley]

On 10 Feb 2007 06:33:36 -0800, "JReynolds"
wrote:

Any thoughts on audio software evolving into 64 bit architectures?
That would probably kill the argument that you need to go analog to
mix due to summing issues.

The arise of 64 bit architecture has absolutely nothing to do with the
difference in sound you get from analog summing. The two are
completely unrelated. Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.

Are you saying the "analog summing" sound results from the
nonlinearities in resistors or similar components? If so, then I grant
you that digital mixing won't sound the same, no matter how many bits
are used. Until the nonlinearities are digitally simulated.

I recall reading some of the "analog summing" threads a few years
back, they were interesting.

While more processing word length per clock would mean we can come up
processes that work on a more precise level, this will not change the
fact that analog summing will give you the color of the gear you are
using.
BTW... Pro Tools summing is already done in 48 bit. check out

As this article demonstrates, 64 bit (or even 128 bit) audio
processing can be done with 32-bit proccessors as "double precision"
fixed-point operation. You don't need a processor with more bits just
to do adds and multiplies with more bits of precision. There's a speed
penalty because each operation with each sample takes more processor
instructions and cycles to do more bits, but that only means the max
real-time track count is something like 215 instead of 479 (your track
count may vary).

http://akmedia.digidesign.com/suppor...ixer_26688.pdf

But as far as killing the argument for the analog mixing bus, only
time, listening, and possibly changing attitudes will tell.

[Arny Krueger]

"JReynolds" wrote in message
ups.com...


Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.

It has long been possible to make analog summers that would pass a straight
wire bypass test.

[tonewheel]

On 12 Feb, 19:29, wrote:
tonewheel wrote:
On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).

This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Actually I think the early VAX/VMS and MVS/XA systems did it on less
than 32 bits...

--
Aaron

You are right about MVS/XA - that was 31 bit. Plain MVS was 24 bit but
I don't remember if that offered this feature - I was only a trainee
programmer at IBM at that time. VAX/VMS was 32 bit from the start,
though, I am 99% sure. Maybe you're thinking of the earlier DEC os's
that ran on PDP's and the like? Again they are before my time.

TWJ

[tonewheel]

On 12 Feb, 20:16, "Arny Krueger" wrote:

The MVS 16 meg barrier fell first for hardware real memory, and then for
application address spaces. The letters "XA" were IBM's code for going
fully 32 bit.


not quite, it was *31* bit. The top bit was a status bit.(reduced from
8 status bits on MVS)
I remember quite clearly linking with "amode 31, rmode 31".
Addresses were stored in 32-bit registers on both systems.

VMS has been through a lot of changes. At one time it was restricted to 24
bit addressing, if I recall correctly. Appreantly there is now a VMS with 64
bit addressing.

Yes 64 bit VMS running on Alpha AXP came out several years ago now,
but I've never heard of 24 bit VMS, unless you are referring to some
*very* bespoke installation created for a special case. Even microvms
on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging
very deep into a very fading memory....


TWJ

[tonewheel]

On 12 Feb, 18:21, "Take Vos" wrote:
Hello TWJ,

- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).
This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Yes, memory mapped I/O is incredibly old, but I meant it would be more
useful with a 64 bit address space when working on large audio files.

In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio
buffers and other application data structures, and you only have 2 GB
left for memory mapping the audio file(s).


eek, how big are your audio files?

In 64 bit you can map a large audio file in memory (think a single 6
hour, 48 channel polyphonic recording) and have enough room free for
the application itself.


oh, that big.

Cheers,
Take

cheers,
TWJ :-)

[Scott Dorsey]

Arny Krueger wrote:
"JReynolds" wrote in message

Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.

It has long been possible to make analog summers that would pass a straight
wire bypass test.

No matter how good your summing network is, I can add enough channels to
it that it won't pass the straightwire test any more.

The question is how many channels that is.
--scott

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

[Scott Dorsey]

tonewheel wrote:
You are right about MVS/XA - that was 31 bit. Plain MVS was 24 bit but
I don't remember if that offered this feature - I was only a trainee
programmer at IBM at that time.

That's addressing, not data. Data was full 32 bit.

VAX/VMS was 32 bit from the start,
though, I am 99% sure. Maybe you're thinking of the earlier DEC os's
that ran on PDP's and the like? Again they are before my time.

The Vax was 32-bit data from the start (although the 11/780 had a 16-bit
compatibility mode so you could run your old RSX binaries). But, it did
not have full 32-bit addressing in hardware, although the instruction scheme
supported it. The actual width of the address buss depended on the model
you bought....
--scott

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

[Scott Dorsey]

tonewheel wrote:

Yes 64 bit VMS running on Alpha AXP came out several years ago now,
but I've never heard of 24 bit VMS, unless you are referring to some
*very* bespoke installation created for a special case. Even microvms
on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging
very deep into a very fading memory....

Q-bus backplanes could be configured for 18 or 22 bit addressing. Lots
of folks bought old 18-bit ones and did some wire-wrapping to put their
microvax cards in.

BUT, the instructions still had 32-bit addresses in them, even though
the hardware didn't support the full space.
--scott

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

[Arny Krueger]

"Scott Dorsey" wrote in message
...
Arny Krueger wrote:

"JReynolds" wrote in message

Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.

It has long been possible to make analog summers that would pass a
straight
wire bypass test.

No matter how good your summing network is, I can add enough channels to
it that it won't pass the straightwire test any more.

Agreed

The question is how many channels that is.

Agreed.

[tonewheel]

On 13 Feb, 14:51, (Scott Dorsey) wrote:
tonewheel wrote:

Yes 64 bit VMS running on Alpha AXP came out several years ago now,
but I've never heard of 24 bit VMS, unless you are referring to some
*very* bespoke installation created for a special case. Even microvms
on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging
very deep into a very fading memory....

Q-bus backplanes could be configured for 18 or 22 bit addressing. Lots
of folks bought old 18-bit ones and did some wire-wrapping to put their
microvax cards in.

BUT, the instructions still had 32-bit addresses in them, even though
the hardware didn't support the full space.
--scott

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

ah, OK it becomes clear. You're talking about the physical hardware,
fair enough.

I was specifically referring to 'VMS' which is the operating system.

cheers,
twj

[Ben Bradley]

On 13 Feb 2007 06:12:03 -0800, "tonewheel"
wrote:

On 12 Feb, 18:21, "Take Vos" wrote:
Hello TWJ,

- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows us
to do this).
This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Yes, memory mapped I/O is incredibly old, but I meant it would be more
useful with a 64 bit address space when working on large audio files.

In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio
buffers and other application data structures, and you only have 2 GB
left for memory mapping the audio file(s).


eek, how big are your audio files?

In 64 bit you can map a large audio file in memory (think a single 6
hour, 48 channel polyphonic recording) and have enough room free for
the application itself.


oh, that big.

Now that you mention it, I have to wonder - just how much RAM is
that, and how much does it costs?
Quick calculations: 44.1k/24bits is 132,300 bytes/second, *3600*6
hours 2857680000, * 48 tracks = 137,168,640,000 - let's call it 137
gigabytes. Let's say 2G is $120, 137G is $8,220. That's not outrageous
for an upscale studio, but RAM is a depreciating investment. It better
save a lot of time vs. hard disk, and hope no one hits the power plug
near the end of a session. A good program would have a background task
writing the files to disk while not recording.

Cheers,
Take

cheers,
TWJ :-)

[Arny Krueger]

"Ben Bradley" wrote in message
...
On 13 Feb 2007 06:12:03 -0800, "tonewheel"
wrote:

On 12 Feb, 18:21, "Take Vos" wrote:
Hello TWJ,

- Able to do memory mapped I/O, this allows a programmer to use an
audio file as if it was normal memory (64 bit address space allows
us
to do this).
This is not a new feature of 64 bit architectures. Windows XP does it.
Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM
mainframes running MVS/XA did it, all on 32 bits.

Yes, memory mapped I/O is incredibly old, but I meant it would be more
useful with a 64 bit address space when working on large audio files.

In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio
buffers and other application data structures, and you only have 2 GB
left for memory mapping the audio file(s).


eek, how big are your audio files?

In 64 bit you can map a large audio file in memory (think a single 6
hour, 48 channel polyphonic recording) and have enough room free for
the application itself.


oh, that big.

Now that you mention it, I have to wonder - just how much RAM is
that, and how much does it costs?
Quick calculations: 44.1k/24bits is 132,300 bytes/second, *3600*6
hours 2857680000, * 48 tracks = 137,168,640,000 - let's call it 137
gigabytes. Let's say 2G is $120, 137G is $8,220. That's not outrageous
for an upscale studio, but RAM is a depreciating investment. It better
save a lot of time vs. hard disk, and hope no one hits the power plug
near the end of a session. A good program would have a background task
writing the files to disk while not recording.

That example illustrates one of the niceties of memory-mapped I/O.

With memory-mapped I/O you don't load the whole file into RAM, just the
parts you reference. Changes to memory can be queued back out to the disk,
so it would only be running a few seconds worth of edits behind the file
image in RAM.

However, in the real world, you wouldn't ever alter the file. You'd do
non-destructive editing which amounts to queuing just the edit commands out
to disk. Those are almost always vanishingly small. And, since its a
more-or-less one-shot affair, the only time you'd touch the whole file would
be rendering, which doesn't need to be loaded to RAM in its entirety.

Note that in the cosmic scheme of things, audio is small potatoes compared
to video. Video editing is also done non-destructively, but you need
partially-rendered files to provide an effective user interface. It turns
out that storage of partially-rendered or lower-resolution rendered video
files for the UI, can get iffy unless you have a large fast memory buffer at
your disposal.

I think the first people to really benefit from 4 GB RAM will be people
doing video, not audio.

[Paul Repacholi]

(Scott Dorsey) writes:

Oh, it predates the 8088 by a long shot. The IBM 360/30 was an example,
I think, as was the horrible PDP-8e.

I think you brain is recoiling from the 8S, one bit wide. All the F-11
systems where in fact 8 bit and double pumped. Most extreme I think was
the S38, 16 bit ALU with 128/256 bit `addresses'.

[JReynolds]

Arny Krueger wrote:
"JReynolds" wrote in message
Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.
It has long been possible to make analog summers that would pass a
straight
wire bypass test.
No matter how good your summing network is, I can add enough channels to
it that it won't pass the straightwire test any more.

Agreed

The question is how many channels that is.

Agreed.

Alright, I agree with what all of you are saying about mixers being
able to be somewhat transparent. That really wasn't my point.
The point here is, that even if we could mix 1,000,000 channels of
audio in the box in a n-bit addressed space with absolute precision, I
would rather mix 96 tracks on a decent analog desk that introduces
some coloring, because it sounds good.
I'm not behind the times either, 24 years old, pro tools expert, and
have studied this stuff in depth, and truly believe that even if
digital is perfect, it's not the best.
I will admit that analog is cost prohibitive for some projects, and
that you can make good music in the box, but I will always prefer an
analog desk to sum through.

[Arny Krueger]

"JReynolds" wrote in message
oups.com...
Arny Krueger wrote:
"JReynolds" wrote in message
Analog summing is used, and will be used into
the future, because electronic components have inconsistent
irregularities that color the sound.
It has long been possible to make analog summers that would pass a
straight
wire bypass test.
No matter how good your summing network is, I can add enough channels
to
it that it won't pass the straightwire test any more.

Agreed

The question is how many channels that is.

Agreed.

Alright, I agree with what all of you are saying about mixers being
able to be somewhat transparent. That really wasn't my point.
The point here is, that even if we could mix 1,000,000 channels of
audio in the box in a n-bit addressed space with absolute precision, I
would rather mix 96 tracks on a decent analog desk that introduces
some coloring, because it sounds good.

You forgot the required qualifier: "to me."

I'm not behind the times either, 24 years old, pro tools expert, and
have studied this stuff in depth, and truly believe that even if
digital is perfect, it's not the best.

I guess your idea of best and my idea of best are two different things.

BTW I'm 60, and edit on analog desks, digital desks, and on a DAW. No
contest - I'll take the DAW.

I will admit that analog is cost prohibitive for some projects, and
that you can make good music in the box, but I will always prefer an
analog desk to sum through.

Enjoy!

At least as long as analog desks are still available. Think they won't ever
go away? Look where analog tape is headed.

[jt]

In article , Romeo
Rondeau wrote:

Richard Crowley wrote:
wrote ...
"Richard Crowley" wrote:

Most knowledgeable people in my acquaintance are
avoiding it like the plague.
well, that's what is out there and time marches on. i'm sure it will
settle in.

I propose to migrate to Linux (or Mac?) by the time WinXP
support ends.

Good luck with that :-) Let us all know how that works for ya :-)


Seesm to be working very, very well for more and more people, thanks
for asking.