Selling VST2 after October 2018: Steinberg agreement

[stratum]

[accidental double post again - I couldn't yet learn the new forum buttons]

[S0lo]

Come together as a market to survive. Cross company lines and help each other develop better products.

It has been done before with the MIDI spec. 34 years back. https://www.theregister.co.uk/2013/08/2 ... to_el_reg/



Problem is, we are 15 years late with plugin API. As has been said in this thread before, It's really upto the few main DAW makers. If they come to an agreement on something, plugin vendors will probably follow, and may be something will evolve.

Frankly I don't think it's going to happen. What I really think is possible is that DAW makers could communicate and convince Steinberg regarding making a Wrapper from (VST2 to VST3). This way VST2 code can produce VST3 format plugins. Hence all these small devs who missed the train don't really need a VST2 agreement because they are selling VST3 plugins. They can still continue developing in VST2 until thier software retires sometime in the far future. This allows both DAW makers and Steinberg to drop VST2 support some time in the far future as they want yet old VST2 code will still work because it's been wrapped as VST3. Every one is a winner.

In fact, this also allows VST2 makers who have a VST2 agreement to easily port to VST3 without rewriting their code again.

[Aleksey Vaneev]

If you have a "meta-wrapper" written for your plugins to support different APIs, VST3 "port" is only 25 kB of code. While VST3 is certainly a mess in comparison to VST2, thankfully VST3 has SingleComponentEffect which makes VST3 implementation simpler. But still VST3 is a degradation through overimplementation. Some things like alphabet should remain unchanged for ages.

[Vertion]

I need to put this in the oven in between my ears to cook for a bit and come back with a more solidified plan. But from the prenotion, we need a common community DAW to take the lead of the market, and thus control of standards going forwards, the design would be a common point for copy protection, and installer, thus removing the need for a billion installers and copy protection schemas. All devs would keep their plugins on one server to be downloaded and maintained, and have advertising on a shared single server, thus avoiding website maintence fees, payment gateway setups, etc. Anyone then can join and quickly setup their own subdirectory, or domain pointer. This would free costs up and lower the entry barrier to the market. An adopted standard or new standard agreed upon by the top devs would be the DAW interface going forwards, with no licensing drawbacks. Rapid composition would be possible, as realtime anonymous mutual composition. Devs can also sell code to other devs as well. The DAW will be free, but a beta tester can subscribe for a monthly fee, and access all products, and these proceeds are divided up by contribution points given to devs who work on the DAW itself, creating a regular paycheck fir those who update and maintain the DAW. The DAW is free, but all the nonbasic functions are only accessible through the online store and install manager, copy protected, or by those with beta tester paid subscriptions. Key emphasis on full song generation with minimal learning curve and effort, as well as live sharing via simple automation loops that are constantly syncing with the server as a means for shared anonymous composition. Only music and emoticonics cab be expressed to simplify on the fly live collaboration.

This is just off the top of my mind, I haven't thought about yhe details yet. Any feedback would be great, I can get started if I see any interest or expansion on the idea.

[tristan-]

I need to put this in the oven in between my ears to cook for a bit and come back with a more solidified plan.
But from the prenotion, we need a common community DAW to take the lead of the market, and thus control of standards going forwards, the design would be a common point for copy protection, and installer, thus removing the need for a billion installers and copy protection schemas.

All devs would keep their plugins on one server to be downloaded and maintained, and have advertising on a shared single server, thus avoiding website maintence fees, payment gateway setups, etc.
Anyone then can join and quickly setup their own subdirectory, or domain pointer.
This would free costs up and lower the entry barrier to the market.
An adopted standard or new standard agreed upon by the top devs would be the DAW interface going forwards, with no licensing drawbacks.
Rapid composition would be possible, as realtime anonymous mutual composition.
Devs can also sell code to other devs as well.

The DAW will be free, but a beta tester can subscribe for a monthly fee, and access all products, and these proceeds are divided up by contribution points given to devs who work on the DAW itself, creating a regular paycheck fir those who update and maintain the DAW.

The DAW is free, but all the nonbasic functions are only accessible through the online store and install manager, copy protected, or by those with beta tester paid subscriptions.

Key emphasis on full song generation with minimal learning curve and effort, as well as live sharing via simple automation loops that are constantly syncing with the server as a means for shared anonymous composition.
Only music and emoticonics cab be expressed to simplify on the fly live collaboration.

This is just off the top of my mind, I haven't thought about yhe details yet. Any feedback would be great, I can get started if I see any interest or expansion on the idea.

Splitting your comment in coherent phrases.

[Skupje]

Would be cool to have an initative that does it all, creates a new compiler programming language, plugin standard, Midi over ethernet/uart. And all in the open source in the worst low level way.

[Vertion]

In short, it's like

Reason - in that it has it's own plugin standard (or adopted)
Amazon - online store for every plugin product
Any Webhost - Each dev has their own subdirectory to advertise products
KvR - Common support base for customers, individualized per developer
FLStudio - Infinite DAW updates, but the DAW itself is free
Cherry Audio Voltage - Inline online store, where anyone can add their own products to sell and download with embedded installer and copyprot
Korg Kaoscillator , but Online - simple gestures into loops that are interpreted for anything from pitch to cutoff, etc, and these loops are synced online for mutual collab
Any given MMO game - emoticon based feedback
Pace - copy protection, but invisible, and NOT pace, additionally online collab requires a single instance username
Cellphone/Mobile Apps - simplified Mobile version for more live composition, and to take control of mobile sector
Rapid Composer/Chord Sketcher/etc - full song generation via chord progression generators etc. I IV V Triangles, etc.
ASMJIT - C++ on the fly, encrypted scripts possible
2DBlend - Vector GUIs
PortAudio/ASIO - Audioi IO
Joining a Gym - monthly fee for beta testers can use all equipment, or you can fully buy one workout machine at a time and bring it home forever

[Skupje]

Im looking to build a webserver. Maybe it can host a forum for something like this. But it's very hard to begin with problems like these. In a way decentralized is a good thing. Hard to match with some stuff, I would love a HTML front end for VST development. Some might not..It wouldnt be very practical to begin with. Most may want to stick with C++, how would you even begin to describe these problems?

[S0lo]

If you have a "meta-wrapper" written for your plugins to support different APIs, VST3 "port" is only 25 kB of code. While VST3 is certainly a mess in comparison to VST2, thankfully VST3 has SingleComponentEffect which makes VST3 implementation simpler. But still VST3 is a degradation through overimplementation. Some things like alphabet should remain unchanged for ages.

Interesting.

VST3 indeed is an explosion compared to VST2. First impression is like "What the hhhhell...". I didn't go into the details yet. But I like the way you put it in "alphabet ...."

Although one attraction to me was the use of Direct2D in vstgui 4 instead of the "no longer hardware accelerated GDI+". Although it seams that vstgui 4 can be used outside VST 3 as far as I can understand.

[No_Use]

FWIW, there has been an effort way back for a developer driven audio host/plugin API called GMPI which then went over into LV2.

[ghettosynth]

FWIW, there has been an effort way back for a developer driven audio host/plugin API called GMPI which then went over into LV2.

Right!?! The discussion in this thread has turned to pure fantasy. I mentioned LADSPA/LV2 above. What I'd like to hear from other more experienced audio developers is, aside from DAW support, which is obviously required, what limitations does LV2 have as compared to VST2/VST3?

Probably Reaper, outside of Mixbus of course, is the best best for seeing LV2 support in a non-linux DAW. Suppose that happened, what would be good and/or bad about it? I have only minimal experience with LADSPA having only created one native linux plugin for an embedded project some time back.

I have no immediate concerns personally, I have my VST2 license, but I would like to see, long term, the industry migrate to an open standard for audio plugins. Is LV2 the best option on the table for that today?

[camsr]

It should be obvious, given the required support to implement DRM, that an open specification will undoubtedly take the reins first. And it's not absolutely decided what DRM needs to protect. The last thing a successful new spec will have is "square wheels" via a poorly managed DRM scheme.

[vortico]

Someone brought up an interesting concept of reselling VST2 plugins for other developers who missed the getting license. I don't want to offer this myself, but I think it would be nice for a company to volunteer for the sake of other developers.

[aciddose]

Solo, you totally missed the point on 100% of what I said.

Try to shorten what you say... I know I have trouble with this myself so I respect that but I've also been trying my best to improve.

VST2 has major flaws. Some of them include lack of constness, the most obvious example is process(const T ** const inputs, const T **outputs, ...)

I'm referring to the pointer addresses (for outputs) and both the values and pointer addresses (for input).

Yes you're right, it should be T ** const outputs (did I get it backward? I haven't bothered to check.)

