DP 8

[Michael Canavan]

The Master EQ is a very very Powerful Tool, ProVerb is great, Leveler is pretty great...The Delay also, just giving props.

Sure, embedded plug ins are always a mixed bag though. MW EQ is heavily used by me for sure. Same with the Pro Verb and innocuous plug ins like Trim etc.

This has nothing to do with DP8 really more of a DAW thing, but high quality embedded plug ins lose their appeal when you use third party applications for mastering for instance. I'm in the market right now for a linear phase EQ on the lines of MW EQ, and honestly if I could use MW EQ in DSP Quattro I wouldn't bother with a linear phase EQ at all and just use it.

Anyway count me in as someone who's thinking there's more to DP8 than what's been mentioned, subtle stuff that appeals to geeks like me, as that's been the case with the last three upgrades.

[MIDI Life Crisis]

Well, the rumbling on the street is that MOTU will drop MAS and if that happens and the plugs go AU, then you can have the MW plug in any app... no?

[dogBoy]

They're allowing for VST 's too...... "I will not bogg down my system with more needless stuff,repeat"... I'm talking to myself..."I will not bogg down my system with more needless stuff,repeat"...

[Michael Canavan]

Well, the rumbling on the street is that MOTU will drop MAS and if that happens and the plugs go AU, then you can have the MW plug in any app... no?

Yeah that's probably not going to happen. Thing is every DAW with embedded plug ins of any quality uses those plug ins as a carrot to draw you in. If you could buy DP and get a bunch of AU plug ins that loaded into other applications like DSP Quattro and Mainstage etc. then you would see those very same plug ins floating around the web free range, and people would be even more inclined to "justify" their not owning DP but having MWEQ etc. Beyond that MOTU started selling the Master Works Edition a while ago.... What would be cool is if DP allowed you to use them as AU plug ins as long as you had a legitimate copy of DP on your system!

MAS I believe gets sort of a confusing legacy from us non coder types. Basically all DAWs have something akin to MAS in that they have an audio handling section of code that takes care of both embedded and AU/VST plug ins. In the case of MAS though MOTU had their own version of AU and VST, but remember most VST hosts like Sonar, Traction, Studio One, Live, ReNoise, "Host that can't be named" etc.... are not the makers of the VST standard! and have to have a "wrapper" for VSTs in their DAW. Same with AU, it's not that MAS is some legacy code outright, it's the name MOTU gives DP's audio engine, and their plug in code. MOTU Audio System, so all MOTU are keeping around by still allowing Audio Ease for example to code for MAS is a set of instructions, not necessarily a whole layer of abstraction away from the audio engine. I don't believe that the MAS AU plug in has to pass through the MAS plug in instructions before reaching the audio engine.
I would bet that the Windows version of DP still call their audio engine MAS, and that there is something akin to the MAS AU plug in for VST on Windows. MAS_vst.dll.

[kgdrum]

Well, the rumbling on the street is that MOTU will drop MAS and if that happens and the plugs go AU, then you can have the MW plug in any app... no?

I actually hope MOTU does away with MAS
I had problems recently with a plug, the fix was disabling the MAS and run as AU.
Isn't there a way to write a plug as an AU and embed into DP so it needs something proprietary to DP to run? For MOTU/DP plugs?

I do think with the complexity of current users systems with the wide assortment of plugins,VI's,&software available, as much standardization as possible could only help minimize conflicts and problems.

I am the 1st to admit I'm not a code writer and I really don't understand this stuff on any kind of technical level but thinking on a instinctual level I suspect using the major plugin formats only, could offer some advantages, I don't think any 3rd party developer that make plugs in the AU format will ever put the same focus & resources into developing for MAS that they use for AU & VST.

[Michael Canavan]

I am the 1st to admit I'm not a code writer and I really don't understand this stuff on any kind of technical level but instinctually using the major plugin formats only, could offer some advantages, I don't think any 3rd party developer that make plugs in the AU format will ever put the same focus & resources into developing for MAS that they use for AU & VST

The people like Audio Ease that make a MAS version do it because MAS mostly is the most stable for DP, because MOTU came up with the plug in format. I had a similar issue with Speakerphone, but normally I just use the MAS versions. It's as close to embedded as you're going to get.

Think of it outside DP, Logic in OS9 days ran VST on both PC and Mac, but their embedded plug ins were not VSTs, Live's embedded plug ins aren't AU or VST, they run in Live's own instruction set I'm sure. DP's embedded plug ins aren't MAS in the same way that the MAS version of Speakerphone is.

[kgdrum]

Well all I can tell you I have been beta testing for a major developer, *nda*
4 or 5 DP beta testers were having the same issues with the software running MAS, the solution was disable the MAS version and run as AU: problems are gone.

I'm sure you know more about this than I do but wasn't MAS developed before AU became a standard format?
I would think if DP is being rewritten now
putting it together in standard formats would be simpler for all of the developers.

[dogBoy]

Well all I can tell you I have been beta testing for a major developer, *nda*
4 or 5 DP beta testers were having the same issues with the software running MAS, the solution was disable the MAS version and run as AU: problems are gone.

