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.

Ah, but I'm something far more vile than that: a transplanted Brit with no sense of history and the attention span of a...

ooh look - new Mac Minis that still only hold 2GB. [:(]

Pardon the interruption in this clever banter [[;)]] , but according to Cakewalk, "VSL would need to be made for native x64 OS in order to fully benefit from the RAM increases x64 can provide. "

Okay, this is lame... So there's still no great workaround for getting a slave machine loading > 4GB. Ouch. Nobody has actually answered whether running more than one host, on Windows XP64, would allow access to more than one 4GB space for VIs. On the PC this should be possible, as there's no client-server model, afaik - that's a Mac-only thing. Is that not correct, cm? Shouldn't multiple hosts be able to load multiple applications into individual 32bit spaces, given that we're talking about 32bit apps running on 64bit XP?

Clarification on this would be greatly appreciated.

J.

@jbm said:

Okay, this is lame... So there's still no great workaround for getting a slave machine loading > 4GB. Ouch. Nobody has actually answered whether running more than one host, on Windows XP64, would allow access to more than one 4GB space for VIs. On the PC this should be possible, as there's no client-server model, afaik - that's a Mac-only thing. Is that not correct, cm? Shouldn't multiple hosts be able to load multiple applications into individual 32bit spaces, given that we're talking about 32bit apps running on 64bit XP?

Clarification on this would be greatly appreciated.

J.

OK I'll get my assistant to test this out today.

DG

Thanks DG.

Looking forward to some *good* news... fingers crossed! [;)]

J.

@jbm said:

Thanks DG.

Looking forward to some *good* news... fingers crossed! [;)]

J.

OK, well the system was stable with no problems up to 7.5GB. I did manage to load more, but the OS was struggling.

I have an 8GB machine and I used FXT for 3.5GB, and 4 Standalone Chainer instances for the rest.

I hope that this is good news for you.

DG

Ah, yes! This is very good news, and thanks for the update!

Any reason for the 4 Chainer instances (since you could presumably fill the 4GB with only a couple)? Was this just to keep instruments divided cleanly? ...maybe Chainer is somehow particular, I don't really know that program...

I'm thinking I'll probably use 2 instances of Bidule, provided there are no big problems with doing that. This should allow me to access around 7-ish GB, which will cut my "farm" to a single Master-Slave pair - just what the doctor ordered.

cheers,

J.

@jbm said:

Ah, yes! This is very good news, and thanks for the update!

Any reason for the 4 Chainer instances (since you could presumably fill the 4GB with only a couple)? Was this just to keep instruments divided cleanly? ...maybe Chainer is somehow particular, I don't really know that program...

I'm thinking I'll probably use 2 instances of Bidule, provided there are no big problems with doing that. This should allow me to access around 7-ish GB, which will cut my "farm" to a single Master-Slave pair - just what the doctor ordered.

cheers,

J.

I couldn't be bothered to make Chainer LAA, so each instance will only hold 1.8GB or so.

DG

Got it. I'm pretty sure Bidule is LAA, so I should be good to go! [;)]

Thanks again.

J.

DG, which Windows version and machine are you using?

So I'd like further clarification on an earlier point: On a Mac there's a VSL Server that manages the VI plug-ins. On the PC there is no such thing? If not, then is the memory for VI instances handled by the host on a PC, unlike on a Mac?

If that's true, I'd be curious to know why Macs require such a structure to handle VIs and PCs don't.

Thanks,
PL