Cubase 5.1: Should I Bump up to 16 Gigs from 4 Gigs?

[Paul[_13_]]

Obviously it would help, but after running the Window Experience
index on my "new" to me 8-core computer, it got a whopping 7.2 for
processor calculations per second, and also about 7.2 for memory
operations per second, which makes me think 4 gigs might be enough,
since the bottle-neck was the Disk data transfer rate, which was a
5.9.

Also, I installed Windows 7 professional, 64-bit version on this
machine. If I import a Cubase project folder from a 32-bit machine,
will there be any issues? Or perhaps Cubase 5.1 runs the same on either
32 or 64 bit?

Another bummer is that I will need to re-install every little plug-in
that I put in my 32-bit machine, or the project folders won't transfer
completely, so that will take some time.

Thanks in advance....

[Peter Larsen[_3_]]

On 05-12-2015 07:33, Paul wrote:

> Obviously it would help, but after running the Window Experience
> index on my "new" to me 8-core computer, it got a whopping 7.2 for
> processor calculations per second, and also about 7.2 for memory
> operations per second, which makes me think 4 gigs might be enough,
> since the bottle-neck was the Disk data transfer rate, which was a
> 5.9.

No. Minimum for real world is 8 gigabytes, and 16 recommended.

> Also, I installed Windows 7 professional, 64-bit version on this
> machine. If I import a Cubase project folder from a 32-bit machine,
> will there be any issues? Or perhaps Cubase 5.1 runs the same on either
> 32 or 64 bit?

There should be no project related issues.

> Another bummer is that I will need to re-install every little plug-in
> that I put in my 32-bit machine, or the project folders won't transfer
> completely, so that will take some time.

Yes, there is no upgrade path from any 32 bit windows to any 64 bit windows.

> Thanks in advance....

Again, get 16 gigabytes memory now. Otherwise you risk that that
specific species of ram sticks has gone extinct when you need them, in
which case your realistic usage perspective for the box will be 2 or 3
years instead of 6 to 8 years.

Kind regards

Peter Larsen

[geoff]

On 12/5/2015 7:53 PM, Peter Larsen wrote:

>
> Again, get 16 gigabytes memory now. Otherwise you risk that that
> specific species of ram sticks has gone extinct when you need them, in
> which case your realistic usage perspective for the box will be 2 or 3
> years instead of 6 to 8 years.

Naaa. Should work fine with 1GB ;-)

geoff

[Paul[_13_]]

On 12/4/2015 11:53 PM, Peter Larsen wrote:
> On 05-12-2015 07:33, Paul wrote:
>
>> Obviously it would help, but after running the Window Experience
>> index on my "new" to me 8-core computer, it got a whopping 7.2 for
>> processor calculations per second, and also about 7.2 for memory
>> operations per second, which makes me think 4 gigs might be enough,
>> since the bottle-neck was the Disk data transfer rate, which was a
>> 5.9.
>
> No. Minimum for real world is 8 gigabytes, and 16 recommended.
>
>> Also, I installed Windows 7 professional, 64-bit version on this
>> machine. If I import a Cubase project folder from a 32-bit machine,
>> will there be any issues? Or perhaps Cubase 5.1 runs the same on either
>> 32 or 64 bit?
>
> There should be no project related issues.
>
>> Another bummer is that I will need to re-install every little plug-in
>> that I put in my 32-bit machine, or the project folders won't transfer
>> completely, so that will take some time.
>
> Yes, there is no upgrade path from any 32 bit windows to any 64 bit
> windows.
>
>> Thanks in advance....
>
> Again, get 16 gigabytes memory now. Otherwise you risk that that
> specific species of ram sticks has gone extinct when you need them, in
> which case your realistic usage perspective for the box will be 2 or 3
> years instead of 6 to 8 years.
>

Yes, thanks for the input.

The previous owner didn't know that certain DDR3 sticks only support
two DIMM sockets at one time for the P6X58D motherboard:


http://vip.asus.com/forum/view.aspx?id=20100420203842531&board_id=1&model=P6X58D-E&page=1&SLanguage=en-us

So he had four 2Gig sticks, but only two of them can be seen at one
time (i tried every combination in the six slots) , for a total of 4
Gigs. I don't think two 8 Gig sticks (to get 16 Gigs) will work,
because the manual states only up to 4 gig sticks, and the highest
configuration in the qualified vendors list is 12Gigs (3x4gigs).

[polymod]

"Paul" wrote in message ...

<snip>
Another bummer is that I will need to re-install every little plug-in
that I put in my 32-bit machine, or the project folders won't transfer
completely, so that will take some time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

You might have issues with some 32 bit plug-ins running on a 64 bit machine.

Poly

[Paul[_13_]]

On 12/5/2015 3:07 PM, polymod wrote:
>
>
> "Paul" wrote in message ...
>
> <snip>
> Another bummer is that I will need to re-install every little plug-in
> that I put in my 32-bit machine, or the project folders won't transfer
> completely, so that will take some time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> You might have issues with some 32 bit plug-ins running on a 64 bit
> machine.
>

Yes, it appears I would need the 64 bit versions of the plugs-in
I want to use.

But actually, I believe the version of Cubase 5.1 that I have is
actually 32 bit, because the "about" screen says nothing about 64 bits.

So if you use a 32 bit program in a 64 bit OS, will you lose all
the extra RAM memory benefits of being in a 64 bit environment?

[Paul[_13_]]

>>> Thanks in advance....
>>
>> Again, get 16 gigabytes memory now. Otherwise you risk that that
>> specific species of ram sticks has gone extinct when you need them, in
>> which case your realistic usage perspective for the box will be 2 or 3
>> years instead of 6 to 8 years.
>>
>
> Yes, thanks for the input.
>
> The previous owner didn't know that certain DDR3 sticks only support
> two DIMM sockets at one time for the P6X58D motherboard:
>
>
> http://vip.asus.com/forum/view.aspx?id=20100420203842531&board_id=1&model=P6X58D-E&page=1&SLanguage=en-us
>
>
> So he had four 2Gig sticks, but only two of them can be seen at one
> time (i tried every combination in the six slots) , for a total of 4
> Gigs. I don't think two 8 Gig sticks (to get 16 Gigs) will work,
> because the manual states only up to 4 gig sticks, and the highest
> configuration in the qualified vendors list is 12Gigs (3x4gigs).

I just did a crucial.com system scan, and the recommended RAM
upgrades were at maximum, 4 Gigs a stick, so I'm pretty sure 8 gigs
or larger sticks will not work with my P6X58D motherboard.

The largest recommended kit was Ballistic Tactical 16 Gigs (4GBx4),
even though the max memory is stated to be 24Gigs. Somehow I doubt
simply filling in the last two slots will work to get me the full 24
Gigs.

???

[Les Cargill[_4_]]

Paul wrote:
> On 12/5/2015 3:07 PM, polymod wrote:
>>
>>
>> "Paul" wrote in message ...
>>
>> <snip>
>> Another bummer is that I will need to re-install every little plug-in
>> that I put in my 32-bit machine, or the project folders won't transfer
>> completely, so that will take some time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>> You might have issues with some 32 bit plug-ins running on a 64 bit
>> machine.
>>
>
> Yes, it appears I would need the 64 bit versions of the plugs-in
> I want to use.
>
> But actually, I believe the version of Cubase 5.1 that I have is
> actually 32 bit, because the "about" screen says nothing about 64 bits.
>
> So if you use a 32 bit program in a 64 bit OS, will you lose all
> the extra RAM memory benefits of being in a 64 bit environment?
>

Not much. You'd only lose the ability for one program to address more
than 32 bits worth of data or code.

--
Les Cargill

[david gourley[_2_]]

"polymod" > :

>
>
> "Paul" wrote in message ...
>
> <snip>
> Another bummer is that I will need to re-install every little plug-in
> that I put in my 32-bit machine, or the project folders won't transfer
> completely, so that will take some time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> You might have issues with some 32 bit plug-ins running on a 64 bit
machine.
>
> Poly
>

I was looking into that and ran across an app called 'J-Bridge' which is
supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently people
are getting mixed results when I found a follow-up on Gearslutz.

There's another one out there but the name escapes me at the moment.
Probably no substitute for the real thing, though.

david

[Nil[_2_]]

On 05 Dec 2015, david gourley > wrote
in rec.audio.pro:

> I was looking into that and ran across an app called 'J-Bridge'
> which is supposed to 'wrap' 32-bit plugins for a 64-bit system.
> Apparently people are getting mixed results when I found a
> follow-up on Gearslutz.

Reaper-64 comes bundled with a similar bridging feature. I haven't
stress-tested it, but it works pretty well with the few plugins I've
tried. I'd still probably use the 23-bit version for serious projects
at this time, but as time goes by more and more plugins are coming in
64-bit versions, so the 64-bit host becomes more viable.

[Trevor]

On 6/12/2015 11:08 AM, Les Cargill wrote:
> Paul wrote:
>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>> the extra RAM memory benefits of being in a 64 bit environment?
>>
>
> Not much. You'd only lose the ability for one program to address more
> than 32 bits worth of data or code.

