Vienna Symphonic Library Forum
Forum Statistics

201,015 users have contributed to 43,226 threads and 259,184 posts.

In the past 24 hours, we have 8 new thread(s), 30 new post(s) and 82 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries (legacy)
  4. 64bit?

  • 64bit?

    N
    N
    I'm just asking, and I'm sure some don't have the answer for this. And I'm sure it's been asked a while ago. But here it goes.

    With the arrival of OSX Leopard coming in October. Is there anything we need to know about VSL being used with a 64bit system? Will there be an update in time?
  • cmC
    VSL Team
    cmC
    let's wait and see if 10.5 comes in october and how mature it will be at that state. also we had to proof if there is a performant option to couple 32bit and 64bit applications, because i'd assume most hosts would need a few months more to be ported to 64 bit too. not to metion drivers and plugins
    christian
    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    ...was i just dreaming, or did the 64bit hype start up about 5 years ago? And still virtually useless... ooh, what a strange field we're in!

    J.
  • P
    P
    last edited
    last edited
    But you VSL people have got the status of a Mac OS developer, haven't you? I suppose you can get hold of a copy of the beta version of Leopard released on Steve Jobs's keynote during WWDC, can't you? The rumor sites have it that the beta version is already pretty stable and reliable.

    The Apple website claims here that 32-bit applications can be run alongside 64-bit applications. So, since VSL server is a separate application, it *might* be possible that the sequencer doesn't have to be 64-bit native -- but that's my naïve non-programmer speculation; I'd greatly appreciate some VSL programmers chiming in here.
  • G
    G
    i will open a tread adressing quite some issues we are facing soon.


    thanks

    chris teuscher
    development
    (we are listening...)
  • P
    P
    That's great -- thanks a lot!
  • D
    D
    last edited
    last edited

    @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
  • cmC
    VSL Team
    cmC
    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
    and remember: only a CRAY can run an endless loop in just three seconds.
  • P
    P
    last edited
    last edited

    @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.
  • M
    M
    EMU hardware is told to work reliably on 64bit windows. But that information is not first hand.
  • D
    D
    last edited
    last edited

    @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
  • cmC
    VSL Team
    cmC
    last edited
    last edited

    @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
    and remember: only a CRAY can run an endless loop in just three seconds.
  • X
    X
    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
  • cmC
    VSL Team
    cmC
    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
    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    last edited
    last edited

    @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.
  • J
    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.
  • cmC
    VSL Team
    cmC
    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
    and remember: only a CRAY can run an endless loop in just three seconds.
  • J
    J
    last edited
    last edited

    @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.
  • J
    J
    ...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.
  • S
    S
    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.