Thanks Christian. I guess I will have to wait on Cakewalk's input. Of course, if VSL VI had multiple outs... [[;)]]
-
Fair enough.DG@Nick Batzdorf said:
Sorry I didn't remember your post from EIGHTEEN MONTHS AGO!http://images.dmusic.com/v7/emoticons/spanking.gif">
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
-
@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
-
-
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
-
because OS X is based on MACH is based on BSD is based on UNIX which is a server operating system and connections to the GUI (aqua, which is just a hood) tend to use too much ressources. another reason is that VI can so access its own memory space (4 GB) besides from any host application (another 4 GB) which makes sense on OS X and machines with more than 4 GB RAM installed.@plurye said:
If that's true, I'd be curious to know why Macs require such a structure to handle VIs and PCs don't.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
@cm said:
because OS X is based on MACH is based on BSD is based on UNIX which is a server operating system and connections to the GUI (aqua, which is just a hood) tend to use too much ressources. another reason is that VI can so access its own memory space (4 GB) besides from any host application (another 4 GB) which makes sense on OS X and machines with more than 4 GB RAM installed.
christian
Thanks - makes sense. Although wouldn't the "VI can access its own memory space" argument apply to PCs as well? Presumably at 32-bit, each PC app can only use 4 GB too, right?
PL
-
whereas some parts of OS X is 64bit (and the GUI framework is not) a *normal* XP is 32bit so the limit is 4 GB in total here from start (up to 3GB can be loaded anyway) 64bit XP versions can access more RAM but need *native* 64bit applications and drivers to configure a system which makes sense.
christian
and remember: only a CRAY can run an endless loop in just three seconds. -