"Not much" :-) If the program you are using is one that requires or
benefits greatly from the extra memory, like video editing or audio with
a number of plugins, or large samples etc. then yes "much".
If you just want a few hundred trivial apps running simultaneously, then
"not much". But why would anyone want to do that anyway? And if you just
want to browse the net you don't really need a 64bit OS or large amounts
of RAM to begin with. So probably not at all.

Trevor.

[geoff]

On 12/6/2015 12:40 PM, Paul wrote:

>
> So if you use a 32 bit program in a 64 bit OS, will you lose all
> the extra RAM memory benefits of being in a 64 bit environment?
>

No - the OS around that app may run more efficiently.


geoff

[geoff]

On 12/6/2015 4:23 PM, david gourley wrote:

>
> I was looking into that and ran across an app called 'J-Bridge' which is
> supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently people
> are getting mixed results when I found a follow-up on Gearslutz.
>
> There's another one out there but the name escapes me at the moment.
> Probably no substitute for the real thing, though.
>
> david
>

Some DAW apps will automaically wrap 32-bit VSTs themselves. Vegas
certainly does, but does not wrap DX plugins.

geoff

[Peter Larsen[_3_]]

On 06-12-2015 00:40, Paul wrote:
> On 12/5/2015 3:07 PM, polymod wrote:
>>
>>
>> "Paul" wrote in message ...
>>
>> <snip>
>> Another bummer is that I will need to re-install every little plug-in
>> that I put in my 32-bit machine, or the project folders won't transfer
>> completely, so that will take some time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>> You might have issues with some 32 bit plug-ins running on a 64 bit
>> machine.
>>
>
> Yes, it appears I would need the 64 bit versions of the plugs-in
> I want to use.
>
> But actually, I believe the version of Cubase 5.1 that I have is
> actually 32 bit, because the "about" screen says nothing about 64 bits.
>
> So if you use a 32 bit program in a 64 bit OS, will you lose all
> the extra RAM memory benefits of being in a 64 bit environment?

No. The OS will still be faster and the application will get is
theoretically useful maximum of ram, generally that would be 2 gigabytes
for a 32 bit application.

Kind regards

Peter Larsen

[Peter Larsen[_3_]]

On 06-12-2015 08:32, Trevor wrote:

> On 6/12/2015 11:08 AM, Les Cargill wrote:

>> Paul wrote:

>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>> the extra RAM memory benefits of being in a 64 bit environment?

>> Not much. You'd only lose the ability for one program to address more
>> than 32 bits worth of data or code.

> "Not much" :-) If the program you are using is one that requires or
> benefits greatly from the extra memory, like video editing or audio with
> a number of plugins, or large samples etc. then yes "much".
> If you just want a few hundred trivial apps running simultaneously, then
> "not much". But why would anyone want to do that anyway? And if you just
> want to browse the net you don't really need a 64bit OS or large amounts
> of RAM to begin with. So probably not at all.

The 64 bit OS is faster than the 32 bit OS.

> Trevor.

Kind regards

Peter Larsen

[Trevor]

On 6/12/2015 7:15 PM, Peter Larsen wrote:
> On 06-12-2015 08:32, Trevor wrote:
>
>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>
>>> Paul wrote:
>
>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>> the extra RAM memory benefits of being in a 64 bit environment?
>
>>> Not much. You'd only lose the ability for one program to address more
>>> than 32 bits worth of data or code.
>
>> "Not much" :-) If the program you are using is one that requires or
>> benefits greatly from the extra memory, like video editing or audio with
>> a number of plugins, or large samples etc. then yes "much".
>> If you just want a few hundred trivial apps running simultaneously, then
>> "not much". But why would anyone want to do that anyway? And if you just
>> want to browse the net you don't really need a 64bit OS or large amounts
>> of RAM to begin with. So probably not at all.
>
> The 64 bit OS is faster than the 32 bit OS.

This is true, but you will never notice the difference with a single 32
bit application, or even a 64bit web browser and most internet connections.

Trevor.

[Peter Larsen[_3_]]

On 06-12-2015 09:40, Trevor wrote:

> On 6/12/2015 7:15 PM, Peter Larsen wrote:
>> On 06-12-2015 08:32, Trevor wrote:

>>> On 6/12/2015 11:08 AM, Les Cargill wrote:

>>>> Paul wrote:

>>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>>> the extra RAM memory benefits of being in a 64 bit environment?

>>>> Not much. You'd only lose the ability for one program to address more
>>>> than 32 bits worth of data or code.

>>> "Not much" :-) If the program you are using is one that requires or
>>> benefits greatly from the extra memory, like video editing or audio with
>>> a number of plugins, or large samples etc. then yes "much".
>>> If you just want a few hundred trivial apps running simultaneously, then
>>> "not much". But why would anyone want to do that anyway? And if you just
>>> want to browse the net you don't really need a 64bit OS or large amounts
>>> of RAM to begin with. So probably not at all.

>> The 64 bit OS is faster than the 32 bit OS.

> This is true, but you will never notice the difference with a single 32
> bit application, or even a 64bit web browser and most internet connections.

That is how I noticed it with Vista64 on this box that now runs Win7-64.
What Microsoft did wrong with Vista was primarily to release it as a 32
bit OS. As 64 bit OS it is in fact quite good.

> Trevor

Kind regards

Peter Larsen

[geoff]

On 12/6/2015 9:40 PM, Trevor wrote:
> s is true, but you will never notice the difference with a single 32 bit app

..... if that's all you'll ever do.

geoff

[Mike Rivers[_2_]]

On 12/5/2015 10:23 PM, david gourley wrote:
> I was looking into that and ran across an app called 'J-Bridge' which is
> supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently people
> are getting mixed results when I found a follow-up on Gearslutz.

I'm surprised that it tool so long for someone to mention a "bridge" or
"wrapper" to use 32-bit plug-ins with a 64-bit OS or program. I was
going to jump in with the suggestion, but never having actually used
one, I figured I'd wait for someone with experience to comment.

The golden rule of upgrading is "You can't upgrade just one thing." This
is why I stick with what works and don't upgrade because it's there. If
it works today and I don't change anything, I don't need manufacturers'
support any more so I don't care if it evaporates for the program,
version, or hardware that I'm using.

I know that some day I'll have to replace broken hardware and when it
comes time that I can't find anything compatible, that's when I'll
replace the whole system - new hardware, new OS, new software. It will
be brutal, but I'll have saved a lot of agony in the mean time.

Of course if your work changes, your system will need to change with it.
The greatest improvements in moving to a 64-bit OS and the hardware
that's capable of getting the most out of it seems to be for people
working with video or using a large number of plug-ins in a DAW project.
I do neither and don't anticipate doing either in the foreseeable
future. Your interests and requirements may, and probably do, differ.

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

[david gourley[_2_]]

geoff > said...news:YtqdnWK6bMHhdv7LnZ2dnUU7-
:

> On 12/6/2015 4:23 PM, david gourley wrote:
>
>>
>> I was looking into that and ran across an app called 'J-Bridge' which is
>> supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently
people
>> are getting mixed results when I found a follow-up on Gearslutz.
>>
>> There's another one out there but the name escapes me at the moment.
>> Probably no substitute for the real thing, though.
>>
>> david
>>
>
> Some DAW apps will automaically wrap 32-bit VSTs themselves. Vegas
> certainly does, but does not wrap DX plugins.
>
> geoff
>

I've had no problem with that as a long-time Vegas user, too.

david

[david gourley[_2_]]

Nil > said...news:XnsA568ECE84EACnilch1
@wheedledeedle.moc:

> On 05 Dec 2015, david gourley > wrote
> in rec.audio.pro:
>
>> I was looking into that and ran across an app called 'J-Bridge'
>> which is supposed to 'wrap' 32-bit plugins for a 64-bit system.
>> Apparently people are getting mixed results when I found a
>> follow-up on Gearslutz.
>
> Reaper-64 comes bundled with a similar bridging feature. I haven't
> stress-tested it, but it works pretty well with the few plugins I've
> tried. I'd still probably use the 23-bit version for serious projects
> at this time, but as time goes by more and more plugins are coming in
> 64-bit versions, so the 64-bit host becomes more viable.

Agreed, I can't say I've had any problem with Reaper-64 on that front
either.

david

[david gourley[_2_]]

Mike Rivers > :

> On 12/5/2015 10:23 PM, david gourley wrote:
>> I was looking into that and ran across an app called 'J-Bridge' which is
>> supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently
people
>> are getting mixed results when I found a follow-up on Gearslutz.
>
> I'm surprised that it tool so long for someone to mention a "bridge" or
> "wrapper" to use 32-bit plug-ins with a 64-bit OS or program. I was
> going to jump in with the suggestion, but never having actually used
> one, I figured I'd wait for someone with experience to comment.
>
> The golden rule of upgrading is "You can't upgrade just one thing." This
> is why I stick with what works and don't upgrade because it's there. If
> it works today and I don't change anything, I don't need manufacturers'
> support any more so I don't care if it evaporates for the program,
> version, or hardware that I'm using.
>
> I know that some day I'll have to replace broken hardware and when it
> comes time that I can't find anything compatible, that's when I'll
> replace the whole system - new hardware, new OS, new software. It will
> be brutal, but I'll have saved a lot of agony in the mean time.
>
> Of course if your work changes, your system will need to change with it.
> The greatest improvements in moving to a 64-bit OS and the hardware
> that's capable of getting the most out of it seems to be for people
> working with video or using a large number of plug-ins in a DAW project.
> I do neither and don't anticipate doing either in the foreseeable
> future. Your interests and requirements may, and probably do, differ.
>

