What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

Steinberg: No more VST2 Development

DSP, Plug-in and Host development discussion.

Moderator: Moderators (Main)

KVRAF
 
3920 posts since 11 Feb, 2006, from Helsinki, Finland
 

Postby mystran; Wed Dec 11, 2013 4:17 pm

JCJR wrote:I would like a plugin SDK that is stupid-simple for both hosts and plugin devs to write against.


It would be totally trivial to build such a thing, if it was only a technical issue. It takes about 20 methods or so that you really can't live without, and if you split those by functionality and make the whole thing extensible, you can add the missing functionality later without breaking anything (by allowing fallback down to the minimal core).

But the problem is that getting anyone to agree on how to do even that, and getting anyone to actually implement it.. just not going to happen. Any one of us could draft that thing into a working state (with a VST wrapper too) in about a day.. but that would be a wasted day.
Image <- plugins | forum
KVRian
 
599 posts since 9 Jan, 2006

Postby matt42; Wed Dec 11, 2013 5:20 pm

AdmiralQuality wrote:If it's true that the VST 2.4 SDK is included in its entirety in the VST 3.6 SDK then that's fine.

Is this actually the case though?

(I don't care about the sample projects.)
Yes, still true as of VST 3.6 SDK.
KVRAF
 
6195 posts since 10 Oct, 2005, from Toronto, Canada
 

Postby AdmiralQuality; Wed Dec 11, 2013 7:42 pm

matt42 wrote:
AdmiralQuality wrote:If it's true that the VST 2.4 SDK is included in its entirety in the VST 3.6 SDK then that's fine.

Is this actually the case though?

(I don't care about the sample projects.)
Yes, still true as of VST 3.6 SDK.


Well good then. It can still be obtained legally. Next battle... when they delete it.
KVRAF
 
1927 posts since 16 Aug, 2004, from Vienna, Austria
 

Postby arakula; Thu Dec 12, 2013 12:08 am

AdmiralQuality wrote:Dude, you just shared warez on KVR.
Hmm, may be so. I removed the direct links now, but still - it's not gone. If you want it, it's there.
"Until you spread your wings, you'll have no idea how far you can walk." Image
User avatar
KVRist
 
466 posts since 19 Dec, 2010

Postby Richard_Synapse; Thu Dec 12, 2013 1:18 am

mystran wrote:It would be totally trivial to build such a thing, if it was only a technical issue. It takes about 20 methods or so that you really can't live without, and if you split those by functionality and make the whole thing extensible, you can add the missing functionality later without breaking anything (by allowing fallback down to the minimal core).


In our own internal host/plugin code in Orion, we essentially just have process() and a few "offline" functions. This could be further reduced to a total of 2-3 methods if we wanted to. If you introduce 20+ methods, then you need to specify exactly when or in what order they should be called, and even if you do that some people will still screw up on the implementation somewhere.

Richard
Synapse Audio Software - www.synapse-audio.com
KVRAF
 
2907 posts since 28 May, 2001, from New York, NY
 

Postby Big Tick; Thu Dec 12, 2013 4:07 am

ras.s wrote:I call on ye mighty developers to make the Host of Hosts, call it the Blue Kaviar, the fish-egg of the Internet's biggest catfish.


For such a host to succeed it would need to have a better feature set than Cubase or Live, and these hosts took hundreds of man-years to develop. Also, do you really think a gathering of independent developers can afford to license things like ZPlane timestretching ?
KVRian
 
686 posts since 2 Dec, 2008, from Finland
 

Postby ras.s; Thu Dec 12, 2013 8:29 am

Most likely not. But consider the possibility of KVR joining in as the close-knit community this place is. In the past three years, Luftrum's charity has collected some 44 000 dollars for charity. One reason those fundraisings have been so successful is that people receive something in return; software and soundsets, whatever is donated to the cause. There's been different charities too, from tsunami relief to someone's cat needing veterinary care, to de la Mancha wishing people donate to cancer research. KVR is a community with very strongly attached members who feel very strongly about supporting developers and noble causes.

I understand that developers who have only a Paypal-donate button on their website don't really make a living out of that. But small streams make big rivers, as cliché as that sounds. End-users are fed up with paying companies for yearly updates that seem to do nothing else than provide products with less features than before alongside worse customer service and breaking support for their current operating systems. I am quite sure - I of course can't be certain - that people would be willing to make donations for or become subscribers to a software that would be born from this community. (Also consider such projects that rely on on-going community fundraising, for example Ardour or Haiku -- they don't make fortunes, but enough to employ someone to work full time on the code.)

The way I would like to see a host is that after the basic feature set of recording and playing back audio and MIDI, loading effects, instruments and utilities and mixing it together, every other feature should be a purchase-per-need. I personally don't need video editing but some do, some don't need modularity but I do. Just as bought plugins add value to hosts, why not make needed features be the same? Personally, I'd probably waste a lot of money in having a choice of different mixers in a single host, if that would be possible, but I very rarely need to time-stretch my tracks. I wouldn't mind my host itself having a market place for extra features, handling purchases, licensing, updates and version control -- and perhaps ZPlane themself would be interested in having that additional source of revenue from providing such a host with a feature people are willing to pay for. If not, perhaps some other established company might be interested in licensing their code for the economic return.

I would imagine that the competitional benefit of starting from scratch compared to companies whose products are over ten years old is that a new system can be designed from the start to have the needed features and futureproof extensibility, instead of the route that established developers have to do, which is basically bolting new features on top of a aging code base. In some sequencers, after several years that has lead to the developers themselves needing to start over to get a clean code base again. Putting together the vast experience you guys have from engineering audio related software would give the software a superior ground.

I understand that I can't truly imagine the amount of work this all would be, but I'd still like to express that I would much rather pay you guys, than companies like Steinberg, Ableton, Apple, Avid, Propellerheads or Cakewalk (or Presonus, whose software I've upgraded yearly for some time now). A lot of money and time would be needed to make it all come true, but computing history has plenty of examples of community projects being highly successful and I have no doubts about this community, both the developers and the end-users, being able to pull it off.

Excuse me for the lengthy post.
KVRian
 
556 posts since 7 Jan, 2009, from Gloucestershire
 

Postby DaveHoskins; Thu Dec 12, 2013 12:20 pm

Big Tick wrote:
ras.s wrote:I call on ye mighty developers to make the Host of Hosts, call it the Blue Kaviar, the fish-egg of the Internet's biggest catfish.


For such a host to succeed it would need to have a better feature set than Cubase or Live, and these hosts took hundreds of man-years to develop. Also, do you really think a gathering of independent developers can afford to license things like ZPlane timestretching ?


You could license my pitch/timeshift software, Copula.
It's:-
* Faster
* Better quality, and I can quote a developer who ditched Zplane for mine!
* Has a bigger range before sounding like stringy metal.
* Keeps in sync when going through complex changes and back to the original speed and pitch.
* Simple formant changes, without needing to know the type of audio.
* Cheaper.
Here: http://www.quikquak.com/Prod_Copula.html

Sorry! I couldn't help mentioning it.
:)
Bad Dave.
KVRist
 
252 posts since 30 Jan, 2005, from New Zealand
 

Postby Jeff McClintock; Thu Dec 12, 2013 7:04 pm

rockstar_not wrote:Is it time for an uprising for plugin developers to develop the host that will support the developer driven plugin standard? Or perhaps, write THE bridge between the plugin standard you want, and the one foisted on you by Steenburg?


It's been tried. It was called GMPI.
Developers simply can't agree on a standard. Some refuse to budge from the familiarity of VST2.x, whereas experienced developers recognise VST2's design as dated and of poor quality.
Some see the advantage of MIDI, others the limitations (7-bit resolution in a 64-bit plugin ???? ). Better to use note-expression?
Some recognise the simplicity of clean separation of GUI and Audio processing via the model-view-control design pattern, others insist that's 'over complicated'.

You can't please everyone. It's impossible.
KVRian
 
599 posts since 9 Jan, 2006

Postby matt42; Thu Dec 12, 2013 7:57 pm

Jeff McClintock wrote:Some refuse to budge from the familiarity of VST2.x, whereas experienced developers recognise VST2's design as dated and of poor quality.
Perhaps I'm reading a little too much into your words, but do you really think you speak for all experienced developers.
User avatar
KVRAF
 
8806 posts since 7 Dec, 2004
 

Postby aciddose; Thu Dec 12, 2013 8:04 pm

The over-all design isn't that bad. It uses a c-style interface with a fixed size struct, "magic" identifier and wrapper functions.

This is the "well I guess it's okay" part.

The bad part is the rest of it which is for the most part atrocious.

For example, the 32-bit "randomized" GUID rather than building identifiers from a hash of other data, or merely a collection of hashes! For example why not take crc32(name) + crc32(vendor) + version and attempt to load plugins with the data in that order of importance? For example you couldn't find a match of version, but name+vendor. So the host can notify the user and either automatically or optionally attempt to load that plugin.

Instead we're trapped with a single version of a plugin with a single identifier. How am I supposed to use multiple versions of the same plugin in a project?

From that point the other bad decisions are on the host-side such as "I know! We'll store the path to the plugin binary! I'm so smart!"

Really though this is just the very tip of the iceberg and anyone familiar with VST2x will give you an awful lot more than that.

I do feel I speak for other developers on this issue. You may be no true scotsman I suppose.
KVRian
 
599 posts since 9 Jan, 2006

Postby matt42; Thu Dec 12, 2013 8:31 pm

To move from a 32 bit ID to a scheme such as you suggest would have been a trivial fix for VST 2.5.

Has VST 3 improved on this situation? I haven't looked at it for a while so could easily be wrong. Doesn't it just use a higher resolution GUID with the same issues regarding multiple plugin versions, etc?

Of course VST 2.x is imperfect, but I just see VST 3 presenting a whole new set of annoyances.

Threading was mentioned. In VST3 you're forced to use a certain threading model. You now have no guarantee of when data will be passed between GUI and processor. This kind of thing causes people real problems.

Really though this is just the very tip of the iceberg and anyone familiar with VST3.x will give you an awful lot more than that. :hihi:

Seriously though I would be more than happy to jump ship from VST2. But where to?

EDIT:

Sorry, Jeff. I'm probably being a little myopic and viewing things as VST2 vs 3 and perhaps missed your point. I suppose you mean that any well thought out alternative SDK would have to compete against VST2.x entrenchment. Which is probably true.
KVRian
 
599 posts since 9 Jan, 2006

Postby matt42; Thu Dec 12, 2013 8:46 pm

Jeff McClintock wrote:It's been tried. It was called GMPI.
What actually happened to GMPI? All I can glean from Wikipedia is that it never progressed beyond a requirements draft.
KVRAF
 
6195 posts since 10 Oct, 2005, from Toronto, Canada
 

Postby AdmiralQuality; Thu Dec 12, 2013 9:03 pm

Jeff McClintock wrote:Better to use note-expression?


You've sold me. Now kindly direct us to where we can buy keyboard and guitar controllers that send note-expression to replace all our MIDI gear with and we can get back to making music.
User avatar
KVRAF
 
8806 posts since 7 Dec, 2004
 

Postby aciddose; Thu Dec 12, 2013 9:54 pm

matt42 wrote:Really though this is just the very tip of the iceberg and anyone familiar with VST3.x will give you an awful lot more than that. :hihi:

Seriously though I would be more than happy to jump ship from VST2. But where to?


I didn't get the impression from either post that anyone was vouching for VST3. If Jeff meant to say that I wouldn't agree with him. I do agree however that a majority of experienced developers know the limitations and bad design of VST2x.

I think much like firefox was able to topple internet explorer from its position a modified open version of VST2x implemented by most smaller hosts would also topple VST3x and other formats. The potential for distinguishing such a format through improvements to its features compared to either VST2x or VST3x would embarrass the authors of hosts lacking support for it.

The primary requirement however would be VST2x compatibility. This would both eliminate the entrenchment of VST2x as well as leverage the existing plugin market. A conversion from VST2x to "OVST" requiring only a few trivial modifications and maintaining backward VST2x compatibility would solve all our problems at once.

The only remaining question is the legal one - is it possible for some person or group of persons (or companies, or so on) to adopt such a standard without running into a tangle? Can we avoid the "community specifies its own" mess of blink tags?

(Noting of course that the VST2x 'design by individual' or 'design by committee' are both capable of producing lovely results like: VST2x, a mess of several different blink tag implementations with significant redundancy.)
PreviousNext

Moderator: Moderators (Main)

Return to DSP and Plug-in Development