Plugin formats? This is the end...

[hibidy]

VST3 is a great example, Thanks AD!

Yeah!, you can always count on AD to crush Steinberg.

what else can you expect from the Yamaha corporation? Feeding the poor??

No, giving quality jobs to more than 50.000 people during 125 years. And I mean real, quality, for-life jobs, not the nefarious crap that you can find in the USA.

Yeah, if we are going to go there then I'll back that up. Steiny and their team are the issue, yamaha is far from being on the evil-empire list.

[tony tony chopper]

just admit it, it's because it lacks MIDI crap that you hate VST3..

[hibidy]

The only thing I know about vst3 is it was announced, then crickets, than a couple of companies came on board with it, more crickets, and that's kinda where it stands. I'm not a programming god like our chopper friend, but I'm missing NOTHING that I can tell. All I care about is stability and compatibility.

I'd love for the world to be a place where everything was more uniform. But then everyone would bitch because there isn't enough variety. Go figure

[gckilla]

Just wanted to chime in to thank tony tony chopper and aciddose on an informative discussion on the complexity of coding. I learned a lot from it. It always gets me riled up when users complain about software issues (that aren't bugs) making it sound like coders are like magicians that wave their wands and can magically make things happen.

But on the flip side, I do find it comical when people bring their utopian business models out for display.


I'm not a Reason user myself, but I find myself defending them. To me, Rack Extensions are not a new plug-in per se. They are going to do what they descriptively called; Extend your palette of existing Reason instruments and effects. Given their design ethos, I see no other way it can be done - they want quality, stability, and conformity. Without that, Reason would just be like any other DAW. I see the Rack Extensions as a natural outflow from what they did by adding the SSL emulation.

I'm in agreement with those who complain about Cakewalk's Sonar X1 producer/xpanded trickery (and have successfully resisted buying their flagship product as a result), but the same logic applies. Something built in to the core of the product cannot be considered a new plugin in format.

[whyterabbyt]

To me, Rack Extensions are not a new plug-in per se.

Something built in to the core of the product cannot be considered a new plugin in format.

Neither Rack Extensions nor ProChannel modules are 'built into the core of the product'. They are plugins, by the accepted definition of software components designed to integrate with and extend applications.

http://en.wikipedia.org/wiki/Plug-in_%28computing%29

They are going to do what they descriptively called; Extend your palette of existing Reason instruments and effects.

That's what 99% of plugins we have for audio software does do.

[gckilla]

I'll admit you've got me what plug-ins do, but I'm in no way convinced to the first part of your argument. The level of integration that is involved is far and away different then what you would get from the established standards.

[whyterabbyt]

I'll admit you've got me what plug-ins do, but I'm in no way convinced to the first part of your argument. The level of integration that is involved is far and away different then what you would get from the established standards.

The level of integration of a plugin with the software it extends has no impact whatsoever on whether it is a plugin or not.

You dont have to be convinced. In terms of how software dynamically loaded libraries can extend an application, they all operate in fundamentally the same way. Its about the mechanism, not the level of functionality they offer.

[VitaminD]

I'll admit you've got me what plug-ins do, but I'm in no way convinced to the first part of your argument. The level of integration that is involved is far and away different then what you would get from the established standards.

I'm going to have to agree with whyterabbyt on this one. It IS a plugin.

Maybe think of it this way...

The expansion cards on Roland and Yamaha Workstations are plugins... they literally plug into the keyboard. Neither companies work in the others... but that doesn't matter. They are both extensions to the original hardware that 'plug in' to it and offer additional features.


Same way with Firefox.. it has plugins. So does Internet Exploder.. neither browser can share plugins.

[gckilla]

LOL, okay guys, it is technically a plugin. I'm in total agreement.

What Ableton, Cakewalk, and the Props did though is still different, so while still a plugin, the level of integration with the core product puts their plugins in a league of their own.

[gckilla]

I'll admit you've got me what plug-ins do, but I'm in no way convinced to the first part of your argument. The level of integration that is involved is far and away different then what you would get from the established standards.

The level of integration of a plugin with the software it extends has no impact whatsoever on whether it is a plugin or not.

You dont have to be convinced. In terms of how software dynamically loaded libraries can extend an application, they all operate in fundamentally the same way. Its about the mechanism, not the level of functionality they offer.

Agree with first point, agree with second point (because you included the word: fundamentally - which makes all the difference).

But if we are arguing definitions (of which I've previously conceded), we're missing the point of the top, imho.

[aciddose]

they're "plugins" or the more common name "modules".

what you're looking for is a module that follows a standard... i suppose you'd call that a standardized module.

vst2 does work really well except for it's limitations. those aren't really an issue with the architecture though.

what i'd really like would have been if they'd taken vst2, replaced the "aeffect" struct with a simple definition of a "dispatcher" function exactly as it was. everything else could be stripped out.

rather than sending "opcodes", function pointers could be requested using names.

ideally you'd have something like process_function = effect.request("process").

the issue with that is you'd have to define the parameters for all these functions somewhere anyway. at some point winamp's plugin struct starts to look attractive.

...but then you have to factor in room for future expansion.

allowing the host to fill it's own function pointer struct by calling plugin.request(...) means you never need to worry about having a fixed format for that structure. someone who wants to implement only a sub-set of the interface only needs to request a sub-set of the interface and never even needs to know about other portions!

with that as a foundation, the other portions of vst2 could be improved. for example the setparameter function could be handled instead by processevents. the whole functionality of vst3 (at least, that which is useful) could be implemented, plus more.

unfortunately they didn't do that.

give me a million and two years and i'll do it.

[machinesworking]

The problem will never go away until you get all major DAWs, both Microsoft and Apple to all come together and create a non proprietary open format that isn't owned by anyone....

IMO it seems VST3 isn't universally supported because people are having a hard time implementing it in their DAW as tightly as Steinberg has in Cubase etc. This is typically the problem and why the Emagic team apparently was not at all unhappy after being bought by Apple to ditch VST for AU... VST2 is solid support wise so developers are loath to port to an unsupported not very well documented on the host side format that magically works like a charm in Cubase.

So again, we're left with an "open" format owned by a particular DAW manufacturer with no incentive to help other DAW makers host VST3, and this is the best we can do, otherwise it's OS specific or host specific formats. We happen to play in a field that very blatantly points out one of the flaws of Capitalism, no real open standards.

[tony tony chopper]

ideally you'd have something like process_function = effect.request("process").

You're pretty much describing COM interfaces (except that interfaces are better since they're holding several functions), & VST3 is using that.
It's totally possible to extend it through interfaces. Exemple is the one that Studio One defined, defining a per-parameter popup menu, which we support since it was pretty similar to FL's:
http://www.presonussoftware.com/en_US/i ... =developer

(I only hate COM objects & interfaces because of the way Delphi handles them with shitty garbage collection that Pascal isn't used to, & handling them always leads to crashing because you never know what's garbage collected & what's not)

[VitaminD]

Except Microsoft and Apple don't care about us Muso types.. They are after the easy money (main stream electronic devices and software to support them)

Well.. That is not entirely true.. MS did create DirectX plugins for awhile.. but that flopped. They wanted the market to embrace it but it seemed as if they didn't want to get too much behind it themselves.


VST is probably where it is going to be for quite some time... I just wish they'd clean it up and make it more newbie friendly Maybe have a Developers side to their website, release books and tutorials, have meetups and such.. really invest in the technology and teaching it to the next wave of DSP devs.

In the games world there are all kinds of methods for learning game development.. books.. SDKs.. even entire schools wrapped around it. Of course its a multi-Billion dollar market. I think we should have something like it on a smaller scale

[aciddose]

ideally you'd have something like process_function = effect.request("process").

You're pretty much describing COM interfaces

sort of. vst3 does do some of that, it just has way too much bulk and mandatory implementation.

i also don't agree with a lot of the functions they've implemented. they took the easy way out in a huge number of places. it also seems like it was built "side-way" rather than starting from a foundation with core functionality and extending upward from there while making adjustments to the foundation to support those extensions.

i suppose you could just blame "bad programmers" but i think it's got some fundamental architectural flaws as well.

i like the simplicity of a list of c-prototypes for function pointers. why they didn't do it that way i have no idea...

one issue i've wondered about a lot is whether they took other things into account in the design - for example there is case law showing that the content of an interface (as exposed in a c-header with prototypes) is not protected under copyright. so by adding additional implementation other than just the basic interface, it would add copyright protection to the interface and therefore give "ownership" of the standard to the author.