I agree with you about the upgrades. I work between audio and video, and
really haven't had any compatibility issue myself. That's just between
Reaper-64, Vegas Pro, and Pro Tools 10 (I'm not wading into their 64 bit
swamp).

I just installed Anthology-X from Eventide, and it accomodates both 32-bit
and 64-bit systems (if needed) very nicely.

david

[geoff]

On 12/7/2015 2:18 AM, Mike Rivers wrote:

>
> The golden rule of upgrading is "You can't upgrade just one thing." This
> is why I stick with what works and don't upgrade because it's there. If
> it works today and I don't change anything, I don't need manufacturers'
> support any more so I don't care if it evaporates for the program,
> version, or hardware that I'm using.

Certainly what one is using currently should continue to work exactly
the same until something actually breaks. That thing that breaks could
be a simple OS update that changes some little-but-vital detail, so be
wary of those !

But you can also miss knowing that something new that could be of great
value to you actually exists, unless you keep you ear to the ground !

geoff

[Les Cargill[_4_]]

Trevor wrote:
> On 6/12/2015 11:08 AM, Les Cargill wrote:
>> Paul wrote:
>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>
>>
>> Not much. You'd only lose the ability for one program to address more
>> than 32 bits worth of data or code.
>
> "Not much" :-) If the program you are using is one that requires or
> benefits greatly from the extra memory, like video editing or audio with
> a number of plugins, or large samples etc. then yes "much".

Yes - "not much" - it's exactly one thing, which is a small number.

I rather doubt it matters at all for audio.

> If you just want a few hundred trivial apps running simultaneously, then
> "not much". But why would anyone want to do that anyway?

2 GB or 4 GB is not a small amount of memory.

> And if you just
> want to browse the net you don't really need a 64bit OS or large amounts
> of RAM to begin with. So probably not at all.
>
> Trevor.
>
>

--
Les Cargill

[Les Cargill[_4_]]

Peter Larsen wrote:
> On 06-12-2015 08:32, Trevor wrote:
>
>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>
>>> Paul wrote:
>
>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>> the extra RAM memory benefits of being in a 64 bit environment?
>
>>> Not much. You'd only lose the ability for one program to address more
>>> than 32 bits worth of data or code.
>
>> "Not much" :-) If the program you are using is one that requires or
>> benefits greatly from the extra memory, like video editing or audio with
>> a number of plugins, or large samples etc. then yes "much".
>> If you just want a few hundred trivial apps running simultaneously, then
>> "not much". But why would anyone want to do that anyway? And if you just
>> want to browse the net you don't really need a 64bit OS or large amounts
>> of RAM to begin with. So probably not at all.
>
> The 64 bit OS is faster than the 32 bit OS.
>

But not because of the 32 or 64 bit-ness of the O/S. It's nearly
impossible to say why it might be faster.

The experience of this 2-core 3.0x GHz i5 w/ Win7 64 is very much like
my old XP except that sometimes the second core helps. Well, except
that some stuff is actually *slower*.

The only reason I upgraded is that Silverlight on Netflix
stopped working well with a video card and the old machine
was getting long in the tooth.


>> Trevor.
>
> Kind regards
>
> Peter Larsen
>

--
Les Cargill

[Les Cargill[_4_]]

Mike Rivers wrote:
> On 12/5/2015 10:23 PM, david gourley wrote:
>> I was looking into that and ran across an app called 'J-Bridge' which is
>> supposed to 'wrap' 32-bit plugins for a 64-bit system. Apparently people
>> are getting mixed results when I found a follow-up on Gearslutz.
>
> I'm surprised that it tool so long for someone to mention a "bridge" or
> "wrapper" to use 32-bit plug-ins with a 64-bit OS or program. I was
> going to jump in with the suggestion, but never having actually used
> one, I figured I'd wait for someone with experience to comment.
>
> The golden rule of upgrading is "You can't upgrade just one thing." This
> is why I stick with what works and don't upgrade because it's there. If
> it works today and I don't change anything, I don't need manufacturers'
> support any more so I don't care if it evaporates for the program,
> version, or hardware that I'm using.
>

You can upgrade one thing all day long every day. I've had
a sequence of continuous small upgrades on all my audio machines from
Win95 on.

You can't overcome things like FAT32 but there was probably
a way around that.

> I know that some day I'll have to replace broken hardware and when it
> comes time that I can't find anything compatible, that's when I'll
> replace the whole system - new hardware, new OS, new software. It will
> be brutal, but I'll have saved a lot of agony in the mean time.
>
> Of course if your work changes, your system will need to change with it.
> The greatest improvements in moving to a 64-bit OS and the hardware
> that's capable of getting the most out of it seems to be for people
> working with video or using a large number of plug-ins in a DAW project.
> I do neither and don't anticipate doing either in the foreseeable
> future. Your interests and requirements may, and probably do, differ.
>


I can't imagine needing that many plugins. I never maxed out a 32 bit
3.02 XP machine when that was my main machine.

64 bit, with vanishingly few exceptions, was and remains hype.

--
Les Cargill

[Mike Rivers[_2_]]

On 12/6/2015 3:10 PM, Les Cargill wrote:
> You can upgrade one thing all day long every day.

And, once you start, you usually have to do exactly that.

To be clear, if you're going to upgrade, do it in the smallest increment
possible and test thoroughly so that if you have a problem, you know
what change caused the problem. Otherwise, upgrade the whole shebang and
be prepared to start from scratch, crossing your fingers that you can
import your data files.

But understand that a driver update for an interface is a small
increment. A new graphics card or additional memory is a small
increment. An OS update is likely to be a large bundle of increments,
and you don't know what's being changed. You can almost always
re-install an older driver (assuming you still have the installation
file or can get it), but OS un-updates don't always work completely.

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

[geoff]

On 7/12/2015 9:10 a.m., Les Cargill wrote:
>
> I can't imagine needing that many plugins. I never maxed out a 32 bit
> 3.02 XP machine when that was my main machine.

Posssible to max out a 'leeser' PC with just one greedy plugin.

>
> 64 bit, with vanishingly few exceptions, was and remains hype.
>

They benefits may be hyped to a degree. But increasingly you will get
applications and hardware that will not come in 32-bit versions. Already
real. Yes, you can choose to stick with what already works fine for you.

geoff

[Les Cargill[_4_]]

Mike Rivers wrote:
> On 12/6/2015 3:10 PM, Les Cargill wrote:
>> You can upgrade one thing all day long every day.
>
> And, once you start, you usually have to do exactly that.
>

No, I never *HAD* to upgrade anything except for trying to chase
Netflix on PCs. I eventually just abandoned that - a $50 BluRay
player works better.

"Upgrades" were new peripherals, software, plugins, yadda.

> To be clear, if you're going to upgrade, do it in the smallest increment
> possible and test thoroughly so that if you have a problem, you know
> what change caused the problem.

Yes!

> Otherwise, upgrade the whole shebang and
> be prepared to start from scratch, crossing your fingers that you can
> import your data files.
>
> But understand that a driver update for an interface is a small
> increment. A new graphics card or additional memory is a small
> increment. An OS update is likely to be a large bundle of increments,
> and you don't know what's being changed.

To be fair, I just haven't except for the jump from Win3.11 to Win95.

> You can almost always
> re-install an older driver (assuming you still have the installation
> file or can get it), but OS un-updates don't always work completely.
>

My version of an "O/S upgrade" is a clean reinstall. This has a
high probability of success.

--
Les Cargill

[Les Cargill[_4_]]

geoff wrote:
> On 7/12/2015 9:10 a.m., Les Cargill wrote:
>>
>> I can't imagine needing that many plugins. I never maxed out a 32 bit
>> 3.02 XP machine when that was my main machine.
>
> Posssible to max out a 'leeser' PC with just one greedy plugin.
>

So I hear. I have not witnessed it. I'd be likely
to stop using a greedy plugin on that basis alone.



>>
>> 64 bit, with vanishingly few exceptions, was and remains hype.
>>
>
> They benefits may be hyped to a degree. But increasingly you will get
> applications and hardware that will not come in 32-bit versions.

That is fine - I still have the old software. It'll at least
run in a VM from now on.

> Already
> real. Yes, you can choose to stick with what already works fine for you.
>
> geoff

--
Les Cargill

[Trevor]