but using strncpy(buffer, ...) is another clear idiot move.

String lengths are never passed in any portion of the VST interface. They are assumed based upon "constant" values in an enumeration.

This is horrible, inflexible and destined to be obsolete the moment it is released. It's simply bad design.

[aciddose]

Nobody cares about your opinion or feels when we're discussing the facts.

"... but I don't wanna use that feature!"

Then don't.

Some features open "can of worms", bad design decisions I would say.

You just described the C language too.

From marketing point of view, creating a single DLL with 30 plugins is tempting, but will that make users happy to scroll through plugins they do not need or even know and have no ability to remove (plugin standards do not have a feature to remove individual plugins exposed by the DLL bundles)?

From a marketing point of view: that's up to the individuals doing the marketing.

Yes I agree, intentionally lumping unrelated plug-ins into one binary is bad.

However at the same time there are many sub-variations that are possible. A synthesizer might ship with its effects both "all effects" and individually in addition to the synthesizer. It might also include bare oscillators, bare filters, filter + envelopes and other sub-components.

All those components already exist inside the synthesizer so there is very little overhead (assuming the interface is light weight in defining sub-modules) associated with also exporting those components.

It's a question of flexibility.

Not all "plug-ins" are audio plugins. As I said MIDI is also used for controlling stage lighting and model train sets!

This is made possible by a flexible protocol. Nobody forces you to include the ability for your synthesizer to schedule departures for trains from the stations or to control stage lighting with the LFOs: but with a flexible interface nothing will stop you either.

For example my effects plug-ins "Xhip Effects" all use identical components and wrappers. By compiling them into a single binary I was able to shrink the distribution from 2.5 mb to 262 kb. That's a ratio of 9.5 to 1.

As things are with VST it is not possible to export all the plug-in sub-types from that single binary. So on a user's system that same identical binary is duplicated 15 times at the moment.

I also plan to more than double the number of effects in the future!