welcome XXL and thanks for this post - just one question: has your XP64 machine more than 4 GB RAM?
i tried to install a phase24FW http://audiode.terratec.net/modules.php?op=modload&name=News&file=article&sid=5 and had no luck at all on an 8 GB XP64 machine (usually i'm not so untalented...) using driver version PHASE24FireWire_App_Drv_Vista_XP_2.41.40c.exe (firmware is also the latest version)
christian

edit: as mentioned above - the problem occures only in combination with firewire ... PCI-cards seem to be not affected

@XXL said:

Another trick under x64 to use MUCH more RAM would be to have a 32-bit version of VSL which starts another (independent) 32-bit application on the x64 system, streams MIDI data to this application and gets back audio (like FX-TELEPORT if it was used on one single system without a remote computer). So, EVERY instance of VSL would be able to load up to 4 GB of samples, since on an x64 system, every single 32-bit application can utilize up to 4 GB of RAM (normally, if using a 32-bit DAW application on x64, it is the DAW application INCLUDING all plug-ins which can IN TOTAL not exceed the 4 GB limit).


XXL

This is something many of us have been wondering about, I think. Since the limit is on a single process using > 4GB, why not make more processes? This would work equally well for XP and OS X - this is kind of what Nick et al have been doing by loading multiple versions of the standalone. But something to tie them all together, and make it less cumbersome to manage audio/midi routing (audio particularly) would be a great help. In fact, it could probably be done by just using a modified version of the current standalone, with some sort of scripted launcher app to load new instances. It seems like a viable option. Any comment from VSL?

J.

Actually, instead of a "modified version of the standalone", why not just make a 'normal' VST/AU plugin - i.e., not using the client-server model currently used on OS X. This way, we could load the 'normal' VST until our DAW ran out of RAM, *then* start loading client-server instances, until the vsl-server tops out. That would basically double RAM access on OS X, putting the limit at around 7 GB.

Make sense?

I suppose it may not make any sense for VSL to put development time into any sorts of "workarounds", with true 64-bit support apparently just around the corner. But who's to say it really IS just around the corner? It may be months before a version running in Leopard, in some as-yet-non-existent DAW, is released... Considering OS X (like XP x64) can already *access* 4+ GB of RAM, why not just maximize the working, and known-good technologies we already have?

Just thinking out loud again...

J.

jbm, the server solution for OS X has been introduced to allow using memory seperated from the host, the *normal* mode you mention has turned up to be troublesome.
in theory one could actually imagine to launch several *servers*, but to be honest: this would be unsupportable considering the lack of computer knowledge for the majority of users (in some cases i'm already happy if i don't need to explain how to make screenshots ...)
christian

@Another User said:

in theory one could actually imagine to launch several *servers*, but to be honest: this would be unsupportable considering the lack of computer knowledge for the majority of users (in some cases i'm already happy if i don't need to explain how to make screenshots ...)
christian

hehe... Well, what about the older idea of a sort of "rack" of Standalones? It could, perhaps, use the current client-server model... oh, duh... wait a second - why not turn the current standalone into a VI-hosting app, which launched its own 'private' vsl-server? Maybe something like "vslrack-server"? That could work, no?

J.

ps - thanks for the reply! As you can tell, I'm going a bit nuts with my current system, and trying to find another way... It looks like magnumpraw has had some success with x64 and Sonar x64. So that may become my new slave machine.

...or, if the problem is a kind of name-space thing, why not have separate servers for VST and AU plugs? It wouldn't be a huge help for Logic-only setups, but using Logic with, say, Bidule would be easy - you'd load AUs in Logic, which would launch a "vsl-au-server" and VSTs in Bidule, which would launch a "vsl-vst-server". Again, 7-ish GB.

Mind you, I know you've already thought of everything my little brain can come up with... [;)]

J.

