PlanetZ forums - scopeusers.com

Taken from http://www.planetz.com/forums/viewtopic.php?t=23460

husker wrote:

wolf wrote:

scope4live wrote:This will hold me over until 64bit apps are stable.

Just a short plunge regarding 64bit apps:
It's a complete myth, that 32bit apps are not capable to address more than 4GB Ram. Logic8's EXS24 can address as much Ram, as there is in you computer .. no limit. Any AU or VST developer can do this *now* .. it is even not platform specific and possible on any 32bit OS.
Having said that, there's not one reason for the audio world to switch to a 64bit OS. Unfortunately it'll happen anyway.

Sorry wolf, I just don't think that is true...the 4GB limit is very real. OSX Leopard is a 64 bit OS and ESX24 is a 64 bit app (Logic 8 itself is still mostly 32 bit).

Do you have any example of 32 bits apps on a 32 bit OS addressing more than 4GB?

cheers.

shure, as mentioned above the EXS24 from Logic8 can do this on Tiger. Everything pure 32bit.
There's even a document somewhere at apple describing how to do this (as said platform independant).

best
Wolfgang

husker wrote:the 4GB limit is very real

Yes, OSX offers the possibility to break that limit and the best of it this part is open source.

ESX24 is a 64 bit app (Logic 8 itself is still mostly 32 bit)

You're mixing up different things here.
EXS24 runs in the same thread as Logic. Logic is a 32bit app. That's the address space.
What you mean with 64bit regarding the EXS24 and some parts of Logic is the internal calculation resolution.

best
Wolfgang

Yes, you are right about ESX24... just my quick googling on the subject hitting people who don't understand the difference between 64 bit CPU/address space VS audio bit depth (I do, honest!)

Is accept that OSX has some 64 bit tricks, but your original post implies the same could be done with 32 bit XP...I guess that's what i'm really questioning. If I have 8GB RAM is a machine there is no way I can access more than 3.125 GB with 32bit XP...

cheers.

I am hitting 2.6GB's on a 4GB layout, and that's the applications limitation.

That's only GVI in standalone also. I won't use this as it limits my drivers to stereo 24bit WAVE.

But I have purchased Forte, as I have seen so many sucess stories with it, I had to get it. Besides Plogue is siding w/ Tascam and not supporting, nor condemning the LAA approach. Where as Brainspawn is right in there.

This allows me to load 60% more content w/o a problem. That's the way to find a sweet spot till the application and developers actually catch up.

Developers are allowed to release buggy, insufficiently tested software. Hell I won't even upgrade w/ the same O.S. unless I hear it does no damage from a reliable friend or developer.


Cheers,

yeah lets head for unix.

hi husker,

