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

@jbm said:

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.

More overlapping posts. [:D]

I don't see why it is such a problem to have a 64bit version of the VI player. It doesn't even have to have any extra features. 64bit has been around for a while, so it's not as if it is anything new. Max, from FX-Max, managed to come up with a 64bit version of FXT in a few days. Now I'm not saying that the Vienna player is as simple as his app. (although nobody else has managed to come up with one that works so well, so it can't be that simple), but I find it hard to believe that the VSL team have been caught napping and aren't thinking ahead.

DG

@jbm said:

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.

Fair enough. I quite like my one £5 cable, and all settings stored in the project....!

DG

@jbm said:

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.

Fair enough. I quite like my one £5 cable, and all settings stored in the project....!

DG

well, there's that... [;)]

I agree that FXT is a brilliant program. I just wish v2 would finally come out - it really is starting to seem slightly "vaporous" (though I'm sure it's not). All I'm saying is that I'm getting a bit tired of software workarounds. I mean, I know FXT isn't exactly a workaround, but in some ways it is... 24 channels of lightpipe running from my XP64 slave to my Mac would be pretty nice for me, I think. And besides, my real goal on the slave is just to have a single, definitive template running anyway. This way I could put the Sonar session in the Startup folder, and basically forget about the machine altogether. Bliss!

cheers,

J.

Does anyone know if say VSL doesn't come out with a 64-bit version, but I installed Leopard. Will it pose problems, or will 32-bit apps run just fine?

@Nathan Allen Pinard said:

Does anyone know if say VSL doesn't come out with a 64-bit version, but I installed Leopard. Will it pose problems, or will 32-bit apps run just fine?

Well, Leopard has to exist first. [:D]

It should be exactly the same as XP64, in that it will have the same limitations as any other 32bit app.

DG

@Another User said:

I don't see why it is such a problem to have a 64bit version of the VI player.

It's not that it's a problem to have a 64-bit version of any software. The issue is that there's no magic button to make it happen - it takes a lot of development!

@Another User said:

I don't see why it is such a problem to have a 64bit version of the VI player.

It's not that it's a problem to have a 64-bit version of any software. The issue is that there's no magic button to make it happen - it takes a lot of development!
Of course, but VI has been out now for 18 months. I would rather have a 64bit version, than any new features at the moment, and even before bug fixes! Of course other users will have other priorities, particularly Mac users, who don't yet have a 64bit OS. However, according to some software developers, 64bit support can be as little extra work as giving LAA support was, providing that the app. has been properly coded to start with. I can't believe that a company like VSL would have developed a sample player where this wasn't taken into account.

DG

DG - too right. I vote that we start a mexican wave and chant "64! 64! 64!" As soon as it's done, there will be NO MORE memory limitations (except for physical ram of course). I mean, that's HUGE right now.

I heard Leopard can run both 32bit and 64bit apps together at the same time with no problem. 32bit apps of course have their old limitations.

My vote is that VSL work on the 64bit issue first and foremost - it's so majorly huge to production capability especially with quad and 8 core machines for both macs and pcs... and after that is up and running then they should start to look at a 96khz release of the library... that would be awesome!

I would be especially great to be able to compose with 24bit 44.1 library, and then "flick a switch" on the VSL server if possible, so that it went ahead and loaded / rendered everything in 24/96 - so you could compose happily on whatever machine you have, but render the results in hi def. well, maybe that's a wish towards the end of 2008... but a good idea none the less. I think hard drives are getting cheap and big enough that you could have both 24/96 and 24/44.1 versions side by side to make it simple, and just have the server smart enough to load the same exact samples, in the different format.

Miklos.