MacPro 3G and VI report

[JWL]

There has been relatively little info on VI on the Intels-- and this report is far from scientific. However, I thought I'd post some findings.

G5 2.5 Dual PPC, OS 10.4.8, 8GB RAM
MacPro 3G quad, OS 10.4.8, 9GB RAM

Both using Digital Performer 5.11, but with buffers set to 512.

Syncrosoft on both: 5.2.8.3 (LCC v 1.9.7.3)
VSL Installer on both: v 1.11

The G5 only seemed to be able to handle about 8 instances with one matrix loaded-- either an articulation combi or perf legato. CPU meter often in the red, but averaging about 80-90% at a stand still.

The Mac Pro actually loaded 20 empty instances (before I started loading sounds)-- with the CPU meter holding steady around 35-40%. With one patch loaded per instance as mentioned above, the CPU meter did not change.

The good news:

Activity Viewer reads:
Wired: 487.18 MB
Active: 197.76 MB
Inactive: 2.87 GB
Used: 3.55 GB
Free: 5.46 GB
VM Size: 7.37 GB
Pages I/O: 41263/0


The bad news:

On the Intel, I only got 17 instances loaded successfully. The 18th instance crapped out and the spinning beach ball of death is doing its thing as I type.

While my instance vs matrix tests on both the PPC and Intel are much less than the official 2.5 Dual PPC reports indicated (being 20-24 instances), I do find the notion of usiing 17 instances on the Intel encouraging while networked to the G5.

I hope to get a bit more scientific than this, but so far I am finding my Intel 3G results a little closer to the official PPC stress tests posted by the VSL Team some time ago.

So now it's time to force quit and start again!

btw-- load times are vastly improved on the Intel... not once did I see the brushed silver "please wait" prompt. Instantiation of 10 instances was approx 3-4 seconds. Had things not gone into beach ball mode, I would have had a total load time for you--

more to come.

If there is anything specific anyone would like for me to check, please let me know.

Cheers!

[Wolf Wein]

I was just writing up my current test results on a similar setup , when I saw this thread, so I'm adding my report here.

Disclaimer: I did by far not read everything that has been posted on this topic, so this might be old stuff...

my test computer: MacPro 3.0Ghz Quad, 16Gb RAM, OS 10.4.8 LogicPro 7.2.3 VI Cube

Just for the sake of trying how much I could load on my Mac I tried loading as much as I could in Logic and multiple copies of the standalone VI (VIS).

results so far: 10.6 GB (I'd attach a screenshot, but don't know how): 2.87 GB on the VSL-Server (= 7VIs in LogicPro); 10 VIS summing to 7.7GB. tested playback with a short sequence - seems to run fine. The Logic performance meter shows very little CPU usage, Activity Monitor CPU is at around 50%, so I think I could load more.

Now this is of course only of theoretical value, because:

1) I can't route the audio of the 10 VISs back to Logic easily (Jack does not work with VI, Sunflower only gives me one output, Aulab or RAX would use the VSL-Server again; other hardware workarounds are impractical for 10 VIs; I don't know of any other way to route audio from the VISs)

2) All standalone VISs share the same preferences file, so I'd have to adjust the midi input (I used IAC ports) each time I start the setup again.

also: this might all be obsolete once we go true 64 bit - but who knows when that will become a workable reality?

I basically post this, to show how much can be loaded on one MacPro and that this could be a very cool working environment if (Imean: VI are amazing already, this would just add to it):

a) VISs allow us to select a midi input channel + VISs allow us to select the audio output channel from the available hardware outputs or virtual outputs (AuNetend-receive might be an option (apart from the latency)). I read the VSL team argument: yes, but the VIs are not designed to be multi timbral and never will be. Makes sense to me, but they could remain perfectly 1 timbral (please help me - what's the correct term for this? mono timbral?), but still allow to select the midi channel and an audio output channel - just one per instance.

b) we find a way to let each copy of the VIS to have it's own preference file. I vaguely remember that there once was a preference manager app that allowed one to choose between several pref files for one app - might have been in OS9.

I'd be very interested to hear your thoughts on this.

[JWL]

@nelp said:

I read the VSL team argument: yes, but the VIs are not designed to be multi timbral and never will be. Makes sense to me, but they could remain perfectly 1 timbral (please help me - what's the correct term for this? mono timbral?), but still allow to select the midi channel and an audio output channel - just one per instance.

b) we find a way to let each copy of the VIS to have it's own preference file. I vaguely remember that there once was a preference manager app that allowed one to choose between several pref files for one app - might have been in OS9.

I'd be very interested to hear your thoughts on this.

I'm not certain quite "how" some of this might be accomplished, but I recognize that something along these lines would be incredibly handy, especially the MIDI routing. The needs of so many different users vary greatly and play against what the VSL Team deems necessary (or unnecessary, as the case may be).

I would think at the very least that OSX's networking could be improved. Having these features right in Core MIDI is a great idea, but OSX (or Leopard?) networking could go at least as far as MOL does, and there's no excuse for having to twiddle with complex setups with every session. Presently, there are too many little thing$ that play against the inherent functions of the DAW just to make it work, and I think that it could be easier somehow-- but how?

[stevesong]

The Standalone does NOT have to be multi-timbral, but, as long as we are stuck with the memory limitations imposed by 32bit systems and software, users of the VI Standalone would benefit greatly if the standalone had assignable MIDI channels (instead of using an entire IAC bus for one MIDI channel) and, even more importantly, assignable audio outputs.

Leopard is supposed to arrive in June and to be fully 64 bit. Perhaps a 64 bit version of Logic Xtreme (or whatever it is to be called) will follow shortly thereafter? And perhaps VSL will release a 64 bit version of its software as well? One has to hope....