On 6/12/2015 8:44 PM, Peter Larsen wrote:
>>> The 64 bit OS is faster than the 32 bit OS.
>
>> This is true, but you will never notice the difference with a single 32
>> bit application, or even a 64bit web browser and most internet
>> connections.
>
> That is how I noticed it with Vista64 on this box that now runs Win7-64.
> What Microsoft did wrong with Vista was primarily to release it as a 32
> bit OS. As 64 bit OS it is in fact quite good.

I'll take your word for it. Never used, or ever wanted to use Vista
myself in any version!

Trevor.

[Trevor]

On 6/12/2015 9:09 PM, geoff wrote:
> On 12/6/2015 9:40 PM, Trevor wrote:
>> s is true, but you will never notice the difference with a single 32
>> bit app
>
> .... if that's all you'll ever do.

Which is why I said that. Half the computers I see these days never run
anything but an internet browser. I even have one of those myself that
I'm typing on.

Trevor.

[Trevor]

On 7/12/2015 6:59 AM, Les Cargill wrote:
> Trevor wrote:
>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>>> Paul wrote:
>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>>
>>>
>>> Not much. You'd only lose the ability for one program to address more
>>> than 32 bits worth of data or code.
>>
>> "Not much" :-) If the program you are using is one that requires or
>> benefits greatly from the extra memory, like video editing or audio with
>> a number of plugins, or large samples etc. then yes "much".
>
> Yes - "not much" - it's exactly one thing, which is a small number.
>
> I rather doubt it matters at all for audio.

There is audio and AUDIO. As I said, if it's an audio sampler with
gigabyte samples, or a DAW running a hundred tracks and dozens of
plug-ins etc. then it matters greatly. For trivial applications, then
obviously we agree.

Trevor

[JackA]

On Sunday, December 6, 2015 at 3:40:07 AM UTC-5, Trevor wrote:
> On 6/12/2015 7:15 PM, Peter Larsen wrote:
> > On 06-12-2015 08:32, Trevor wrote:
> >
> >> On 6/12/2015 11:08 AM, Les Cargill wrote:
> >
> >>> Paul wrote:
> >
> >>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
> >>>> the extra RAM memory benefits of being in a 64 bit environment?
> >
> >>> Not much. You'd only lose the ability for one program to address more
> >>> than 32 bits worth of data or code.
> >
> >> "Not much" :-) If the program you are using is one that requires or
> >> benefits greatly from the extra memory, like video editing or audio with
> >> a number of plugins, or large samples etc. then yes "much".
> >> If you just want a few hundred trivial apps running simultaneously, then
> >> "not much". But why would anyone want to do that anyway? And if you just
> >> want to browse the net you don't really need a 64bit OS or large amounts
> >> of RAM to begin with. So probably not at all.
> >
> > The 64 bit OS is faster than the 32 bit OS.
>
> This is true, but you will never notice the difference with a single 32
> bit application, or even a 64bit web browser and most internet connections.

64 bits for 16 bit human minds!! :-)

Jack
>
> Trevor.

[Trevor]

On 7/12/2015 7:10 AM, Les Cargill wrote:
> 64 bit, with vanishingly few exceptions, was and remains hype.

For you obviously, for many others they only need one exception. I do
however agree that many people these days never use 10% of their
computers ability. I think that it's great computers are now cheap
enough that we can say that! And of course there is the chicken and egg
thing. More people think about video editing when their computer can
already do it.

Trevor.

[geoff]

On 7/12/2015 3:37 p.m., Trevor wrote:
> On 6/12/2015 8:44 PM, Peter Larsen wrote:
>>>> The 64 bit OS is faster than the 32 bit OS.
>>
>>> This is true, but you will never notice the difference with a single 32
>>> bit application, or even a 64bit web browser and most internet
>>> connections.
>>
>> That is how I noticed it with Vista64 on this box that now runs Win7-64.
>> What Microsoft did wrong with Vista was primarily to release it as a 32
>> bit OS. As 64 bit OS it is in fact quite good.
>
> I'll take your word for it. Never used, or ever wanted to use Vista
> myself in any version!
>
> Trevor.
>
>

Hey - something we can agree on !

;-)

geoff

[geoff]

On 7/12/2015 4:07 p.m., Trevor wrote:
> On 7/12/2015 7:10 AM, Les Cargill wrote:
>> 64 bit, with vanishingly few exceptions, was and remains hype.
>
> For you obviously, for many others they only need one exception. I do
> however agree that many people these days never use 10% of their
> computers ability. I think that it's great computers are now cheap
> enough that we can say that! And of course there is the chicken and
> egg thing. More people think about video editing when their computer
> can already do it.
>
> Trevor.
>
>

These days you even get pre-teens editing and rendering large video files !

geoff

[Trevor]

On 7/12/2015 7:52 AM, geoff wrote:
> On 7/12/2015 9:10 a.m., Les Cargill wrote:
>>
>> I can't imagine needing that many plugins. I never maxed out a 32 bit
>> 3.02 XP machine when that was my main machine.
>
> Posssible to max out a 'leeser' PC with just one greedy plugin.
>>
>> 64 bit, with vanishingly few exceptions, was and remains hype.
>
> They benefits may be hyped to a degree. But increasingly you will get
> applications and hardware that will not come in 32-bit versions.

Yep, many video editing programs no longer do. So you have to stick with
the old programs and perhaps SD video only forever, or upgrade.
You can usually choose to run a 32 bit bit OS on a new 16GB computer,
and only access 4GB of it if you really want though.


>Yes, you can choose to stick with what already works fine for you.

He seems to think nobody has different requirements to himself, but
obviously many do.

Trevor.

[Les Cargill[_4_]]

Trevor wrote:
> On 7/12/2015 6:59 AM, Les Cargill wrote:
>> Trevor wrote:
>>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>>>> Paul wrote:
>>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>>>
>>>>
>>>> Not much. You'd only lose the ability for one program to address more
>>>> than 32 bits worth of data or code.
>>>
>>> "Not much" :-) If the program you are using is one that requires or
>>> benefits greatly from the extra memory, like video editing or audio with
>>> a number of plugins, or large samples etc. then yes "much".
>>
>> Yes - "not much" - it's exactly one thing, which is a small number.
>>
>> I rather doubt it matters at all for audio.
>
> There is audio and AUDIO. As I said, if it's an audio sampler with
> gigabyte samples,

Do those still exist? Serious question - I thought that
went by the wayside.

> or a DAW running a hundred tracks

*shudder* - I am afraid I'd have to use stems/submixes just to manage
that anyway.

> and dozens of
> plug-ins etc. then it matters greatly.

Well - what used to take a couple of synced tape machines
and a big console now classes as "trivial" I guess :)

> For trivial applications, then
> obviously we agree.
>
> Trevor

--
Les Cargill

[Les Cargill[_4_]]

Trevor wrote:
> On 7/12/2015 7:10 AM, Les Cargill wrote:
>> 64 bit, with vanishingly few exceptions, was and remains hype.
>
> For you obviously, for many others they only need one exception. I do
> however agree that many people these days never use 10% of their
> computers ability. I think that it's great computers are now cheap
> enough that we can say that!

Absolutely.

> And of course there is the chicken and egg
> thing. More people think about video editing when their computer can
> already do it.
>

Sure.

> Trevor.
>
>

--
Les Cargill

[Les Cargill[_4_]]

Trevor wrote:
> On 7/12/2015 7:52 AM, geoff wrote:
>> On 7/12/2015 9:10 a.m., Les Cargill wrote:
>>>
>>> I can't imagine needing that many plugins. I never maxed out a 32 bit
>>> 3.02 XP machine when that was my main machine.
>>
>> Posssible to max out a 'leeser' PC with just one greedy plugin.
>>>
>>> 64 bit, with vanishingly few exceptions, was and remains hype.
>>
>> They benefits may be hyped to a degree. But increasingly you will get
>> applications and hardware that will not come in 32-bit versions.
>
> Yep, many video editing programs no longer do. So you have to stick with
> the old programs and perhaps SD video only forever, or upgrade.
> You can usually choose to run a 32 bit bit OS on a new 16GB computer,
> and only access 4GB of it if you really want though.
>
>
>> Yes, you can choose to stick with what already works fine for you.
>
> He seems to think nobody has different requirements to himself, but
> obviously many do.
>
> Trevor.
>
>
>
>

I am more thinking "what would an ordinary studio require", the sort
that used to get by with a largish console and say, 16 or 24 tracks.

Obviously, film gets pretty crazy these days and I don't even try to
keep up with that.

--
Les Cargill

[John Williamson]

On 07/12/2015 06:36, Les Cargill wrote:
> Trevor wrote:
>> There is audio and AUDIO. As I said, if it's an audio sampler with
>> gigabyte samples,
>
> Do those still exist? Serious question - I thought that
> went by the wayside.
>
I saw one reviewed the other day that has to be delivered on a hard
drive. Somewhere round 100gB of samples, and that's just the string
section, but sampled at 24 bits and a high bit rate. The percussion
one's almost as big, and that's just the orchestral stuff. Three or four
samples per hit or per note, with a few microphones at differing
distances, and several different hits per instrument from ppp to fff.
The strings are also sampled for open strings, closed strings and
differing types of playing as well as single and multiple instruments in
the same way. These get used a fair bit in the film industry, sometimes
even finding their way on to the finished product.

