Okay, just trying to get my head around this.

Everything in my scenario is 64-bit except for the VI, which will supposedly work as a 32-bit app in a 64-bit environment because of the Bit Bridge wrapper. So if everything is functioning, I would assume that Sonar could access 8+ gigs of ram. Even if the plug-in is limited to ram access afforded a 32-bit app, given 8+ gigs of ram in the machine, it seems to me one could have 16 instances of VI, each with roughly 1/2 gig of articulations, with multiple output/panning/mixing capability afforded by Sonar, which could them be routed via ADAT out to my Mac DAW?

What am I missing?

@Nick Batzdorf said:

No no no, it's because you need a 64-bit player for that.

According to Steinberg when the 64bit of Cubase/Nuendo is released there will be a wrapper that will allow you to load 32bit plugs. I assume that this is what bitbridge is. The per application limitation of 4GB may not matter as one can always load more instances. Therefore it is a legitimate question as to whether this means that Sonar can use more than 4GB as the wrapper could well "fool" the OS. Until someone has tried it I wouldn't count it out.

DG

I would, but then I've been wrong before.

IMO this can only be a wrapper for VST (64 to 32 bit) and not for memory used by the plugin - of course you could use the trick to run the stand-alone besides the plugin to access more than 4 GB (via a virtual midi cable)
christian

@cm said:

IMO this can only be a wrapper for VST (64 to 32 bit) and not for memory used by the plugin - of course you could use the trick to run the stand-alone besides the plugin to access more than 4 GB (via a virtual midi cable)
christian

But if you are running multiple instances of the plugin within your 64bit sequencer, surely the memory available wouldn't be governed by individual plugs?

DG

If the plug-in is only capable of accessing 4GB (theoretically - far less in the real world), then I think it is.

@Nick Batzdorf said:

If the plug-in is only capable of accessing 4GB (theoretically - far less in the real world), then I think it is.

If I had Sonar I'd test this out. However, my two reasons for casting doubt upon your wisdom are:

1) Memory is held by the sequencer, not the plug. This is why when even a plug is not LAA you can still run multiple instances to get more than 2GB for your sequencer. Regarding Sonar, it all depends as to whether running bitbrige means that Sonar is running in 32bit compatibility mode or not (easy to check in Task Manager).

2) You are certainly wrong about getting far less than 4GB with a 32bit application; I can load 3.9GB in XP64 and it is perfectly stable.

DG

I have Sonar 6 but unfortunately only a 32-bit system. I put the question to Cakewalk technical support and will let you know what I hear.

@Another User said:

my two reasons for casting doubt upon your wisdom are:

As long as there are only two I'm doing a great job of keeping all the others hidden. [:D]

By the way, your #2 must be using VSL rather than, say, NI players. The V.I. Player can load a lot of available RAM, like 1.7GB out of 2 installed or something - I forget the exact number.

And as to #1, the 32-bit sampler still has to load samples from memory addresses. My thinking is that if it only sees 32 bits worth, it doesn't matter how much the host can see, it still can only access 4GB worth of RAM.

@Nick Batzdorf said:

By the way, your #2 must be using VSL rather than, say, NI players. The V.I. Player can load a lot of available RAM, like 1.7GB out of 2 installed or something - I forget the exact number.

And as to #1, the 32-bit sampler still has to load samples from memory addresses. My thinking is that if it only sees 32 bits worth, it doesn't matter how much the host can see, it still can only access 4GB worth of RAM.

OK, I think that you need to go back to the start and read the loading tests I did 18 months ago.

1) I can load a hair under 2GB in VI player with 2GB RAM installed. It was a bit flaky, but cutting it down a bit made it perfectly stable.

2) Agreed K2 is a bit cr*p for loading compared with VI player. However, as I wouldn't use just one instance it doesn't matter. I can still load 3.9 GB.

I think that you are bogged down with standalones, and forget that some of us currently have no use for them. If Nuendo 4 is not released when I finish my current project (and there is no word from development), then I will try to get hold of a copy of Sonar to test all this.

DG

