Someone posted this on the Logic TDM mailing list (which I still skim even though I'm not using TDM anymore).

http://www.xcellent-productions.de/downloads/activity2.png


[:)]

....... right [:D]

J.

So why does my G5 2.0ghz crash when VSL server reads 1.4Gb RAM (real mem)? Is this not normal?

Miklos.

@jbm said:

Hey Stephen,

Well, as I say, I haven't actually got it working with Logic. It just works taking direct hardware midi input, and sending audio directly to my RME card. So I don't know how it will work with Logic -- it just works in principle.

However, if I were going to seriously try, I'd probably try using the IAC bus or MIDI Patchbay for MIDI and Jack OS X or Soundflower for audio. Give it a go and let me know what happens!

Has anyone got any further with this?

I'm keen to use the Standalone along with VI plugins in Logic, but I have no idea how to do the MIDI and audio routing. (Something that works like Rewire to get back into Logic?)

I now have a Dual Quad with 8 GB RAM so I'd really like to maximise my resources here.

@jbm said:

Hey Stephen,

Well, as I say, I haven't actually got it working with Logic. It just works taking direct hardware midi input, and sending audio directly to my RME card. So I don't know how it will work with Logic -- it just works in principle.

However, if I were going to seriously try, I'd probably try using the IAC bus or MIDI Patchbay for MIDI and Jack OS X or Soundflower for audio. Give it a go and let me know what happens!

Has anyone got any further with this?


My apologies, I didn't see beyond the first page of the thread so missed all that great stuff re: Soundflower, jack and aggregate devices. Thanks everyone for your excellent theories, testing and explanations.

I now have two standalones working nicely.

1) output to Built-in Digital out connected to Optical S/PDIF in of Ensemble

2) Soundflower (Ensemble + Soundflower aggregate)

I've spent 3 hours trying to get Jack happy and no luck. Maybe I'm just being thick. Should I be able to use it to route a 3rd standalone output assigned to Ensemble, so that the Audio routes to a spare Ensemble DAW input (e.g. to 13/14)???

Ensemble doesn't have a loopback mode, i.e. it can't route outputs back to inputs without a cable. As far as I know the only ones that do that are RME's interfaces, but Metric Halo is adding a loopback feature to their interfaces.

The Ensemble sure does sound nice, though.

I think we need a step by step tutorial and links to the relevant sites / third party software, plus some diagrams and screen shots would help ! [[:)]]

This is a very clever and excellent work around by the way, congratulations to the masterminds behind it. I agree, VSL should release a standalone version with the option of selecting a different output - we're not asking them to implement this workaround as an officially supported feature, just quietly allow a standalone to support *choosing* the output (as opposed to multiple outputs) - they can even say "we don't support this work around we are just adding a tiny little bit more functionality to the stand alone in case people would need to use it" [[:)]]

Of course by now I imagine they are hard at work on the 64bit version of the server??!! But then again who knows when Leopard + Cubase / Logic + VI will be a workable up to standard and reliable set up?? It could take many months after the initial release of leopard before it's all bug free, and it will probably be the Cubase / Logic side of things that will take the longest to be worked out. Armchair speculation of course...

Miklos.

I'll put one up on www.VirtualInstrumentsMag.com shortly. We've had yet another letter on the subject, which I'm answering in the magazine, and I'll just stick it up there as a perennial article.

Give me a few days...

And of course I don't mean to preempt VSL in any way. [:)] That's in addition to what anyone cares to post here.

By the way the latest Metric Halo software's loopback mode works very well.

Hey you remembered I have a 2882 [:)] what a memory! I don't know my age or the year most mornings let alone the day of the week.

Thanks Nick you're a champion for the cause! Your good work is much appreciated.

Miklos.

As somebody who has just bought a new 8 Core Mac and would dearly like to be able to use more than the 3-3.5GB of memory Logic allows you to, this whole thread is like stumbling over Atlantis!

I'm going to try out the Soundflower/IAC approach outlined earlier in this thread, but I wondered if there wasn't a more stragiht forward way.....

Why can't one simply run a separate VST host on the same Mac, run the additional VI plugins in that, and route the audio into Logic via Rewire. This way 1) no additional audio drivers and routing is needed, 2) no additional MIDI routing is needed 3) you can save and load all your extra instances of VI, with their settings intact, in one operation and 4) you can have as many separate stereo pairs running via REwire into Logc as you want.

