MOTUnation.com

MIDI Life Crisis wrote:Do you have the manual?

Only the PDF.

zed wrote:

kgdrum wrote:just confirmed with MOTU,no bridge for 32bit plugs or VI's so I do hope UA & the other stragglers get the 64bit their upgrades finished.

With this very unfortunate development, I will no longer be one of the early adopters.

Have another look at the details on motu.com. There's a lot of good stuff there besides the 64 bit mode.

One question though -- will the new plugins included with DP 8 run with DP in 32 bit mode?

Seems like they should. I doubt MOTU would disable them in either mode.

zed wrote:With this very unfortunate development, I will no longer be one of the early adopters.

Zed, I originally thought so too, but there are two things you should consider:

A) 64bit mode is not the only big architecture improvement of DP8, it's also full Cocoa, which will mean it should be much more CPU friendly. Honestly, I think this is probably even bigger a deal than 64bit. You can still run DP8 in 32bit mode, it will run all your old 32bit plugins, AND you'll still get the cocoa benefits.

B) $100 for Plogue Bidule and you're set for old 32bit plugs.

Prime Mover wrote: B) $100 for Plogue Bidule and you're set for old 32bit plugs.

So we have a convert! LOL!

Seriously, it is one awesome app and there's a free demo, damn it!

Caveat: Setup can be a beast. YouTube videos help a lot!

PB is sort of overkill just to host plugins, isn't it?

Not if you need both the 32 bit VI and the 64 bit DP. I do.

You may now kiss the bride.

What I mean is that there are other applications that will host plugins. PB does a lot more.

AU Lab is free and looks like it does most of the things you would need to host VIs and Plugins. I tried it with Logic a while ago, but didn't really have a need for it. DSP Quattro is another alternative, if you already have it.

Ummm, AULab is an application. Sort of defeats the purpose, as most VIs have standalone components. The goal here is to run 32bit plugins inside a 64bit application. Plogue Bidule is an AU plugin (it has a standalone app too) that can run inside a DP project.

Seriously, setting up a signal path from outside DP to run a few plugins is a mess, and limited to say the least. To my knowledge there are only two plugin VI hosts that can act as a 32bit -> 64bit bridge: Plogue Bidule and VEPro.

Now, if someone knows of a small AU that can act as a bridge, then PLEASE let me know.

Why does it matter that it's an app? It hosts AUs, accepts MIDI, outputs to internal audio channels, etc. If all you need is somewhere to send a signal for processing, or somewhere to host a VI you can send MIDI too, it ought to be fine.

bayswater wrote:Why does it matter that it's an app?

Why does it matter? Are you kidding me? First off, your DP project suddenly doesn't contain all of the necessary components, so you've got to coordinate between external and internal software components. Secondly, you lose quite a bit of functionality of the DAW: tempo sync, VI freezing, etc. Then, you have to use some sort of interapplication audio bus like Soundflower, which as good as it is, introduces additional latency into your signal. All of this is just really inconvenient. I guess it would be fine if you just need to do something once in a while, but if you're using the plugs all the time, like me, it's really bad. Not to mention, we're ONLY talking VIs here, for those who have 32bit effects, then the back & forth signal routing would be massively problematic.

Also, most VIs have standalone versions anyway.

Prime Mover wrote:

bayswater wrote:Why does it matter that it's an app?

Why does it matter? Are you kidding me? First off, your DP project suddenly doesn't contain all of the necessary components, so you've got to coordinate between external and internal software components. Secondly, you lose quite a bit of functionality of the DAW: tempo sync, VI freezing, etc. Then, you have to use some sort of interapplication audio bus like Soundflower, which as good as it is, introduces additional latency into your signal. All of this is just really inconvenient. I guess it would be fine if you just need to do something once in a while, but if you're using the plugs all the time, like me, it's really bad. Not to mention, we're ONLY talking VIs here, for those who have 32bit effects, then the back & forth signal routing would be massively problematic.

Also, most VIs have standalone versions anyway.

Yes, it takes a bit of setup, but it's not as difficult as you suggest.I've put my UAD-1 in an old G5 and set up V-Racks in DP with all the routing and latency compensation to continue using it. Likewise many people are using slave computers to run VIs where similar routing and timing problems exist. It's not going to be any more difficult to use something like AU Lab. But in your case, if the main issue is Korg Legacy, PB is all you need.

Sure, in fact, it makes you feel kinda lazy considering that 20 years ago, pretty much all effects were done outside the box with sends and returns to hardware processors. I guess you can say we've become a bit spoiled. But on the other hand, it's how we've become used to doing things. If we were sending and receiving out to hardware on a regular basis, it would become easy and second nature. But in the modern day of in-the-box audio editing, it's fairly uncommon. Digital hardware processors are kind of a ridiculous concept, and analog processors are quickly becoming synthesized with fairly decent accuracy. Probably a majority of users (myself included) no longer use any hardware processors.

The concept behind a "Digital Audio Workstation" is to try, as much as possible, to unify all of the editing tools into one manageable system, where settings can be saved together and no re-routing is required between projects. Exceptions can be made for analog hardware because some of them have qualities to them that digital processing has not yet achieved. However, anything digital (hardware or software), can be completely folded into the DAW environment without any creative loss. I would call this "jury rigging," because it's not really being used the way it was supposed to be, and isn't the most efficient use of the technology.