Why don't more developers create AUs as well as VSTs?

[eigentone]

All the good stuff by legit developers is cross-platform, anyway.

That's your opinion.
EDIT: I am curious, what makes a developer 'legit'?

Seriously, you need to get a clue. A "legit" developer is one certified by planet trauma as legit.

I'd love a web badge for this certification.

[eigentone]

This is a simple question to answer: resources.

VST uses 1 API, AU uses another, RTAS is a third API. And they are all different. This means anyone programming a plugin to any standard has to have:

1. development time
2. debug time
2. QA/Test time

And you need to do all 3 for each supported platform.

Some people sell APIs that try to hide all of this from you (JUCE is one example). The problem is it's never 100% abstracted so the details still leak through.

It's a lot of work to make software for 1 target. It's even harder to make it for 2. It's starts getting really tricky for 2+. It's not like LinPlug or U-He can just take their vst and run it through an "AU Maker" machine.

There. Now why is this thread 11 pages?

But that end of the code doesn't account for the majority of the development time. Devs (should) use an abstraction process... basically to hide the plugin format specifics from their program as much as logically possible. It does account for 'too much time', especially for indie devs, because they have wheels to reinvent - a lot of development overhead to initially meet and maintain that compatibility. In a well designed library/build system, the abstraction/compilation/build serves as the the 'AU maker' machine. In essance, you'd have to determine what the plugins you develop need, and go by the minimal feature set needed (you probably need to render audio, and you probably want to know a parameter's value). It's a tough initial hurdle, though areas like graphics can be more painful. Host specific issues can be far more painful. This all assumes you're developing everything in house (not always the case).

J

[Big Tick]

It's a lot of work to make software for 1 target. It's even harder to make it for 2. It's starts getting really tricky for 2+. It's not like LinPlug or U-He can just take their vst and run it through an "AU Maker" machine.

Well actually, to share my own recent experience, making an AU out of Rhino wasn't that hard, thanks to VstAU. The really hard part was porting the PC vst to Mac vst, mainly because I had not thought cross-platform from the outset.

'Tick

[mcnoone]

There. Now why is this thread 11 pages?

Because it's filled with mac bashing trolls.
I think yours was the most useful post in the last 8 pages though, so things are looking up.

As far as I'm concerned, people who hate mac's, hate freedom of choice.

[eigentone]

I understand the historic reasons for numerous API's, but could a collaborative effort by enough plugin and host devs force the adoption of a single standard? Maybe with a BSD-type license?

This has been discussed, as well as universal wrapper APIs for plugin devs to use, unfortunately, I have not seen it materialize in a public/shared lib. This may be for legal/license reasons. Devs do share code privately.

[bmrzycki]

But that end of the code doesn't account for the majority of the development time. Devs (should) use an abstraction process... basically to hide the plugin format specifics from their program as much as logically possible.

Abstraction layers are famous for "leaking". What you say should be simple and straightforward. Once the real world gets involved however these layers can actually cause more problems than what they were originally designed to separate.

It does account for 'too much time', especially for indie devs, because they have wheels to reinvent - a lot of development overhead to initially meet and maintain that compatibility. In a well designed library/build system, the abstraction/compilation/build serves as the the 'AU maker' machine.

It's be nice if you could always do this. Unfortunately, real world code almost always has 1 or more crufty sections with comments along the lines of:

Code: Select all

/* Hack needed for Sonar and latency issues */
(magic code here)

And that magic code could be different for 4-5 hosts, and could need to be different for the Mac/Win version of the same host and different for the AU/VST version. That's part of the testing section I mentioned.

In essance, you'd have to determine what the plugins you develop need, and go by the minimal feature set needed (you probably need to render audio, and you probably want to know a parameter's value). It's a tough initial hurdle, though areas like graphics can be more painful. Host specific issues can be far more painful. This all assumes you're developing everything in house (not always the case).

These are all things that layers like JUCE (and others) are meant to do. You program the actual DSP alg and the heavy lifting is done by the API. But as I mentioned before, if something breaks you have to crawl through someone else's API to debug. That can make debugging a lot harder. Other companies have build their own engines that they add/modify for each changed plug. But the thing is, both of these situations go back to what I said before. It requires more resources.

If a dev (indie/commercial/whatever) really knows VC++, understands the VST API and can get something working quickly that might be the path he/she takes. Making AUs means the dev has to have at least 1 mac, and the time to learn how to make AUs inside a totally different development app (Xcode). There's a hell of a lot of work to make one simple VST/AU pairing.

[bmrzycki]

It's a lot of work to make software for 1 target. It's even harder to make it for 2. It's starts getting really tricky for 2+. It's not like LinPlug or U-He can just take their vst and run it through an "AU Maker" machine.

Well actually, to share my own recent experience, making an AU out of Rhino wasn't that hard, thanks to VstAU. The really hard part was porting the PC vst to Mac vst, mainly because I had not thought cross-platform from the outset.

Sounds like a bit of luck helped too.

From what it sounds like your app isn't a native AU but rather a repackaged VST with an AU stub?

Regardless, I'm glad you (and your users) have more choices for their plugs from Big Tick.

[Big Tick]

From what it sounds like your app isn't a native AU but rather a repackaged VST with an AU stub?

Indeed, but who cares, really - as long at it passes the AU validation, loads in Logic and AUlab...

[duncanparsons]

..thanks to VstAU..

thx 'T, hadn't come across that ace!

[dbrane]

Devs do share code privately.

Good to hear!

[Zaphod (giancarlo)]

In essance, you'd have to determine what the plugins you develop need, and go by the minimal feature set needed