>> and dozens of plug-ins etc. then it matters greatly.
>
> Well - what used to take a couple of synced tape machines
> and a big console now classes as "trivial" I guess :)
>
The luxury is that you can now layer a few artificial sounding reverbs
and get something that actually sounds like a real room, and you can
even do it in real time if your computer's fast enough and has plenty of
memory. It's cheaper and sounds better than a speaker and a mic in a
basement...

Or you can layer stuff with sample accuracy and get sounds that you
could only dream of in the days of sync'd tape machines and outboard
effects, if that's your bag, and do it in your bedroom.


--
Tciao for Now!

John.

[John Williamson]

On 06/12/2015 20:41, Mike Rivers wrote:
> On 12/6/2015 3:10 PM, Les Cargill wrote:
>> You can upgrade one thing all day long every day.
>
> And, once you start, you usually have to do exactly that.
>
> To be clear, if you're going to upgrade, do it in the smallest increment
> possible and test thoroughly so that if you have a problem, you know
> what change caused the problem. Otherwise, upgrade the whole shebang and
> be prepared to start from scratch, crossing your fingers that you can
> import your data files.
>
> But understand that a driver update for an interface is a small
> increment. A new graphics card or additional memory is a small
> increment. An OS update is likely to be a large bundle of increments,
> and you don't know what's being changed. You can almost always
> re-install an older driver (assuming you still have the installation
> file or can get it), but OS un-updates don't always work completely.
>
Before you update your OS, just take a disc image of your system drive
onto a hard drive in a caddy, and make sure you can restore it before
you go any further. The program I use for that is free, and I've used it
successfully with systems up to Windows 7. I've also used it to upgrade
a hard drive to a new, faster, larger one, leaving everything else the
same, without the bother of reinstalling anything.

--
Tciao for Now!

John.

[Trevor]

On 7/12/2015 5:36 PM, Les Cargill wrote:
> Trevor wrote:
>> On 7/12/2015 6:59 AM, Les Cargill wrote:
>>> Trevor wrote:
>>>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>>>>> Paul wrote:
>>>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>>>>
>>>>>
>>>>> Not much. You'd only lose the ability for one program to address more
>>>>> than 32 bits worth of data or code.
>>>>
>>>> "Not much" :-) If the program you are using is one that requires or
>>>> benefits greatly from the extra memory, like video editing or audio
>>>> with
>>>> a number of plugins, or large samples etc. then yes "much".
>>>
>>> Yes - "not much" - it's exactly one thing, which is a small number.
>>>
>>> I rather doubt it matters at all for audio.
>>
>> There is audio and AUDIO. As I said, if it's an audio sampler with
>> gigabyte samples,
>
> Do those still exist? Serious question - I thought that
> went by the wayside.

Why would you say that? Still see the same need, only expectations have
increased sample sizes, hence more RAM is necessary to load into memory.


>> or a DAW running a hundred tracks
>
> *shudder* - I am afraid I'd have to use stems/submixes just to manage
> that anyway.

What used to require pre-rendered sub mixes is now just done on the fly
and simple track groups. Makes life a lot easier.


>> and dozens of
>> plug-ins etc. then it matters greatly.
>
> Well - what used to take a couple of synced tape machines
> and a big console now classes as "trivial" I guess :)

Yep. Isn't that great! :-)

Trevor.

[geoff]

On 12/7/2015 7:36 PM, Les Cargill wrote:

>>
>> There is audio and AUDIO. As I said, if it's an audio sampler with
>> gigabyte samples,
>
> Do those still exist? Serious question - I thought that
> went by the wayside.

Nope.

>
>> or a DAW running a hundred tracks
>
> *shudder* - I am afraid I'd have to use stems/submixes just to manage
> that anyway.

Don't be afraid. Anybody would be crazy not to use stems/folder-tracks,
or whatever.


>> and dozens of
>> plug-ins etc. then it matters greatly.
>
> Well - what used to take a couple of synced tape machines
> and a big console now classes as "trivial" I guess :)

Not to mention all the outboard FX.

geoff

[Trevor]

On 7/12/2015 7:12 PM, John Williamson wrote:
> On 06/12/2015 20:41, Mike Rivers wrote:
>> On 12/6/2015 3:10 PM, Les Cargill wrote:
>>> You can upgrade one thing all day long every day.
>>
>> And, once you start, you usually have to do exactly that.
>>
>> To be clear, if you're going to upgrade, do it in the smallest increment
>> possible and test thoroughly so that if you have a problem, you know
>> what change caused the problem. Otherwise, upgrade the whole shebang and
>> be prepared to start from scratch, crossing your fingers that you can
>> import your data files.
>>
>> But understand that a driver update for an interface is a small
>> increment. A new graphics card or additional memory is a small
>> increment. An OS update is likely to be a large bundle of increments,
>> and you don't know what's being changed. You can almost always
>> re-install an older driver (assuming you still have the installation
>> file or can get it), but OS un-updates don't always work completely.

Or at all with older hardware.


> Before you update your OS, just take a disc image of your system drive
> onto a hard drive in a caddy, and make sure you can restore it before
> you go any further. The program I use for that is free, and I've used it
> successfully with systems up to Windows 7. I've also used it to upgrade
> a hard drive to a new, faster, larger one, leaving everything else the
> same, without the bother of reinstalling anything.

Which is fine for a simple hard drive swap, but the real problem with
continual upgrades is that new hardware often doesn't support an old OS
with necessary drivers, and a new OS often doesn't support old hardware.
IF you can keep using an old computer, old peripherals, old software,
and old OS, then you are fine. Eventually one of these things breaks or
you want some shiny new capability, and you sometimes are forced to
throw out the whole lot and start again. Or more commonly continually
throw out bits and pieces in a never ending upgrade spiral.
Even something simple like a faulty motherboard often requires a new
CPU, new RAM and sometimes a new OS because it no longer supports your
old one. Then you find your software and peripherals no longer support
the new OS etc. :-( Avoiding the mass upgrade path entirely, often
requires you to find a working S/H solution.

Trevor.

[Peter Larsen[_3_]]

On 07-12-2015 03:37, Trevor wrote:

> On 6/12/2015 8:44 PM, Peter Larsen wrote:
>>>> The 64 bit OS is faster than the 32 bit OS.

>>> This is true, but you will never notice the difference with a single 32
>>> bit application, or even a 64bit web browser and most internet
>>> connections.

>> That is how I noticed it with Vista64 on this box that now runs Win7-64.
>> What Microsoft did wrong with Vista was primarily to release it as a 32
>> bit OS. As 64 bit OS it is in fact quite good.

> I'll take your word for it. Never used, or ever wanted to use Vista
> myself in any version!

I was deeply surprised when I found out, because I had professionally
removed Vista and replaced it with XP on 3 company laptops because of
wait for (n)ever situations that the users found unacceptable. And then
some day it refused to work and said that it was "not genuine", since I
had bought it second hand I assumed that the first box it had been
installed on had been taken out of retirement and scrapped the installation.

> Trevor.

Kind regards

Peter Larsen

[Paul[_13_]]

On 12/6/2015 12:32 AM, Trevor wrote:
> On 6/12/2015 11:08 AM, Les Cargill wrote:
>> Paul wrote:
>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>
>>
>> Not much. You'd only lose the ability for one program to address more
>> than 32 bits worth of data or code.
>
> "Not much" :-) If the program you are using is one that requires or
> benefits greatly from the extra memory, like video editing or audio with
> a number of plugins, or large samples etc. then yes "much".
> If you just want a few hundred trivial apps running simultaneously, then
> "not much". But why would anyone want to do that anyway? And if you just
> want to browse the net you don't really need a 64bit OS or large amounts
> of RAM to begin with. So probably not at all.
>

So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.

And then I used a 32-bit program (like I believe my Cubase 5 is)
on it.

Some of you are saying it will still run faster than if it was
within a 32-bit OS. Is this because a 32-bit program will still be able
to access the full 16 Gigs, because the OS is still 64 bit?

Or will it still run at the same speed, because only 4 Gigs will
be seen by Cubase?

[Mike Rivers[_2_]]

On 12/7/2015 1:45 AM, Les Cargill wrote:

>>>> I can't imagine needing that many plugins. I never maxed out a 32 bit
>>>> 3.02 XP machine when that was my main machine.
> I am more thinking "what would an ordinary studio require", the sort
> that used to get by with a largish console and say, 16 or 24 tracks.

Today's "tracks" aren't like yesteryear's tracks, and today's recordists
aren't like yesteryear's, either. People tend to record everything on
its own track because they can. Instead of using a pair of 4-band
parametric EQs on "the drums," you might have an equalizer, a reverb,
and two compressors on every track that goes into the drum mix. Play six
rhythm guitar tracks and treat each one differently so you can groove on
the separation and you add more plug-ins. Same for multiple vocal
tracks. And then there are virtual instruments piled on top of each other.

