@Nick Batzdorf said:

I've managed to load about 7GB on a 2 x 2.5 G5 and have it work fine. (Using the old "stand-alone outside DAW and plug-in inside DAW" trick.)...

I'm still trying to figure out some of the rhyme and reason behind what works and doesn't work. The next step is to see whether running stand-alone instances outside Logic would work better.

What's interesting is that the offline bounce of the cue was fine.

This is still a mystery to me. As I watch Activity Monitor, it seems that Virtual Memory is accessing all available RAM no matter if the instances are inside or outside of DP. I'm not sure which works better because the amount of data on deck to page to/from VM always exceeds the amount of RAM I have.

What's really odd is that at one time VM used to kick in with a lot more available than it seems to do now. More often the latest readings appear to be tapping in to a lot more available RAM as VM data increases. I no longer see the 3-4GB brick wall.

The more I learn the less I understand.

By the time that any of us understand this we will all be running 64bit OS and not worrying any more.

DG

"What's interesting is that the offline bounce of the cue was fine."

In all my RAM, disk, and CPU limitations, never once have my offline bounces been affected. Offline bouncing gets me through the thickest of tuttis. When the real-time factor is removed, most bottlenecks are irrelevant.

clicks and pops are because the buffer is overrun usually, and the cpu can't keep up with the audio stream. Also, the cpu meters are very deceptive in some cases, while you may not think the audio engine is "taking a hit" it in fact is, and it will rise up exponentially at a certain load point.

Nick: there is a bug with Ivory if using Logic your process buffer should be set to small, or something similar perhaps in whatever DAW you are using, or try freezing Ivory everything should clear up then.

Miklos.

Oddly enough I have found that freezing Viennna Instrument tracks in Logic, when the matrix is fairly complex, there are frequent cell changes (using both keyswitches and CC messages) and lots of CC data streams modifying different performance parameters does not work well - - the results often exhibit wrong patches and other inaccuracies. Perhaps this happens because the keyswitches are on a separate track assigned to the same MIDI Channel as the VI (which I do since the music starts as notation in Finale where using keyswitchs on the same staff with the notes can create problems and make the score look unreadable)? I get the best results when bouncing each track in real time - - except that when I do this, Logic freqently (approx 1 time out of 5) announces that Audio and MIDI have lost synch. Possibly things would be better if I merged the instrument and keyswitch tracks?

one of the reasons it's helpful to freeze is because when jumping between song positions you don't have to worry about going back to the last keyswitch because it's audio.

@mpower88 said:

one of the reasons it's helpful to freeze is because when jumping between song positions you don't have to worry about going back to the last keyswitch because it's audio.

Miklos.

You could try this: force legato on yor key switch notes (you will have to do this manually or put keyswitches in a seperate track and do it automatically) Then wherever you start Logic as long as you haven't got the "no transpose instrument" selected Logic should pick up and send the current keyswtch whereever you start. If you jump between sections with the transport continuously running I'm not sure this will work but each time you hit play the keyswitches should update.

Julian

That's interesting, Miklos. Thanks, I'll check that. Yes, this is in Logic.

"By the time that any of us understand this we will all be running 64bit OS and not worrying any more."

This is what I like: an optimist. [[:)]]

My fear is that we'll be running a 64-bit OS and worrying about something else. [[:)]]

Looks like it will all take longer than we all hope unfortunately. I'd say don't hope for the bugs to be worked out and everything smoothly "64bit" on either Vista or OSX before Christmas... and I'm usually optimistic... but we'll see [:)]

@Nick Batzdorf said:

That's interesting, Miklos. Thanks, I'll check that. Yes, this is in Logic.

"By the time that any of us understand this we will all be running 64bit OS and not worrying any more."

This is what I like: an optimist. [[:)]]

My fear is that we'll be running a 64-bit OS and worrying about something else. [[:)]]

Well, I'm considering changing to XP64 very soon, so I'll keep you posted.

DG

Switching to XP64 for other software, obviously, right?

I would of thought Leopard or Vista (in about 3 years) once they work out the bugs, would have been a better choice for 64 bit??