in my case it required 4 years. When I was ready for the AU porting, after modifying assembler code (syntax is different and I found some opcode is not supported and what's missing it's not even documented), code for loading png from memory, mutex&semaphores&thread primitives, different abstraction layers for strings, blah blah blah....
and blah blah blah
I discovered that parameters between editor and process should be passed by value
aaaaaaaaaarggggggggghhh
in my case there were more than 130 members, and they were passing pointers to other classes.... a nightmare.

Guys, it's simple AFTER you have done it. Don't tell me it's easy, because it's not. It's damn complex because there are so many strange things: sometimes documentation is missing, maybe you don't realize that but this developer forum is THE ONLY place where I find solutions. Just look at this forum. Every day there is a new question, and many developers are damn expert.

In my case I started from borland c and it was a mistake.
Than I adapted code to gcc/xcode.
Than I discovered that borland was not going to release a 64 bit compiler and I moved to microsoft c.
Add: tons of hosts and different policies (this host loads the plug in this way, this host doesn't like high values for latency compensation, this host is doing strange things when this, that)


Answer to the original question is stupid.
It's
not
that
simple

[eigentone]

But that end of the code doesn't account for the majority of the development time. Devs (should) use an abstraction process... basically to hide the plugin format specifics from their program as much as logically possible.

Abstraction layers are famous for "leaking". What you say should be simple and straightforward. Once the real world gets involved however these layers can actually cause more problems than what they were originally designed to separate.

Then the abstraction should be declared a failure (or obsolete if functional for a time), and rewritten (Which does not mean: It does not happen). There is a lot of surprisingly poor code dealing with plugin sdk interfacing. Fortunately, api validators and test apps are used more often these days.

It does account for 'too much time', especially for indie devs, because they have wheels to reinvent - a lot of development overhead to initially meet and maintain that compatibility. In a well designed library/build system, the abstraction/compilation/build serves as the the 'AU maker' machine.

It's be nice if you could always do this. Unfortunately, real world code almost always has 1 or more crufty sections...

Right, my reply supported that (and resource demands), when I said 'a lot of development overhead to initially meet and maintain that compatibility'.

If a dev (indie/commercial/whatever) really knows VC++, understands the VST API and can get something working quickly that might be the path he/she takes. Making AUs means the dev has to have at least 1 mac, and the time to learn how to make AUs inside a totally different development app (Xcode). There's a hell of a lot of work to make one simple VST/AU pairing.

And (for devs new to this or adding formats/platforms) it's best (IMO) to determine what hosts/platforms you will support from the outset (as much as is rational) and cross compile and test regularly. This way the abstractions serve their duty and the ripple effects are minimized when the new format/platform is publicly adopted. Though it can be hard to fit that time in up front, it is a worthwhile investment (again, my opinion). Otherwise, the platform/plugin format dependent code has a way of exploding within the code base, and/or huge pieces of the code base needs to be rewritten - especially within loose or poorly written programs. Another problem: Too many people end up adding (features,complexity) in the process of abstraction, which is (IMO) counterproductive.

I haven't tried it, though it is most likely possible to compile simple AUs on Windows, since everything (unique to the platform) boils down to a C interface which uses opaque types (iirc).

J

[hibidy]

There. Now why is this thread 11 pages?

Because it's filled with mac bashing trolls.
I think yours was the most useful post in the last 8 pages though, so things are looking up.

As far as I'm concerned, people who hate mac's, hate freedom of choice.

I only hated my mac because of the LACK of freedom I had. Lack of freedom to change my woefully underpowered CPU, lack of being able to use logic pro (which used to be 1000 bucks for all the new kiddies) lack of freedom from crashes, lack of OS stability with the constant and un-tested updates that they kept BUGGING me to update to (that didn't work anyways), lack of freedom to have anything that resembled support.

You mean that kinda freedom?

[eigentone]

In essence, you'd have to determine what the plugins you develop need, and go by the minimal feature set needed

in my case it required 4 years. When I was ready for the AU porting, after modifying assembler code (syntax is different and I found some opcode is not supported and what's missing it's not even documented), code for loading png from memory, mutex&semaphores&thread primitives, different abstraction layers for strings, blah blah blah....
and blah blah blah
I discovered that parameters between editor and process should be passed by value
aaaaaaaaaarggggggggghhh
in my case there were more than 130 members, and they were passing pointers to other classes.... a nightmare.

Guys, it's simple AFTER you have done it. Don't tell me it's easy, because it's not. It's damn complex because there are so many strange things: sometimes documentation is missing, maybe you don't realize that but this developer forum is THE ONLY place where I find solutions. Just look at this forum. Every day there is a new question, and many developers are damn expert.

In my case I started from borland c and it was a mistake.
Than I adapted code to gcc/xcode.
Than I discovered that borland was not going to release a 64 bit compiler and I moved to microsoft c.
Add: tons of hosts and different policies (this host loads the plug in this way, this host doesn't like high values for latency compensation, this host is doing strange things when this, that)


Answer to the original question is stupid.
It's
not
that
simple

Ouch! 4 years is a long time, for sure.

The pain can be minimized with good designs, abstractions, libraries (in house ones too) and preventive measures (like you say, it's simple AFTER you have done it). In the broader scope of cross platform development, the initial investment is huge for a small company or indy dev, even with good planning. I would assume everyone would have (bad) surprises along the way, and it is time consuming. For this reason, I have programs that will likely never make it to Windows, though i try to plan ahead, if I change my mind.

J

[Zaphod (giancarlo)]

pain would be minimized with good design "later". You should know which is the trouble before planning a solution. And the trouble is "moving". When I started my little project CPU were single core, a 64 bit OS was more or less a dream and snow was something related with winter.