I'd think the problem wasn't the MAS but your developers. Motu owns the house and your *nda* is visiting.

I trust the MAS plugins because they are proprietary. Maybe I'm Polly Ann-ish.

[supersonic]

Could someone explain to me the whole 32-64 bit issue? The advantages of one over the other and compatibility with the plug ins, ie can a 64bit version of DP work with 32 bit plug ins.

Thank You

[Michael Canavan]

Well all I can tell you I have been beta testing for a major developer, *nda*
4 or 5 DP beta testers were having the same issues with the software running MAS, the solution was disable the MAS version and run as AU: problems are gone.

I'd think the problem wasn't the MAS but your developers. Motu owns the house and your *nda* is visiting.

I trust the MAS plugins because they are proprietary. Maybe I'm Polly Ann-ish.

Again, from what I can tell, MAS is both what MOTU call their audio engine and what they call their instruction set to plug in to that engine. AU doesn't run through the MAS plug in instruction set. I'm not a coder, but I'm pretty certain of that. MOTU developed AU MAS instructions for it's MOTU Audio Engine, to compliment their "MAS plug in" instructions. Any developer that has more problems with the MAS plug in version isn't proving that MAS is outdated or not as complete as AU, but that they are better programmers for AU than MAS. Think about it, MAS allows for more MIDI tracks and isn't much of a layer of abstraction from the audio engine, simply by virtue of being developed completely in house.

I do think we will see the retirement of MAS at some point, (MachFive 3 is an example) but it's going to require AU to start improving a bit really. It's been years and years since AU had an update and VST 3 is going to destroy it in terms of features if Apple don't step up.

[bayswater]

Did MOTU actually write direct support for AU, or did they just develop a wrapper for it? I assumed that's what MAS AudioUnit Support.bundle is for. Maybe not.

[Michael Canavan]

Did MOTU actually write direct support for AU, or did they just develop a wrapper for it? I assumed that's what MAS AudioUnit Support.bundle is for. Maybe not.

Yeah it's all conjecture to a degree, but again MAS is the name of their plug in format and their Audio System, so it's inconclusive to assume that AU runs in a shell. Also, the thing is all plug ins, every single one of them talks to the audio system in every DAW through a shell.

This much I do know, a plug in is a set of instructions on how to treat audio, ( a delay plug in takes the audio and repeats it etc.), that set of instructions is plug in type and platform independent, the real fact is all plug ins are "wrapped" in a set of instructions and GUI conformity that allow said DAW to host it. This is why you now get companies sometimes coding only an AU version of their Windows VST plug in. It's supposedly much easier to code a Mac VST from a Windows VST, but it's not that much easier, and AU is a bigger market on the Mac side. At first there was a lot of wrapped VST- AU plug ins, but that died down as it sometimes leads to crashing AU's.
In the end of the day any layer of abstraction if done right isn't that much, so it's IMO more worthwhile to think about which AU's are unstable etc. than to conjecture as to what is causing it, since we aren't coders and in the end the most important thing is that it works.

IMO it's not the MAS AU layer that needs work it's AU itself, and that's in Apple's hands.

[James Steele]

Did MOTU actually write direct support for AU, or did they just develop a wrapper for it? I assumed that's what MAS AudioUnit Support.bundle is for. Maybe not.

Pretty sure it works that way. Try removing it and none of your AU plugs will be available on DP.

[bayswater]

That's what I figured. If DP moves to direct AU support, we could see increased efficiency.

[Michael Canavan]

Did MOTU actually write direct support for AU, or did they just develop a wrapper for it? I assumed that's what MAS AudioUnit Support.bundle is for. Maybe not.

Pretty sure it works that way. Try removing it and none of your AU plugs will be available on DP.

Again, I don't think that's an indicator that AU is in a "wrapper" for "MAS" as a plug in format, or that "direct AU support" will mean increased efficiency. MAS will not go away, it's what MOTU calls it's audio engine in general, it's not just plug ins, it also handles audio tracks, audio cards, and all DSP. Again, look at Logic, it's embedded plug ins never had a way for third party formats like VST or AU sit next to them in a folder. I think the only difference here is Emagic/Apple hid the folders we can all see in our Audio folder in OSX.

DP is and never has been less efficient that any other OSX DAW in terms of AU handling. Logic is a special case for two reasons: it's always had a super efficient engine even in Emagic OS9 days it was more CPU efficient by far than Cubase or DP, even using the Steinberg Cubase VST format! Secondly it's always had direct access to the AU team at Apple. If any of you remember, MOTU designed DP to handle the AU spec 100% efficiently and Apple had tweaked their spec without telling anyone to make it work in Logic's odd audio engine!

IMO there are plenty of things to worry about with DP in terms of having it run efficiently, but comparing it's performance to the only DAW I know of that beats it in terms of CPU use that's owned by the company that makes the OS it runs on.... Again Logic is the only DAW that beats it, and even then not in every case. Logic sometimes for some users has really bad multi core support for instance.