With a powerful enough computer, anyone can do this, and they do. And
there is little difference between the process how recordings are made
in a professional studio than someone dabbling at home. One difference
is that a professional engineer who recognizes his system's limitations
is that he can (and does) make decisions as the project moves along and
keeps things within the system's limits. You don't have to throw out
most of those 47 vocal takes, but you can make a good composite vocal,
apply your processing plug-ins to that, and then remove all the plug-ins
from the takes that aren't going to play in a mix. The more computer
horsepower you have, the more sloppily you can work, the more time you
have, the more you can fool around, and the less experience you have,
the harder it is to decide that the project is finished.

Then there's the Internet. Most of what you read in forums is what
people think they need. It's rare that someone will report that he
actually ran out of computer power on a project of rational complexity.
Usually people don't wait to learn the limits of their system, they play
it safe. It's easier to add more RAM (if that will let them keep
working) than it is to spend some time working on the recorded tracks to
reduce the CPU load.


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

[Mike Rivers[_2_]]

On 12/7/2015 3:12 AM, John Williamson wrote:
> Before you update your OS, just take a disc image of your system drive
> onto a hard drive in a caddy, and make sure you can restore it before
> you go any further.

I do this periodically as a backup as an alternative to backing up
"essential" things at regular (short) intervals. It sounds simple, and
generally it is, but it just isn't something that everyone does. No
question that I'd do this before installing a new OS, but how many
people would think to do a disk image before installing one of the
Windows updates that come fast and furious. And, as I understand it,
with Windows 10, they just slip updates in without your knowledge unless
you take steps to turn that "feature" off. About the only Windows
updates I ever did were new versions of Dot.NET when I get a new program
that complains that I need a newer version of that library, so I'm
managed not to break a system due to an update or installation. But I
have to admit that I've done updates to application programs without
making a full backup first. I've learned a couple of times by necessity,
that Windows Restore does a pretty good job of un-doing an update.

But, you know, this is all "maintenance." It's what takes the place of
cleaning patchbay jacks, tape heads, and switches.

> The program I use for that is free, and I've used it
> successfully with systems up to Windows 7. I've also used it to upgrade
> a hard drive to a new, faster, larger one, leaving everything else the
> same, without the bother of reinstalling anything.

I've found a couple of programs (Sound Forge is one I remember) that
want to re-validate registration when running for the first time from a
cloned drive, but that's not a big deal. I don't use plug-ins as a rule
so I don't know how those survive a cloning. I use a (free) version of
Acronis True Image that Western Digital provides that works as long as
either the target or destination disk is a Western Digital. What are you
using?



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

[Les Cargill[_4_]]

John Williamson wrote:
> On 07/12/2015 06:36, Les Cargill wrote:
>> Trevor wrote:
>>> There is audio and AUDIO. As I said, if it's an audio sampler with
>>> gigabyte samples,
>>
>> Do those still exist? Serious question - I thought that
>> went by the wayside.
>>
> I saw one reviewed the other day that has to be delivered on a hard
> drive. Somewhere round 100gB of samples, and that's just the string
> section, but sampled at 24 bits and a high bit rate. The percussion
> one's almost as big, and that's just the orchestral stuff. Three or four
> samples per hit or per note, with a few microphones at differing
> distances, and several different hits per instrument from ppp to fff.
> The strings are also sampled for open strings, closed strings and
> differing types of playing as well as single and multiple instruments in
> the same way. These get used a fair bit in the film industry,

Of course...

> sometimes
> even finding their way on to the finished product.
>

Lolz!

>>> and dozens of plug-ins etc. then it matters greatly.
>>
>> Well - what used to take a couple of synced tape machines
>> and a big console now classes as "trivial" I guess :)
>>
> The luxury is that you can now layer a few artificial sounding reverbs
> and get something that actually sounds like a real room,

Absolutely.

> and you can
> even do it in real time if your computer's fast enough and has plenty of
> memory. It's cheaper and sounds better than a speaker and a mic in a
> basement...
>

Perhaps I don't appreciate "good" reverbs but that's been the
case with very humble compute resources for a very long time.

> Or you can layer stuff with sample accuracy and get sounds that you
> could only dream of in the days of sync'd tape machines and outboard
> effects, if that's your bag, and do it in your bedroom.
>
>

"Stuff you can only dream of" was possible 20, maybe 30 years ago.
Check out "black MIDI" as a style some time.

--
Les Cargill

[Les Cargill[_4_]]

Mike Rivers wrote:
> On 12/7/2015 1:45 AM, Les Cargill wrote:
>
>>>>> I can't imagine needing that many plugins. I never maxed out a 32 bit
>>>>> 3.02 XP machine when that was my main machine.
>> I am more thinking "what would an ordinary studio require", the sort
>> that used to get by with a largish console and say, 16 or 24 tracks.
>
> Today's "tracks" aren't like yesteryear's tracks, and today's recordists
> aren't like yesteryear's, either. People tend to record everything on
> its own track because they can. Instead of using a pair of 4-band
> parametric EQs on "the drums," you might have an equalizer, a reverb,
> and two compressors on every track that goes into the drum mix. Play six
> rhythm guitar tracks and treat each one differently so you can groove on
> the separation and you add more plug-ins. Same for multiple vocal
> tracks. And then there are virtual instruments piled on top of each other.
>

yeah, and then it turns into ... used dog food. I'm still
telling people "you don't need a mic on each tom."

> With a powerful enough computer, anyone can do this, and they do. And
> there is little difference between the process how recordings are made
> in a professional studio than someone dabbling at home. One difference
> is that a professional engineer who recognizes his system's limitations
> is that he can (and does) make decisions as the project moves along and
> keeps things within the system's limits.

yes. Limitations are good things.

> You don't have to throw out
> most of those 47 vocal takes, but you can make a good composite vocal,
> apply your processing plug-ins to that, and then remove all the plug-ins
> from the takes that aren't going to play in a mix. The more computer
> horsepower you have, the more sloppily you can work, the more time you
> have, the more you can fool around, and the less experience you have,
> the harder it is to decide that the project is finished.
>

Yep.

> Then there's the Internet. Most of what you read in forums is what
> people think they need. It's rare that someone will report that he
> actually ran out of computer power on a project of rational complexity.

Right. This is what I mean.

> Usually people don't wait to learn the limits of their system, they play
> it safe. It's easier to add more RAM (if that will let them keep
> working) than it is to spend some time working on the recorded tracks to
> reduce the CPU load.
>
>

--
Les Cargill

[Paul[_13_]]

On 12/6/2015 12:59 PM, Les Cargill wrote:
> Trevor wrote:
>> On 6/12/2015 11:08 AM, Les Cargill wrote:
>>> Paul wrote:
>>>> So if you use a 32 bit program in a 64 bit OS, will you lose all
>>>> the extra RAM memory benefits of being in a 64 bit environment?
>>>>
>>>
>>> Not much. You'd only lose the ability for one program to address more
>>> than 32 bits worth of data or code.
>>
>> "Not much" :-) If the program you are using is one that requires or
>> benefits greatly from the extra memory, like video editing or audio with
>> a number of plugins, or large samples etc. then yes "much".
>
> Yes - "not much" - it's exactly one thing, which is a small number.
>
> I rather doubt it matters at all for audio.
>
>> If you just want a few hundred trivial apps running simultaneously, then
>> "not much". But why would anyone want to do that anyway?
>
> 2 GB or 4 GB is not a small amount of memory.
>
>> And if you just
>> want to browse the net you don't really need a 64bit OS or large amounts
>> of RAM to begin with. So probably not at all.
>>


So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.

And then I used a 32-bit program (like I believe my Cubase 5 is)
on it.

Some of you are saying it will still run faster than if it was
within a 32-bit OS. Is this because a 32-bit program will still be able
to access the full 16 Gigs, because the OS is still 64 bit?

Or will it still run at the same speed, because only 4 Gigs will
be seen by Cubase?

[Nil[_2_]]

On 07 Dec 2015, Paul > wrote in rec.audio.pro:

> Some of you are saying it will still run faster than if it was
> within a 32-bit OS. Is this because a 32-bit program will still
> be able to access the full 16 Gigs, because the OS is still 64
> bit?
>
> Or will it still run at the same speed, because only 4 Gigs will
> be seen by Cubase?

I believe the latter case is true.

[Scott Dorsey]

In article >, Paul > wrote:
>
> So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.
>
> And then I used a 32-bit program (like I believe my Cubase 5 is)
>on it.
>
> Some of you are saying it will still run faster than if it was
>within a 32-bit OS. Is this because a 32-bit program will still be able
>to access the full 16 Gigs, because the OS is still 64 bit?

The program itself is still running in 32-bit mode. It won't run any
faster. It will be able to access more memory, but that doesn't make it
run faster.

The OS, on the other hand, is likely to be running faster than the 32-bit
version, so your OS overhead might be reduced. This is because Windows is
a horrible bloated pig.

> Or will it still run at the same speed, because only 4 Gigs will
>be seen by Cubase?

Why would more or less memory being seen by Cubase affect how fast Cubase
runs at all?
--scott

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

