@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.

I assume the Windows version is also 32-bit right now?

"Other companies have already delivered this, so for once VSL is lagging behind"

Only EastWest's PLAY as far as I know.

According to EastWest:

"PLAY upgrades for the Orchestra are due to be released this Fall, we will have more information on our website regarding this once we get closer to releasing it."

(PLAY is the 64bit sample player for EastWest.)

@Nick Batzdorf said:

"Other companies have already delivered this, so for once VSL is lagging behind"

Only EastWest's PLAY as far as I know.

I was trying not to be specific. [:D]

OK, so VSL is lagging behind EW when it comes to sample player development. Happy now?

Actually I think that all the software and hardware manufacturers seem to be waiting for each other, but the silly thing is, that when the 64bit versions of DAWs are released, there will be people complaining that they have to use some sort of wrapper just to get their favourite plugs to run. I wish that more companies would think ahead. I mean, its not as if a 64bit OS is exactly new. Windows has had a good, stable 64bit OS for a number of years, and now has two. Allegedly Apple may even have one by the end of the year, providing that too many resources aren't diverted to the iToilet. [8-)]

DG