I'd be *very* interested to know exactly what the story is with this setup as well, as this is what I've been planning on doing with my next machine. I don't see why we wouldn't be able to break the 4GB barrier, really, as Sonar can access the 64bit space, and presumably each VST instance is relatively independent, memory-wise(??). I suppose, if all VI instances somehow share the same memory space then this obviously won't work, but it seems to me that it would be *more* complicated to have them share the same memory than it would to have them access their own independent memory-spaces within Sonar. I don't know... I mean, the term "bit bridge" certainly implies a sort of translation from the 32bit space to the 64bit space, which suggests to me that the actual memory space being accessed is the 64bit space, with a sort of virtual memory space for the 32bit plug. Now if the virtual space for 32bit plugs is a *single* space, then it sounds like we'll still be stuck at 4GB. If it's a per-instance space, then we should be okay.

Anyway, I'll watch this thread closely to see what Cakewalk has to say about it.
If it does turn out that this solution still suffers from the 4GB limit, I'm going to move to Vienna and start a hunger strike on VSL's doorstep. [;)]

J.

I'm bogged down with Macs and have plenty of use for them, DG, but unfortunately I don't yet have a Windows machine with more than 2GB installed. Sorry I didn't remember your post from EIGHTEEN MONTHS AGO!

http://images.dmusic.com/v7/emoticons/spanking.gif">

The reason I have use for stand-alones is that I can load up to 7GB on my G5; it's not entirely irrational. [:)]

@Nick Batzdorf said:

I'm bogged down with Macs and have plenty of use for them, DG, but unfortunately I don't yet have a Windows machine with more than 2GB installed. Sorry I didn't remember your post from EIGHTEEN MONTHS AGO!

http://images.dmusic.com/v7/emoticons/spanking.gif">

The reason I have use for stand-alones is that I can load up to 7GB on my G5; it's not entirely irrational. [:)]

Fair enough.

FWIW the answer from Steinberg about their 64bit to 32bit wrapper is that all the 32bit plugs will share the same memory space. So that would mean that VSL VI could only currently use 4GB. However, 64bit plugs (such as PLAY) would not share this space, so theoretically one could use much more of the memory. I'd still like to know about Sonar though.

DG

Still wondering about Sonar as well, but I'm also curious whether anybody knows if running multiple hosts on XP64 can open up the extra memory (or at least another 4GB-ish space)? For example, would it be possible to load 8GB (well, obviously a bit less in practice) on an XP64 slave by launching two instances of Bidule?

J.

OK - maybe I'm not understanding something, but does VSL work differently on PCs from on Macs? On Macs, the memory for all VI plug-ins in all open hosts is assigned to the VSL Server, an independent background application(extension? thingie?). It's the VSL Server that is thus limited to 4 GB (although when hosting in DP I've found the real-world limitation is about 3.2 GB). So until VSL Server is 64-bit, it seems to me that it won't matter whether a sequencing application hosting the VI plug-ins is 64-bit, since VI isn't using the host's memory allotment. Isn't that true?

Would be happy to be wrong about this. Might even buy a PC to celebrate.

And yes, the standalone trick has been a lifesaver. Although it's a pain to open each one individually, assign a MIDi path, load each preset, etc. Ah, for a workaround for that...

PL

Re the server issue, VSL will need to comment on that. Re the functionality of Bitbridge as it relates to ram access, I still have not heard back from Sonar tech support.

aplanchard, the vsl-server has also been introduced to allow access to memory seperate from the host's memory and since it is a 32bit app it is also limited to 4 GB. as mentioned real world allows 3,2 GB and beyond 3,5 GB it becomes pretty unstable.
a 64bit version would of course overrule this limit but one probably had to make sure a 32bit host can communicate with the vsl-derver and the audio drivers are 64bit too.
christian

Thanks Christian. I guess I will have to wait on Cakewalk's input. Of course, if VSL VI had multiple outs... [[;)]]

@Nick Batzdorf said:

Sorry I didn't remember your post from EIGHTEEN MONTHS AGO!

http://images.dmusic.com/v7/emoticons/spanking.gif">

Fair enough.DG

Daryl - eighteen months is a long time to a Yank. It's unbelievable I know. They have the attention span of a gnat. No sense of history - that's their problem. I remembered every word and syllable of your post myself.