jbm, shall read: would be ... a few pieces are missing like audio drivers for most devices and a license control center. i came across BSD (4.0?) when i noticed the DV streaming server (must have been a decade ago) - a brilliant application.
christian

ps:

@Another User said:

Just picture all us VI users hunkered down, punching in matrix mappings on the command line

well considering you have to make friends with terminal from time to time this shouldn't be too hard ... and you could always use emacs [:P]

@cm said:

nick, stephen, sorry if i lost track on this, but your statements read contradicting ... has been PLAY already released or are more details to be announced this fall ... i don't get it ...

PLAY has already been released for the new libraries. The orchestral libraries are currently being converted, and are due for release in the fall.

Not to rain too hard on VSL, I have to say that from what I've read so far PLAY is not in the same league as the VSL VI player (apart from the 64bit thing) and has a number of bugs. There are many planned features, but like anything else, until they are available, they don't exist. A bit like Leopard...... [:D]

DG

@cm said:

DG, i agree when you say *Windows has had a good, stable 64bit OS for a number of years*, but i can't agree on *and now has two* [:P]
christian

Ooooooooooooo. That's low.

FWIW my XP64 bit sample box is due to arrive next week, so I'll let you know how I get on.

DG

@DG said:

Not to rain too hard on VSL, I have to say that from what I've read so far PLAY is not in the same league as the VSL VI player (apart from the 64bit thing) and has a number of bugs. There are many planned features, but like anything else, until they are available, they don't exist. A bit like Leopard...... [:D]

DG

PLAY is a far cry from VSL-league at the moment. It's a promising engine, but it's still a little wet behind the ears being a 1.0 version.

It's really amazing in retrospect to see the vast distance the Vienna team has covered since the Standard Edition. This came to mind with the recent "last chance" announcement for some of the earlier collections.

VSL has simply gone from being a clever concept to being downright elegant!

@DG said:

Not to rain too hard on VSL, I have to say that from what I've read so far PLAY is not in the same league as the VSL VI player (apart from the 64bit thing) and has a number of bugs. There are many planned features, but like anything else, until they are available, they don't exist. A bit like Leopard...... [:D]

DG

PLAY is a far cry from VSL-league at the moment. It's a promising engine, but it's still a little wet behind the ears being a 1.0 version.

It's really amazing in retrospect to see the vast distance the Vienna team has covered since the Standard Edition. This came to mind with the recent "last chance" announcement for some of the earlier collections.

VSL has simply gone from being a clever concept to being downright elegant!
I agree. I haven't used PLAY, so I'm merely speculating, but I seem to remember that VSL VI player had very few bugs when it was released. In fact I think that most of them were on Mac and concerned the Syncrosoft dongle. However, we are now 18 months down the line, so I'm sure that many of us are hoping to see a big improvement in the next incarnation.

DG

@cm said:

Nick, stephen, sorry if i lost track on this, but your statements read contradicting ... has been PLAY already released or are more details to be announced this fall ... i don't get it ...

cm:

To answer your question:

The statement I quoted in my initial post - - indicating that the release of the PLAY version of the EWQLSO is planned for the Fall of 2007 - - is from an e-mail I received from EastWest Technical Support on July 5, 2007. Whether PLAY has been released for libraries other than the EWQLSO, I don't know.

ahhh, thanks ... i really should pay more attention to other websites [;)]

I believe four of the six new libraries have been released, or I should say that I'm busy working with the first four of their libraries as we speak.

OK, I now have my 64bit sample box, and it is purring nicely. I can load 3.95GB samples without any problem, but as expected it cr*ps out when it hits 4GB. I have tried to run two instances of FXT on the Slave machines using different ports in order to use more memory, but this doesn't seem to be possible on the Host machine, as I don't seem to be able to change ports for each instance independently. I'll report back if I have any success, as it would be a good stopgap until VSL gets its 64bit ar*e in gear. [:D]

DG

Which 64-bit sample box, which operating system, and what libraries, DG? Are you talking about VSL, PLAY, etc.?

@Nick Batzdorf said:

Which 64-bit sample box, which operating system, and what libraries, DG? Are you talking about VSL, PLAY, etc.?

Intel 2.66GHz Core 2 Duo
8GB RAM
250GB System
1TB Samples drive
DVDRW
256MB Nvidia GForce
XP x64
VSL VI
FXT

DG

I've now heard back from Max at FX-Max, and he says that it is not possible to run two instances of FXT on the Host machine using different ports, so unless I can think of another way to fool it, I'm stuck with 3.95GB for now. [:(]

DG

Hey DG,

I can't remember his name, but there is a user out there who's having some success running Sonar 6 on a slave machine. Shouldn't that allow you to get past 4GB? I'm basically planning on doing something like that in the next couple of months, so I'd be interested to know if it's actually possible.
My plan was to make a machine pretty much like what you've just built, and host the VIs in Sonar. I have an RME HDSP9652 card, which has 64bit drivers, so I'd use hardware audio, not FXT... I'm really hoping it will be possible to load > 4GB this way.

J.

It should work in Sonar, assuming that the Bit Bridge thing actually works. It should also work in the new version of Cubase/Nuendo (when it is released), as there will be a wrapper for loading 32bit plugs, assuming that this works as well! However, FXT will only load either 64bit plugs or 32bit plugs at the moment, so no mix and match I'm afraid.

DG

oh, yeah. I just realized I had a PM from him about this: it's *magnumpraw*. He seems to be running an XP64 Sonar 6 setup with some success.

J.

@jbm said:

oh, yeah. I just realized I had a PM from him about this: it's *magnumpraw*. He seems to be running an XP64 Sonar 6 setup with some success.

J.

Interesting, but Sonar is of no use to me I'm afraid. I'm waiting for VSL...... [:D]

DG

@DG said:

It should work in Sonar, assuming that the Bit Bridge thing actually works. It should also work in the new version of Cubase/Nuendo (when it is released), as there will be a wrapper for loading 32bit plugs, assuming that this works as well! However, FXT will only load either 64bit plugs or 32bit plugs at the moment, so no mix and match I'm afraid.

DG

Yes. Magnumpraw definitely told me he's using VIs in Sonar 6 on XP64, and the Bit Bridge thingy is working perfectly. So that could definitely solve your problem, I would think. I'm going to try that once I build my own XP64 beast.

J.

heh... we've got some overlapping posting going on here!

Yes, genuine 64bit VSL, OS, host, hardware, and so on, is obviously the real solution. But who knows how far off it will actually be... ???
[8-)]

J.

I don't understand how it could solve the problem. Sonar can't be hosted in FXT. If I used a standalone Sonar, then I could get more samples loaded, but I would still have to get MIDI to the machine and audio back again, unless I've misunderstood.

DG

Oh yeah, sorry. I'm thinking of a strictly hardware-based IO setup - hardware midi in, hardware audio out. That's how I'm going to approach it. Software is overrated anyway, IMO. [;)]

J.