this "trick" has nothing to do with 32 or 64bit. It is simply a method to address more RAM in a separated area (using protected RAM). Of course those two address spaces need to be synchronized, which uses additional cpu ressources (it doesn't come for free, that is).
I see no reason, why this shouldn't be possible with WinXP .. we're all cooking a soup with water, aren't we

The funny thing is, this 64bit transision will draw all dev. power away from other (useful) things in audio land and scope in its current incarnation will even last longer, also because PC hardware will have to follow up to achieve, what we have right now with 32bit.

It's not possible for 32bit XP to access more than 3.5GB...and if XP can't access then neither can any app - regardless of soup incredients

Not a big deal to me, but it is misleading to claim 32 bit memory limits is a myth

you may wabt to change to cakewalk sonar 7 then (full 64 bit app). or podium:http://www.zynewave.com/

husker wrote:It's not possible for 32bit XP to access more than 3.5GB

Shurely you mean: One application can only acces 3.6GB max. on WInXP
Otherwise that'd be complete news to me. I thought the max. available (not the addressable) RAM is only dependant on the motherboard.

Not a big deal to me, but it is misleading to claim 32 bit memory limits is a myth

yeah, maybe I wasn't clear enough.
Shurely there is this memory limit for threads running inside one app instance.
But this limit can be circumvented.
If you start i.e. Kontakt as separate application (not as VST-plugin inside a host), you shurely are able to address additional 3.6GB .. even on WinXP 32bit (if it's able to show up all physcal memory available). The "trick" is to pretend both are one application (very roughly described).

stardust wrote:Why are samples always needed in RAM ?

You may want to playback lots of audio tracks, while using sample based instruments. Streaming samples directly from RAM gives room for playing back more audio tracks,.

wolf wrote:

husker wrote:It's not possible for 32bit XP to access more than 3.5GB

Shurely you mean: One application can only acces 3.6GB max. on WInXP
Otherwise that'd be complete news to me. I thought the max. available (not the addressable) RAM is only dependant on the motherboard.

Not a big deal to me, but it is misleading to claim 32 bit memory limits is a myth

yeah, maybe I wasn't clear enough.
Shurely there is this memory limit for threads running inside one app instance.
But this limit can be circumvented.
If you start i.e. Kontakt as separate application (not as VST-plugin inside a host), you shurely are able to address additional 3.6GB .. even on WinXP 32bit (if it's able to show up all physcal memory available). The "trick" is to pretend both are one application (very roughly described).

stardust wrote:Why are samples always needed in RAM ?

You may want to playback lots of audio tracks, while using sample based instruments. Streaming samples directly from RAM gives room for playing back more audio tracks,.

All memory access is through the OS (obviously) - so all apps can only access what the OS sees. In various flavours of 64 bit UNIX, there is a trick where 32 bit apps each get there own 32 bit memory space. That can't be done in 32 bit XP - still waiting for your example of where this is actually been done in 32 bit XP

stardust wrote:No offense, but that is theory.

No offence taken. In fact this is very real.
Film composers want to have the instruments to make sound when they need it *without* having to load them before or even adjusting them (let alone making tracks and routings). And they want to use the 16GB Ram, they've put into their machines. Believe it or not, but they have good arguments (call it relationship) to convince the responsible guys to enhance this situation.

husker wrote:still waiting for your example of where this is actually been done in 32 bit XP

I can just repeat myself: It has *nothing* to do with 32bit vs 64bit.
I already gave an example above, btw.
Still waiting for a reason, why it shouldn't be possible on WinXP to start two applications (each adressing 3.6GB)

just because they won't.

garyb wrote:just because they won't.

Well .. I'm really clueless in this area. I never had more than 2GB installed in a XP machine and I never cared about more. That's why I asked.
However this article indicates it should be possible in some way:
http://technet.microsoft.com/de-de/libr ... 57155.aspx :
"PAE mode enables processors to address greater than 4 gigabytes (GB) of memory. "

i was being flip, but this suggests, that there really is no problem, as you say. is there any hardware that would be using DEP in the operation of a sampler? this looks like the only problem is bad programming and the desire to sell a new os and corresponding software....

I am jumping to 64 to have the ability to load more content, that's it.

The 3GB LAA trick proved that larger memory addressing works, but all the developers involved suggest not to use it for the sake of stability.

Beta testers of 64bit VSL shells and instruments who have used the 3GB trick love it, but are claiming Vista and certain 64bit apps like Sonar, and 64bit shells like Aria 64 player, and VSL are yeilding some serious load amounts.

So w/ sampler apps, and VSTi's where the samples used reside on the HDD's and must be streamed, the bottleneck has been strictly memory addressing. Hence 64bit Vista. That's why I must go this way, and GS4 sounds so sick, I have no choice.

I do find it interesting though that MS released this little bit of information / trick, once Vista became widely excepted.

Those Sneaky Bastards.

according to the article, there's nothing but bad programming(and a few pieces of hardware, not an issue for a softsampler) keeping programs from using all the memory that you want(up to 3.6gb per application), and no 3GB LAA trick is even necessary.

i only made a cursory reading of the paper, but the whole memory situation looks like another boondogle, good for m$, they get to sell another os and get more control over YOUR computer, and good for the developer who has a reason to sell a new version of the software(64bit). the hardware manufacturers are happy too, because now you need a new machine since 1gb of that extra memory is being eaten by the os and extra processor speed is needed for the extra overhead and the architecture needs to be revised! again, it looks like bad(good) planning. well, this kind of thing has always been the computer world m.o.. where else could there be something sold, that's fraudulent, but accepted and even affectionately named "vaporware" as an indication of something that was only a neat idea, treated as reality.....


vista and sonar?
yeah, m$ and sonar. i'll never forget how they hype WDM drivers as SUPERIOR to ASIO. sir, there are lies, damn lies and public relations.(to paraphrase) sonar is a relatively light app. i don't think it works any better in vista than xp. i remember that logic 5 on '98 outperformed sonar or cubase in xp, more tracks, more plugins, everything. of course, i wouldn't change back. if sonar is really that much better in vista, it's only because they unscrewed it, they fixed the program itself, not because of vista. don't worry though, i'm not saying to avoid vista necessarily, and the stuff you want to run may indeed run better in vista. i'll happily use vista when it's advantageous, but when i have to thumbscan to get online, i'm going postal.

Jimmy, how can an sequencer play back 30 tracks of streaming audio in realtime, instantaneously, and these romplers can't? there's NO bottleneck, just lazy, greedy or incompetent developers. i believe that the new machine may be needed to get the performance you crave, but i think the reason is different than the developers are claiming. still, reality is reality. whatever it takes(within reason )....

garyb wrote:Jimmy, how can an sequencer play back 30 tracks of streaming audio in realtime, instantaneously, and these romplers can't? there's NO bottleneck, just lazy, greedy or incompetent developers. i believe that the new machine may be needed to get the performance you crave, but i think the reason is different than the developers are claiming. still, reality is reality. whatever it takes(within reason )....

but it was you who created the monster...

Well maybe because each articulation is another sample of the same instrument using different bowing or pizzacato, etc.

Since each sample in the first Gigasampler took a piece of RAM, and had 16 different layers ( recordings ) it worked well in Windows 98. But each velocity required a separate sample, each having it's own RAM footprint. Then add the different velocity layers and you will see that hundreds of small footprints were used. That's one instrument w/o other articulations that Gigastudio 2.54, and now GS3, and upcoming GS4 are currently using. To pull off a live real instrument attempt requires thousands of these footprints. In other words thousands of tracks actually.

So 30 tracks of Audio is quite small in comparison. When you stream those tracks, each one has a little piece of RAM as a pre-load to keep the buffer filled and mark it's path to continuous streaming. This is all in real time and literally hundreds of thousands are used / needed, that is if you are striving for the best articulations and dynamics. We are way past the one key, one sample triggering stuff of yore.

http://vsl.co.at/en/65/71/512/336.vsl

The above application allows 35,000 such RAM paths on 1 MIDI channel. I wouldn't call that bad programming, but actually taking advantage of more memory addressing. Maybe this is extreme, but film scoring folks need this to pull off elaborate orchestrations, as opposed to using an entire orchestra.

Remember my beloved Emulator II ? I am sure Pro Music has had a couple come through there. EMU was the premier sampler for years, and I could only address 128MB of RAM. More RAM, better samples. The most hardware samplers could do was 256 MB, the Akai. Even when Glyph added those external Hdd so we could have racks stuffed w/ Roland S700's, etc. The sampler could only address so much at once, hence the multiple loads during or between songs. That,....was bad programming IMHO.

Let's say that 64k is all that is needed for a RAM path. In a 4GB address, that would be 4GB's divided by 64kb, if my math is correct, is 65,536. It sounds large but the above analogy demonstrates how quickly RAM gets chewed up when multiple velocity layers ( dynamics ), is added w/ multiple articulations ( sample level ).

So more is better, as in life I suppose.

Since you are building this I will play some Orchestral libraries developed for LAA type apps that I am buying this week. Each stereo channel will have it's own MIDI channel where 6 of these giant instruments will be loaded into RAM. I can show you exactly how many little snippets of RAM it requires. It's staggering, but from using samplers for 25 years, I see it as an evolution of things. A musical Moore's Law.

I really enjoy threads where all opinions are listened to and argued. We all are learning, and sharing. In this way my new DAW will surely punish all comers.


Thanks Again,

I told you, a monster...

Jimmy, the point of this thread was whether or not 64bit was needed to address large amounts of memory with multiple apps. the m$ article showed that xp is more than capable of doing it.

there are many potential playback layers with the sampler, but only a few of those are required at any one time. only a small buffer needs to be in memory, that's the point of disk streaming! a sequencer IS a sampler! there's no bottleneck. old samplers had limited memory, not because of a technical inability to handle those samples, but because ram was expensive and bulky. also, you are the one to tell me how much better some of those old libraries sounded compared to many of these huge libraries used today...

once again, though, i totally understand your decision to build this computer and i'm fine with it(like it really matters what i think when it comes to your gear and your music! ). naturally, you should use what will work best! all this techno love kinda makes me puke though, especially when there's so much dishonesty in it's marketing.