Miklos.

@Nick Batzdorf said:

Switching to XP64 for other software, obviously, right?

No, I'll be using FXT, same as usual.

D

Sorry that was an involuntary anti windows slip, I'm seeing a professional about it and working through the issues if you can be tolerat with me....

[:P] [:D]

PS windows sucks! he he he I'll never forget what you did to me Gates, All those YEARS!!!!!!! NEVER!!!!!! [6] [6] [6] [6] [6] [:D]

Oh darn, well that looks like three more sessions for me next week at $350 an hour...

[:D] [:D]

@mpower88 said:

Oh darn, well that looks like three more sessions for me next week at $350 an hour...

[:D] [:D]

Well, come back and chat when you've calmed down. [8-)]

DG

he he, ah, I was only playing around... [:D]

Just a quick comment on the original topic...

The thing I appreciate most about what they've done with PLAY is the networking and centralized control. The 64-bit thing is a given, and really only a matter of time. I also take very seriously Christian's cautious stance on the subject. There's a lot more to be considered than just getting the samples into RAM.

Anyway, if VSL could implement some centralized control system for networked VIs, that would be nice. Mind you, my recent experiments with FXT have revealed that to be a *brilliant* system, so it's not a huge problem. But the main thing is that I somehow can't see the multiple-machine sample "farm" going anywhere, anytime soon. Or even getting much smaller, for that matter. I mean, the network aspect of PLAY still implies a multi-machine setup (even though it's 64-bit), and the AI (DVZ) system *requires* multiple machines. My current setup actually doesn't host *any* VIs on my sequencer/DAW and I **LOVE** it! It's like being back in the 80s, with a room full of samplers, ready and waiting! Sweet. Not only that, but my FXT instances are all hosted on slave 1, so the "band" is persistent across projects, sequencers, and so on -- Logic, Live, Finale, Sibeius... I just load up whatever sequencer I want to use, and the orchestra's ready and waiting! (About 8 months and 2 machines later, I finally figured out a simple and convenient way to use these beasts. Nice!)

J.

The whole PLAY concept is intriguing enough to inspire serious consideration for this user who has quite a few NI-linked software bundles with EW.

64-bit support (requires Windows Vista 64-bit or Mac OS X Leopard 64-bit version). 64-bit support allows you to load many more instruments and voices, limited only by your system RAM (32-bit support is included also).

Windows users may be in slightly better position than Mac users right now in that the shroud of the 64-bit mystery is slowly being lifted in Windows than it is on the Mac. This is the first concrete statement about any 64-bit app to come for the Mac platform. While 32-bit support is "included", it remains to be seen whether Mac users will be able use PLAY in 64-bit with DAWs and other plugins concurrently which are firmly rooted in 32-bit.

The wording of the press release also implies that a 64-bit version of Leopard is a different software bundle from a 32-bit counterpart. This is spec because info about Leopard has been fairly cryptic-- with more promise than anything else. It will get here eventually, but "how soon" also remains to be seen.

It would otherwise appear as a cruel teaser to Mac users who read the GIGA GVI press release from more than a year ago where it was stated clearly that a Mac version was "already in development" with no word of such a version appearing since on the Mac platform to date.

Add to this the word from many other important virtual instrument developers, including the VSL team, whose word on the topic ranges from extremely cautious to doubtful at this time.

But even Vista has my attention in a big way as developers such as East West are taking a more pro-active approach to getting 64-bit instruments into the hands of users who need them sooner than later. Some will go kicking while others will go screaming-- let's see if the screams in 2007 are cheers or other words to be bleeped.

This page of articles and links dates back two years, but the information is still relevant.

http://www.cakewalk.com/x64/

"When I'm 64 (bit)" is a very well-written article in plain speak for those who are wondering but were afraid to ask. No doubt, for some members here this info will appear to be rather old news.

What I appreciate about these articles is that they go further than to say 64-bit will mean "more", but it talks about just how much more that will likely be.

The possibilities are endless. It's the probabilities that are holding us back.

Happy reading.