Simply giving the Standalone assignable audio outputs and MIDI inputs would make it easy to run several Standalones along with the plugins instantiated in a DAW. As Nick Batzdorf has pointed out, even with the limitations of the current Standalone, one can load 7GB of samples using this method and some workarounds (e.g. SoundFlower) to compensate for the current Standalone's lack of assignable ins and outs,, but t would be much easier to accomplish if the Standalone had assignable audio outputs and MIDI inputs.

@stevesong said:

Simply giving the Standalone assignable audio outputs and MIDI inputs would make it easy to run several Standalones along with the plugins instantiated in a DAW. As Nick Batzdorf has pointed out, even with the limitations of the current Standalone, one can load 7GB of samples using this method and some workarounds (e.g. SoundFlower) to compensate for the current Standalone's lack of assignable ins and outs,, but t would be much easier to accomplish if the Standalone had assignable audio outputs and MIDI inputs.

This is all very true... However, lately I'm suffering from acute workaround fatigue syndrome (yes, AWFS - a serious and debilitating disease). I'm intensely yearning for something simple and supported. My machine (dual G5 1.8 ) also happens to run Soundflower like absolute crap, for some reason. I do have a kind of hardware loopback going on between my 2 RME cards, but still... This whole, 'run that port into that port, and this virtual cable into that app, and...' thing has been playing on my sanity for the past few years, and I've kind of hit bottom. (I was quite involved in the early part of Nick's multiple standalones discussion, if you dig around and find the original thread.)
--- Launch sequencer. Boot slave. Compose music. ---
That's what I'm after... call me a dreamer. [;)]

I'm looking at getting a new Mac Pro in the fall, whenever they release a genuine update (i.e., latest Intel chipset - and hopefully not fully-buffered RAM), so maybe then a Soundflower/Standalone workaround will seem more attractive.

But you and Nick are right - it is certainly possible.

J.

I find it practical as well as possible.

@Nick Batzdorf said:

I find it practical as well as possible.

Well, that's good... Perhaps if my machine could come anywhere near handling it, I'd feel the same. Which machine do you run, again?

J.

A 2 x 2.5 G5 with 8GB of RAM. I've found that Logic runs more smoothly this way, so I do the same with other large libraries too (e.g. Broadway Big Band, Ivory Italian Grand...).

So, where do you fiure the disconnect is?

2.5 runs fine...1.8 doesn't? On a CPU non intensive app? How much RAM are you running in the 1.8?

The disconnect is that I'm always right and other people are only right when they agree with me.

>The disconnect is that I'm always right and other people are only right when they agree with me.

Amazing! I've found the same thing.

@Nick Batzdorf said:

The disconnect is that I'm always right and other people are only right when they agree with me.

LOL!

I'm only running 2.5 GB in the dual 1.8 now, since it got demoted to a sequencer-only machine. No more VIs for this baby! But way back when that original thread was going I was running 4 GB, as I recall, and it was pretty dismal - just loads of pops and clicks. Mind you, I've been having lots of grim performance problems with Sibelius 5 recently, which is making me think that perhaps my machine is just a piece of crap. Who knows. I'm praying that the fall will bring a new Mac Pro worth upgrading to.
A few months ago I wiped the system and re-installed and it seemed to help... for a while. There were reports that this particular model had an SATA bus problem which could cause file corruption, but my performance problems don't seem related to file corruption, which would tend to have more cataclysmic results. Also, the Apple Service Diagnostic CD for this machine finds no fault - all tests pass. (And no, I'm not using that crappy hardware test CD - this is the real McCoy!).

Anyway, fingers crossed for our huggable cell phone company to actually release a computer in October... (Which isn't to say that I don't need an iToothpick, or an iPoop-scoop, or an iNavigate...) The only problem being that any new machine will probably only boot Leopard or higher, and then we'll have other fish to fry! [[:|]]

J.