[Les Cargill[_4_]]

Scott Dorsey wrote:
> In article >, Paul > wrote:
>>
>> So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.
>>
>> And then I used a 32-bit program (like I believe my Cubase 5 is)
>> on it.
>>
>> Some of you are saying it will still run faster than if it was
>> within a 32-bit OS. Is this because a 32-bit program will still be able
>> to access the full 16 Gigs, because the OS is still 64 bit?
>
> The program itself is still running in 32-bit mode. It won't run any
> faster. It will be able to access more memory, but that doesn't make it
> run faster.
>
> The OS, on the other hand, is likely to be running faster than the 32-bit
> version, so your OS overhead might be reduced. This is because Windows is
> a horrible bloated pig.
>

For simple things, I can get lower latency and less jitter than most
Linux distros. I measured the error on the multimedia timers once at
about 5 microseconds average per millisecond.

But add a hardware timer and/or the realtime
extensions to Linux and it's different yet again.

>> Or will it still run at the same speed, because only 4 Gigs will
>> be seen by Cubase?
>
> Why would more or less memory being seen by Cubase affect how fast Cubase
> runs at all?

+1 It might make things faster of there's no swap file, but once I
forgot to reenable the swap file for six months on this machine and
nothing bad happened.

This is a cheap, $400 Sams Club desktop w/ 4GB.

> --scott
>

--
Les Cargill

[Mike Rivers[_2_]]

On 12/7/2015 5:50 PM, Scott Dorsey wrote:
> Why would more or less memory being seen by Cubase affect how fast Cubase
> runs at all?

It's possible that with more memory, more things are buffered and can be
accessed faster than if it has to wait for virtual memory to swap things
to on a disk drive. But then, does one ever really know how fast a
program is running? What people seem to be most impressed with speedwise
is in doing jobs that are computation-intensive, and there really isn't
a lot of that when it comes to digital audio.

If a solid state drive is really faster than a mechanical one, that
might give the impression of speeding up more than adding more RAM. If
nothing else, the program might load faster, and that wait time between
when you click the icon and can start recording or playing is probably
more noticeable than a tiny bit less processing time.

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

[Trevor]

On 8/12/2015 9:50 AM, Scott Dorsey wrote:
> In article >, Paul > wrote:
>> So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.
>> And then I used a 32-bit program (like I believe my Cubase 5 is)
>> on it.
>> Some of you are saying it will still run faster than if it was
>> within a 32-bit OS. Is this because a 32-bit program will still be able
>> to access the full 16 Gigs, because the OS is still 64 bit?
>
> The program itself is still running in 32-bit mode. It won't run any
> faster. It will be able to access more memory,

Can you explain how you think a 32 bit program can access more than 4GB
at once? I'm sure a lot of people would love to know how to do that.


>> Or will it still run at the same speed, because only 4 Gigs will
>> be seen by Cubase?
>
> Why would more or less memory being seen by Cubase affect how fast Cubase
> runs at all?

It will certainly affect it's speed if you don't have enough and
swapping to disk is necessary, that's why. Not a problem for most people
perhaps, but you did ask.

Trevor.

[geoff]

On 8/12/2015 2:53 p.m., Mike Rivers wrote:
> On 12/7/2015 5:50 PM, Scott Dorsey wrote:
>> Why would more or less memory being seen by Cubase affect how fast
>> Cubase
>> runs at all?
>
> It's possible that with more memory, more things are buffered and can
> be accessed faster than if it has to wait for virtual memory to swap
> things to on a disk drive. But then, does one ever really know how
> fast a program is running? What people seem to be most impressed with
> speedwise is in doing jobs that are computation-intensive, and there
> really isn't a lot of that when it comes to digital audio.

Unless you use some slightly sophisticated plugins in a real-time
operation. Easy to get a lesser PC to stutter with not that much Ozone
on, or a convolution reverb or two.

geoff

[Paul[_13_]]

On 12/7/2015 7:22 PM, Trevor wrote:

>>
>> The program itself is still running in 32-bit mode. It won't run any
>> faster. It will be able to access more memory,
>
> Can you explain how you think a 32 bit program can access more than 4GB
> at once? I'm sure a lot of people would love to know how to do that.
>
>
>>> Or will it still run at the same speed, because only 4 Gigs will
>>> be seen by Cubase?
>>
>> Why would more or less memory being seen by Cubase affect how fast Cubase
>> runs at all?
>
> It will certainly affect it's speed if you don't have enough and
> swapping to disk is necessary, that's why. Not a problem for most people
> perhaps, but you did ask.
>

Not only that, but Cubase has a tendency to crash if there isn't
enough memory.

Maybe he foolishly thinks I can get away with 512MB! Haha!

[Scott Dorsey]

In article >, Mike Rivers > wrote:
>On 12/7/2015 5:50 PM, Scott Dorsey wrote:
>> Why would more or less memory being seen by Cubase affect how fast Cubase
>> runs at all?
>
>It's possible that with more memory, more things are buffered and can be
>accessed faster than if it has to wait for virtual memory to swap things
>to on a disk drive.

In the 21st century, if you are swapping at all, something is terribly
terribly wrong. You might page a little now and then to get unused stuff
out of memory when your OS has a million things in memory that aren't being
used.... but if a process is being swapped out, you are hurting badly.

>If a solid state drive is really faster than a mechanical one, that
>might give the impression of speeding up more than adding more RAM. If
>nothing else, the program might load faster, and that wait time between
>when you click the icon and can start recording or playing is probably
>more noticeable than a tiny bit less processing time.

Yes, this is true.... and it will dramatically speed boot time on a Windows
machine which is always heavily I/O bound.
--scott

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

[geoff]

On 8/12/2015 3:22 p.m., Trevor wrote:
> On 8/12/2015 9:50 AM, Scott Dorsey wrote:
>> In article >, Paul >
>> wrote:
>>> So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.
>>> And then I used a 32-bit program (like I believe my Cubase 5 is)
>>> on it.
>>> Some of you are saying it will still run faster than if it was
>>> within a 32-bit OS. Is this because a 32-bit program will still be
>>> able
>>> to access the full 16 Gigs, because the OS is still 64 bit?
>>
>> The program itself is still running in 32-bit mode. It won't run any
>> faster. It will be able to access more memory,
>
> Can you explain how you think a 32 bit program can access more than
> 4GB at once? I'm sure a lot of people would love to know how to do that.
>

Well happy to help them out - it can address more of the 4GB slot of
memory because it is not necessarily sharing it with the whole of the of
the OS and other running applications.

\geoff

[geoff]

On 8/12/2015 4:20 p.m., Scott Dorsey wrote:
>> If a solid state drive is really faster than a mechanical one, that
>> might give the impression of speeding up more than adding more RAM. If
>> nothing else, the program might load faster, and that wait time between
>> when you click the icon and can start recording or playing is probably
>> more noticeable than a tiny bit less processing time.
> Yes, this is true.... and it will dramatically speed boot time on a Windows
> machine which is always heavily I/O bound.
> --scott
>


And now you can get (for not significantly high price) combo SSD/HDDs
which 'intelligently' cleverly stash the commonly used (esp OS and
frequently loaded apps) stuff on the SSD part.

geoff

[Trevor]

On 8/12/2015 2:20 PM, Scott Dorsey wrote:
> In article >, Mike Rivers > wrote:
>> On 12/7/2015 5:50 PM, Scott Dorsey wrote:
>>> Why would more or less memory being seen by Cubase affect how fast Cubase
>>> runs at all?
>>
>> It's possible that with more memory, more things are buffered and can be
>> accessed faster than if it has to wait for virtual memory to swap things
>> to on a disk drive.
>
> In the 21st century, if you are swapping at all, something is terribly
> terribly wrong. You might page a little now and then to get unused stuff
> out of memory when your OS has a million things in memory that aren't being
> used.... but if a process is being swapped out, you are hurting badly.

Exactly, so you just answered you own question why you need enough memory!

Trevor.

[Mike Rivers[_2_]]

On 12/7/2015 9:23 PM, geoff wrote:
> Unless you use some slightly sophisticated plugins in a real-time
> operation. Easy to get a lesser PC to stutter with not that much Ozone
> on, or a convolution reverb or two.

More buffer. Better planning. No compelling reason to use a
sophisticated reverb or cleanup software when you're recording.

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

[Trevor]

On 8/12/2015 2:24 PM, geoff wrote:
> And now you can get (for not significantly high price) combo SSD/HDDs
> which 'intelligently' cleverly stash the commonly used (esp OS and
> frequently loaded apps) stuff on the SSD part.

Trouble with all such "intelligence" is that someone decides the
algorithm, which may not always be best. You are better off with two
disks (SSD and HD) if they fit. Even a laptop can have a large USB3,
firewire, thunderbolt etc HD attached for those really big files, and
simply use an SSD for the internal drive.

Trevor.

[Trevor]

