@golem said:

i will open a tread adressing quite some issues we are facing soon.


thanks

chris teuscher
development
(we are listening...)

That's really good to know, as VSL is the only 64bit component missing in my system at the moment.

DG

DG, what audio device(s) are you using? the only drivers i got to work so far are for RME hammefall DSP and fireface.
just yesterday i got confirmed there is a known incompatibility for bridgeco hardware (among others found in edirol, terratec, m-audio) on 64bit systems with more than 4 GB RAM (haha!) related to firewire.
christian

@cm said:

just yesterday i got confirmed there is a known incompatibility for bridgeco hardware (among others found in edirol, terratec, m-audio) on 64bit systems with more than 4 GB RAM (haha!) related to firewire.
christian

Uh oh.

EMU hardware is told to work reliably on 64bit windows. But that information is not first hand.

@cm said:

DG, what audio device(s) are you using? the only drivers i got to work so far are for RME hammefall DSP and fireface.
just yesterday i got confirmed there is a known incompatibility for bridgeco hardware (among others found in edirol, terratec, m-audio) on 64bit systems with more than 4 GB RAM (haha!) related to firewire.
christian

FX-Teleport. Don't need no stinkin' audio hardware. [H]

DG

@mathis said:

EMU hardware is told to work reliably on 64bit windows

good hint, also yesterday i stumbled across a 1616 and thought by myself it might be worth trying ... though i just couldn't find any drivers on their website at all ...
christian

I am using Windows XP x64 since late 2005. Rock-stable. I am still using an out-of-date Terratec EWS 88 D audio card - just ADAT in/out (which was about 100 EUR back then). Terratec was one of the first manufacturers to release x64 drivers for their audio cards. Maybe RME performs better (buffer sizes), but it is far more expensive.

It would be nice to have a 64-bit version of the VSL instruments plug-in to load more samples. Unfortunately, a 64-bit version of a DAW application (like Sonar x64) will not be able to load 32-bit plug-ins, so it has to start another (32-bit) application to be used as a "tray" application for 32-bit VST plug-ins (streaming MIDI and audio from one application to another). Sonar has developed the "BitBridge" application (a tray for all, not single, 32-bit VST plug-ins), but it seems to be quite buggy.

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

If this came true, I would look forward to install at least 64 GB of RAM in an x64 system. No need then for countless "mini PCs" around the host machine each running one instance of VSL with a GBit switch and FX-TELEPORT.

Thanks,

XXL

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.