I must be missing something obvious here (and I admit I haven't tried it yet), because this seems like the easiest way to have double the amount of RAM available to VI. I've been experimenting doing exactly this on our WindowsXP machine, which runs the brass element of the symphonic cube, hosting the VI plugin in Acid (theoetically Reaper, Live, Fruityloops etc. could also be used), and routing it into ProTools HD on that machine using REWIRE. Seems to work a treat.

Please tell me why this can't be done on a Mac, so I can stop dreaming and get stuck into the whole Soundflower and IAC adventure.

Many thanks

Jules

Just going over all the details of this whole issue again, I'm wondering if the reason my suggesstion is not going to work so well, is that both sets of plugins (those in Logic and in the separate VSTi host) will use the same VI server application for hosting samples, meaning actually there's no benefit to having a separate host.

Does anyone know if that's the case? I suppose that's why the focus has been on standalone instances, which address memory as a separate application ..... oh well, it was worth suggesting.

Jules

Trailerman I think you are right. But here is another way of doing things on an 8core machine. Even at low latency you should get 20 instances of VI running at once, so why don't you just write 20 instances at a time. Then freeze say ten of them, continue adding / writing, freeze a few more. The 8-core should freeze pretty fast. If you use Logic, it will retain all the samples in memory - not much help. But if you use Cubase, it actually removes the samples and the VI instance from memory (but still remembers all the settings for when you unfreeze) - so you can literally write as many tracks as your hard drive can feed audio into the 8 core mac - 128 stereo tracks? Then you don't have to worry about a memory limit anyway. Of course you will not be able to have all tracks live at the same time, but being able to have 20 tracks of your choosing live at one time is not a bad trade off (but you will probably need to have many of those tracks optimised at some point as well, or else have less tracks live at any one time). Depending on what you load per instance 20 tracks is not unimaginable, but if you load a lot of samples on every instance, maybe 8-10 tracks would be more doable from a memory standpoint, still, again it's not a bad scenario. Freezing on an 8 core shouldn't be too painful. On my dual 2.0 G5, it's VERY painful...

Miklos.

Trailerman, the answer to your question two posts ago is that the plug-in gets one helping of RAM regardless of how many hosts it's running in. The reason is that the plug-in is actually a MIDI/audio router to and from a separate program running outside the host. That means its RAM space is separate from the host's, but there's only one program running on the machine rather than lots of plug-ins.

On the other hand each instance of the stand-alone program gets its own memory allotment. You have to rename each instance, of course - Copy of V.I. Player, or whatever.

Come to think of it, I wonder how hard it would be to make the program launch multiple instances of the VSL plug-in server application? That would let you run multiple hosts, and it would also solve the "no individual audio interface outputs addressed" issue...

Hm. Another one for the feature requests list?

Thanks Nick. That's what I eventually managed to figure out - sorry to force you to regurgitate it all yet again.

I agree that it should definitely go on (near the top of!) the feature request list, and looking at the way VSL have deigned the plugin, they clearly believe that memory availability for their instruments is a huge issue. I'm sure your extremely clever standalone approach works well, and I will grapple with it as soon as we have out Mac Pro set up, but just having one or more additional hosts running all the extra instances one needs might be more straight forward, if VSL could make it possible.

Incidentally, the logistics of getting it working in separate hosts seems very doable - after trying multiple VSTi host applications with mixed success on our Windows XP machine, Plogue Bidule seems to be a perfect, unbloated and amazingly flexible application for this kind of use.

Thanks again

Jules

I don't know what VSL's plans are but I would assume that given the imminent release of OSX Leopard and the already released Windows Vista 64bit, it would make sense to put development efforts into creating 64bit versions of the VSL server and client app (au/vst plugin), rather than developing ways to have the VSL server run multiple versions of itself and plug in access multiple versions of the server - which would have a very limited life in terms of practically needing to have that - because once leopard is out and Vista is actually usable for something other than being blended (ha ha) then a 64 bit release of the VSL server and plug in would completely negate the need for the workaround anyway. So, it's just a matter of time - I would say my estimation, January 08, Well have 64bit, OS's, much cheaper RAM and 64bit Cubase and VSL, and hopefully a 64bit Logic 8 too. Until then, Nick's workaround is a fantastically successful one although for me, as Borat says, "not so much", as I have a slow machine anyway...

M

[:D] [:D]

Jeez you worked hard to get that Borat quote in Mpower!! [:D]

I'm sure you're right about 64bit and prioritization, although personally I won't be going near a 64bit OS for at least a year, when I know all the kinks have been worked out and all the applications and plugins needed are fully stable. At that stage, I'll give it a spin, and no doubt say "I like!!!", to quote Borat yet again!

Jules

PS. Sorry Mpower I completely missed your post above about freezing. Unfortunately I use Logic, and also, I have this thing about freezing until I've put the full structure down, which is often right at the very last minute. Nonetheless I take your point - there are probably more efficient ways of working, which would keep everything under one roof.

Jules

I think many may be surprised at how quickly leopard comes up to standard as a stable OS. Think about how badly Vista was received, so unstable, and basically useless at launch. Historically the Mac OS has been very good at launch, if with some bugs and kinks, I think one of the major releases was touted as being somewhat unstable, but nothing in the arena of Vista. They're put off Leopard to October which is also something they normally don't do, unlike MS who put off Vista for year after year. I would say they are well aware of all these facets and more, and it's likely that come October they'll be wanting to release a major OS update that flys in Vistas face by being surprisingly stable, and ready to rock and roll. Even for music production I would say the major issue will be host's being updated more than the OS, and I would say December / January - things will be quite workable. In that case, you can throw 8 - 16 Gb RAM in your G5 [:)] Or if you have a MacPro the max right now is 32Gb and VI will be able to access all of that if it is 64bit!

Miklos.

By the way the Borat quote came quite naturally and easily [:)] Why, you like?

Miklos.