On 8/12/2015 2:21 PM, geoff wrote:
> On 8/12/2015 3:22 p.m., Trevor wrote:
>> On 8/12/2015 9:50 AM, Scott Dorsey wrote:
>>> In article >, Paul >
>>> wrote:
>>>> So what if I upgraded to 16 Gigs RAM on my 64-bit Windows 7 OS.
>>>> And then I used a 32-bit program (like I believe my Cubase 5 is)
>>>> on it.
>>>> Some of you are saying it will still run faster than if it was
>>>> within a 32-bit OS. Is this because a 32-bit program will still be
>>>> able
>>>> to access the full 16 Gigs, because the OS is still 64 bit?
>>>
>>> The program itself is still running in 32-bit mode. It won't run any
>>> faster. It will be able to access more memory,
>>
>> Can you explain how you think a 32 bit program can access more than
>> 4GB at once? I'm sure a lot of people would love to know how to do that.
>>
>
> Well happy to help them out - it can address more of the 4GB slot of
> memory because it is not necessarily sharing it with the whole of the of
> the OS and other running applications.

So still less than 4GB, not "more than 4GB" as I asked!
Can make a big difference of course for those who have a video card with
large amounts of video RAM sharing the address space. Not so much otherwise.

Trevor.

[Paul[_13_]]

On 12/7/2015 8:33 PM, Trevor wrote:
> On 8/12/2015 2:20 PM, Scott Dorsey wrote:
>> In article >, Mike Rivers
>> > wrote:
>>> On 12/7/2015 5:50 PM, Scott Dorsey wrote:
>>>> Why would more or less memory being seen by Cubase affect how fast
>>>> Cubase
>>>> runs at all?
>>>
>>> It's possible that with more memory, more things are buffered and can be
>>> accessed faster than if it has to wait for virtual memory to swap things
>>> to on a disk drive.
>>
>> In the 21st century, if you are swapping at all, something is terribly
>> terribly wrong. You might page a little now and then to get unused stuff
>> out of memory when your OS has a million things in memory that aren't
>> being
>> used.... but if a process is being swapped out, you are hurting badly.
>
> Exactly, so you just answered you own question why you need enough memory!
>

+1.

And again, the bottle-neck on this machine was the Disk data
transfer rate, which was a 5.9.

So file swapping would definitely slow this machine down.

[jason]

On 7 Dec 2015 22:20:45 -0500 "Scott Dorsey" > wrote in
article >
> Yes, this is true.... and it will dramatically speed boot time on a Windows
> machine which is always heavily I/O bound.
> --scott
>

I volunteer for a local non-profit that received a donation of Dell
laptops and deskside machines recently. They're middling models - dual-
core laptops, four-core desksides. All were Win 7 Pro. I figured some of
the clients of said non-profit might run into Windows 10 on the job so I
upgraded a few of the laptops and desksides. I am pleasantly surprised by
the fact that Win 10 boots faster and seems generally to run faster than
Win 7. I'd read some tech articles on MS' site about changes to improve
performance - mainly by fixing global locking behavior - and it seems
like they succeeded.

[geoff]

On 8/12/2015 4:35 PM, Mike Rivers wrote:
> On 12/7/2015 9:23 PM, geoff wrote:
>> Unless you use some slightly sophisticated plugins in a real-time
>> operation. Easy to get a lesser PC to stutter with not that much Ozone
>> on, or a convolution reverb or two.
>
> More buffer. Better planning. No compelling reason to use a
> sophisticated reverb or cleanup software when you're recording.
>

Um, mixing ? If that is part of what one is doing ....

geoff

[Mike Rivers[_2_]]

On 12/8/2015 2:37 AM, geoff wrote:
>> More buffer. Better planning. No compelling reason to use a
>> sophisticated reverb or cleanup software when you're recording.
>>
>
> Um, mixing ? If that is part of what one is doing ....

When mixing, you can use as large a buffer as you need in order to
prevent glitching. Latency is of no concern unless you object to waiting
a few milliseconds for playback to start after you push the button.

Unless, of course, your computer simply can't handle the computation
tasks. But then you probably wouldn't win any drag races if all you had
was a riding lawn mower. First you start out with the correct tools,
then you learn how to use them properly.

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

[geoff]

On 9/12/2015 1:25 AM, Mike Rivers wrote:
> On 12/8/2015 2:37 AM, geoff wrote:
>>> More buffer. Better planning. No compelling reason to use a
>>> sophisticated reverb or cleanup software when you're recording.
>>>
>>
>> Um, mixing ? If that is part of what one is doing ....
>
> When mixing, you can use as large a buffer as you need in order to
> prevent glitching. Latency is of no concern unless you object to waiting
> a few milliseconds for playback to start after you push the button.
>
> Unless, of course, your computer simply can't handle the computation
> tasks. But then you probably wouldn't win any drag races if all you had
> was a riding lawn mower. First you start out with the correct tools,
> then you learn how to use them properly.
>

There is a limit to what more buffer can achieve.

Thought this whole discussion had changed into how an underpowered tool
was fine for everything.

geoff

[JackA]

On Tuesday, December 8, 2015 at 2:11:01 PM UTC-5, geoff wrote:
> On 9/12/2015 1:25 AM, Mike Rivers wrote:
> > On 12/8/2015 2:37 AM, geoff wrote:
> >>> More buffer. Better planning. No compelling reason to use a
> >>> sophisticated reverb or cleanup software when you're recording.
> >>>
> >>
> >> Um, mixing ? If that is part of what one is doing ....
> >
> > When mixing, you can use as large a buffer as you need in order to
> > prevent glitching. Latency is of no concern unless you object to waiting
> > a few milliseconds for playback to start after you push the button.
> >
> > Unless, of course, your computer simply can't handle the computation
> > tasks. But then you probably wouldn't win any drag races if all you had
> > was a riding lawn mower. First you start out with the correct tools,
> > then you learn how to use them properly.
> >
>
> There is a limit to what more buffer can achieve.
>
> Thought this whole discussion had changed into how an underpowered tool
> was fine for everything.
>
> geoff

What is this Cubase? For making rap music?

Jack

[geoff]

On 9/12/2015 9:01 a.m., JackA wrote:
> What is this Cubase? For making rap music?
>
> Jack


No.

http://tinyurl.com/p67z57

geoff

[John Williamson]

On 08/12/2015 20:11, geoff wrote:
> On 9/12/2015 9:01 a.m., JackA wrote:
>> What is this Cubase? For making rap music?
>>
>> Jack
>
>
> No.
>
Although it *can* be used to record it.

--
Tciao for Now!

John.

[JackA]

On Tuesday, December 8, 2015 at 3:21:05 PM UTC-5, John Williamson wrote:
> On 08/12/2015 20:11, geoff wrote:
> > On 9/12/2015 9:01 a.m., JackA wrote:
> >> What is this Cubase? For making rap music?
> >>
> >> Jack
> >
> >
> > No.
> >
> Although it *can* be used to record it.

Oh!! I see, it was made for the Atari!! Should run fine on 65kb memory!!

Jack

>
> --
> Tciao for Now!
>
> John.

[JackA]

On Tuesday, December 8, 2015 at 3:11:02 PM UTC-5, geoff wrote:
> On 9/12/2015 9:01 a.m., JackA wrote:
> > What is this Cubase? For making rap music?
> >
> > Jack
>
>
> No.
>
> http://tinyurl.com/p67z57

Cute!

http://moshlab.com/wp-content/uploads/2015/03/Funny-Cat-Headphones-Music-Wallpaper-Animal-43287827.jpg
>
> geoff

[Trevor]

On 9/12/2015 6:10 AM, geoff wrote:
> Thought this whole discussion had changed into how an underpowered tool
> was fine for everything.

You'd be the only one who thought that then.

Trevor.

[Trevor]

On 9/12/2015 7:11 AM, geoff wrote:
> On 9/12/2015 9:01 a.m., JackA wrote:
>> What is this Cubase? For making rap music?

Isn't "Rap Music" an oxymoron? Surely one or the other, and Cubase can
manage either.

Trevor.

[None]

"Trevor" > wrote in message
...
> Isn't "Rap Music" an oxymoron?

Only if you have a pathetically narrow definition of music. I've heard
the same bull**** about rock-n-roll and Stravinsky.

[JackA]

On Tuesday, December 8, 2015 at 11:05:55 PM UTC-5, Trevor wrote:
> On 9/12/2015 7:11 AM, geoff wrote:
> > On 9/12/2015 9:01 a.m., JackA wrote:
> >> What is this Cubase? For making rap music?
>
> Isn't "Rap Music" an oxymoron?


That would be RAP Music, not Rap Music! :-)

> Surely one or the other, and Cubase can
> manage either.

Okay. So, who's in favor of a 64 bit DAW? Please explain why.
The mentor behind Goldwave made it clear 64 bit (environment) is silly. I agree. Yet, I see others offering it.


Jack
>
> Trevor.

[Dominique[_2_]]

Les Cargill > écrivait news:n438vp$9cc$1@dont-
email.me:

> Do those still exist? Serious question - I thought that
> went by the wayside.
>

Check out Native-Instruments Komplete or Toontrack Superior Drummer, if you
give those some RAM, they will gladly take it.