Of course, by the time 64 bit is actually up and working on all hardware and software, solid state disks may have developed sufficiently (read - become cheaper) that we no longer need such a significant pre-load in VSL (or other plug-ins). They can simply read the data off the (solid state) hard-drive instead. It is worth remembering that the only reason for such a large pre-load (OK - only large because of the number of samples we have) is because of the latency of contentional hard-drives, which have to physically seek across the drive using a mechanical arm.
With the advent of solid state disks, it takes the same amount of time to find any piece of information on the drive - and it does that 100x times quicker than a conventional drive.
It is a funny time. I suspect that this race to get bigger and bigger memory on a machine may suddenly find itself redundant.
Of course, this also means that the concept of de-frag maybe becomes a thing of the past. Who cares if your data is all over the place on a solid state drive, if it takes the same time to access it wherever the data resides.
Interesting...
I don't think it will be a long way off before the concept of memory and hard-drives start to merge and we no longer think of the two as separate entities.

@paynterr said:

Of course, by the time 64 bit is actually up and working on all hardware and software, solid state disks may have developed sufficiently (read - become cheaper) that we no longer need such a significant pre-load in VSL (or other plug-ins). They can simply read the data off the (solid state) hard-drive instead. It is worth remembering that the only reason for such a large pre-load (OK - only large because of the number of samples we have) is because of the latency of contentional hard-drives, which have to physically seek across the drive using a mechanical arm.
With the advent of solid state disks, it takes the same amount of time to find any piece of information on the drive - and it does that 100x times quicker than a conventional drive.
It is a funny time. I suspect that this race to get bigger and bigger memory on a machine may suddenly find itself redundant.
Of course, this also means that the concept of de-frag maybe becomes a thing of the past. Who cares if your data is all over the place on a solid state drive, if it takes the same time to access it wherever the data resides.
Interesting...
I don't think it will be a long way off before the concept of memory and hard-drives start to merge and we no longer think of the two as separate entities.

Yep. Very good points, right across the board. I do think VSL has been on the technology-pushing train for a while now - just look at how long it's taking the current technology to catch up with the MIR. I mean, as I understand it, the main reason we're still waiting is because the current technology still isn't up to the job - at least not enough to unleash MIR on the big public. But really, actual performance of chips hasn't improved at anywhere near the rate we would have expected 7-10 years ago. I mean, highly significant speed bumps were common back in the late 90s, but it just doesn't happen any more. Damned physics...
But the main point you made is the one about hard drives and ram kind of merging in the future. I think that's probably very true. And if you think about it that way, then having one's entire template on a single machine, given a hearty enough processor, will probably be a doddle! Nice. Oh, to dream...

J.

@jbm said:

I'm only running 2.5 GB in the dual 1.8 now...

Have you considered adding more RAM? It's quite affordable for your machine. $100 or less will buy you noticeable performance gains.

Granted, much can be done with 2.5 GB, but your DAW will access at least another GB on top of that. Why not give your machine and your DAW the best chance possible of delivering all it can?

@jbm said:

I do think VSL has been on the technology-pushing train for a while now.....

J.

Except that there still is no 64bit version of the sample player available yet. Other companies have already delivered this, so for once VSL is lagging behind.

DG

@jbm said:

I'm only running 2.5 GB in the dual 1.8 now...

Have you considered adding more RAM? It's quite affordable for your machine. $100 or less will buy you noticeable performance gains.

Granted, much can be done with 2.5 GB, but your DAW will access at least another GB on top of that. Why not give your machine and your DAW the best chance possible of delivering all it can?

Read on, read on, JWL. The dual 1.8 was running 4 GB, but got demoted for being poop. The 4 GB kit went into one of my PC slave machines...

------------

DG,

True about the 64bit plug. Golem mentioned a while back he would post a thread on the problems their facing on the road to 64bits. I wonder if he'll post that soon? Anyway, being a Mac guy, (ironically) I'm still waiting for a practical 64bit solution on the software side - hosts, drivers, and so on (though my card is RME, so it could be supported, I guess).


J.