[JWL]

@stevesong said:

Leopard is supposed to arrive in June and to be fully 64 bit. Perhaps a 64 bit version of Logic Xtreme (or whatever it is to be called) will follow shortly thereafter? And perhaps VSL will release a 64 bit version of its software as well? One has to hope....

Yep-- and all elements must be in place before anything can come of it. The question is just how long or how soon after Leopard appears will we see our DAWs and plugins address 64-bit. In some cases, I'd dare say that the question may be closer to "if" because no one's really talking except for East West at the moment.

[stevesong]

JWL:

I wouldn't fret about "if," only "when." I have no inside information, but, given VSL's responsiveness in general, I'd bet on them releasing a 64 bit version of Vienna Instruments software in a timely fashion. I also think Apple would have a strong interest in making its Pro Apps - - including Logic - - 64 bit within a reasonable time after the release of Leopard - - doesn't a 64 bit OS need 64 bit apps to show itself off? I'm confident MOTU will not let itself be left out of the game either - - they already have Windows XP Pro (64bit) versions of their audio and MIDI drivers as well as their Ethno and Symphonic Instrument virtual instrument libraries.

Of course there are companies where this changeover could take years (Finale, for example, is still not multi-processor aware) - but luckily Leopard will, according to Apple, run 32 bit software with no problem.

[JWL]

@stevesong said:

... but luckily Leopard will, according to Apple, run 32 bit software with no problem.

Good stuff, Professor. It's your last statement that is at once a reason celebrate and a reason to wonder. 32-bit addressing lives on. Yay!!

But it also means that 64-bit addressing is less of a priority than it is an eventuality. In time-- in time... it will all come around, no doubt.

And it's good in the bigger picture because it doesn't sound as if there will be any downtime for users.

But for VI users, it's also understandable why the desire for more/better RAM access and instance counts generates everything from wonder to anxiety, partly fueled for Mac users by machines that now take 16GB RAM.

But here's the twist with it all: to release 64-bit apps too soon is unwise because not everyone has a MacPro just yet and sales would be relatively slow until such time enough of the Mac market will buy into the hardware capable of running the software. That catch-22 is that this is because apps have been slow to go Universal Binary, but that's coming along nicely. One thing Apple has playing in its favor is that even the PPCs that take 8GB RAM will benefit as well, so the transition is not such a rocky one, however slow. Even with PPCs, I'm sure that Apple is eager to leave the IBM architecture behind and having to optimize on both platforms must be anything but a cinch.

Perhaps Apple is putting the cart (hardware) before the horse (software) in a sense, but if the hardware is establishing itself already, then I have to think that Apple's Pro applications are prime candidates for 64-bit threading some time soon-- and that includes Logic, and that's good news for Logic musicians. But then we heard some of the same things with Panther and Tiger which never transpired.

I'm leaning towards the notion that the real attractiveness of Leopard's 64-bit threading will mean little unless Apple releases its pro apps in 64-bit at or around the same time that Leopard is released. Otherwise, it's all vapor and hype as it was at the autumn MacWorld convention-- which was followed up by a very conspicuous silence about it in January.

The entire process is both awkward and clever, really.

[stevesong]

JWL:

No reason software cannot have both 32bit and 64bit iterations simultaneously - so people will not be shut out. As you point out, Leopard is supposed to run in 64bit mode on G5s as well as MacPro's. And NAB show is April 14-19 -- Apple is rumored to be showing something significant there..."Final Cut Xtreme" perhaps - running on 8 cores and lots of RAM...

[JWL]

@Another User said:

... And NAB show is April 14-19 -- Apple is rumored to be showing something significant there..."Final Cut Xtreme" perhaps - running on 8 cores and lots of RAM...

Yes, I've heard this rumor and didn't want to make more of it than it is. But if there is a Final Cut Xtreme coming then an Xtreme DAW can't be too far behind.

It cracks me up [:D] to see how Apple keeps outdoing itself with the superlatives: Pro, Xtreme... I can't wait to see what's next!

[stevesong]

@JWL said:

ndeed-- no downtime. I don't think there could have been any better news than this

JWL:

I don't know for a fact that software will exist in 32bit and 64bit iterations, but it would make sense that it would - - just as there Universal Binary versions of software that will run natively on PPC or Intel and there are 32bit and 64bit versions of some Windows applications - for Windows XP (32bit) and Windows XP Pro (64bit) respectively. It would seem to make sense for software manufacturers to offer both because they would be able to sell software to those who had 32bit hardware and those with 64bit capable hardware. For example, the first MacBooks and MacBook Pro's had 32 bit processors, so it would seem unlikely that Apple would offer a new version of Logic that would not work on those machines. We'll soon see what happens...

[JWL]

@stevesong said:

JWL:

I don't know for a fact that software will exist in 32bit and 64bit iterations, but it would make sense that it would - -

From 2006 Keynote:

In Leopard, you can have a fully native 64-bit Carbon application and we did this in a completely compatible 32-bit compatible way. That means that you can run 32-bit and 64-bit applications side by side. None are emulated.

[cm]

@Another User said:

means that you can run 32-bit and 64-bit applications side by side

no surprise so far, we see this on 64bit systems already - the right question would be: are they communicating with each other? or: are tools connecting them communicating between both? we will see ...
christian

[JWL]

@Another User said:

the right question would be: are they communicating with each other? or: are tools connecting them communicating between both? we will see ...
christian

Yes, only hands-on experience will tell for sure-- but the keynote did say "none would be emulated". Wouldn't anything else be a waste of time and resources-- not to mention a black eye for Apple?