Don't know if anyone noticed... VST3

[liqih]

On the flip side.. I think it's counter productive to promote any open API as an anti-VST specifically, it should be pitched as an anti(any less-open, less well designed standard).

ok thanks Angus, I see that maybe I was wrong, but I also saw that this thread started as an anti-VST3 no?, or rather I would say
anti-forced-updates-imposed-to-small-devs-by-the-big-industry,
so I agree: it's NOT anti-VST (after all I love VST, <grin>)

So I don't have any plans to work on it right now, and I don't see many that do.

as I say maybe I'm wrong, from some messages here and there it seemed to me that someone wanted or wished to put the hands forward

[Aleksey Vaneev]

VST3 is just a milestone that marks a new 'open plug-in API' era. So, VST3 release is important by itself, just if only to prove again we all need an open plug-in API.

[GlennO]

In fairness to the speakers from AudioEase and Sonnox, they were obviously misled into thinking their audience was press, so they made a marketing presentation, devoid (and yes, comically so) of technical accuracy regarding VST3. The comment from the AudioEase speaker about how this was going to reduce the number of plugin formats they need to support was particularly hilarious.

I have no idea why Steinberg invited a bunch of developers to the press conference when there were no Steinberg engineers at NAMM, but it was a surreal 30 minutes.

- Glenn

Well, as I aid before, me and everybody I spoke to found it funny how AudioEase and Sonnox were used by Steinberg to hail VST3. So much so that they didn't look good and havn't had their facts straight. One could even hear a bit of laughter from the audience every now and then.

Seriously, it was embarrassing. They were trying to praise their own products in front of their competition. I guess they got a pretty weird briefing from Steinberg.

.
.
.

Urs

[heeb]

Being that Opus is a Musical Composition, I think there is a nifty little link there.

And when you chain two or more Opus plug-ins, you'd have to call the chain 'Opera', since that's the cromulent plural of Opus

[lowkey]

This might be worth looking into...

http://www.grame.fr/~letz/jackdmp.html

It covers Windows, OSX and Linux. Heres how its implemented in Linux...

http://jackit.sourceforge.net/docs/design/

It could side step having DAWS support it a new plugin format because its between the audio application and the soundcard driver.

I hope I'm not completely off here, but since jack isn't really a plugin standard, but more of a protocol one (at least afaik?), the main drawback, imo, is that your project won't be self-contained, so to speak.

Sorry if I'm wrong about this.

Your right its a bit like rewire without the midi. Would using VST/AU as a frontend work? If so then it would easier to adapt to changes caused by Steinberg/Apple/Microsoft while "Open Plug-in" is being developed..

[stefancrs]

Your right its a bit like rewire without the midi. Would using VST/AU as a frontend work? If so then it would easier to adapt to changes caused by Steinberg/Apple/Microsoft while "Open Plug-in" is being developed..

IMHO something along the lines of rewire (or, obviously, jack) is fairly useless.

What do you mean with the frontend suggestion? The main issue (and in some ways, main strength, I guess) with rewire, jack etc is that there's no way for the one connecting at one end of the "cable" to tell anyone what to do with the other end of the "cable". These protocols got nothing to do with plugins really.

[jwatte]

If you think about graphics card computing, they do not require interleaved data - it can even hurt performance AFAIK.

The analogy is somewhat flawed, because the different channels are all part of the sample vertex. And interleaved is still at least as fast as non-interleaved; sometimes faster (because of pre-transform vertex caching). I do graphics for a living

Regarding doubles, everybody may be doing it, but that doesn't make it right. I can see how some higher-order filters benefit from the additional stability, but for regular data transport, the quantization and noise levels of 32-bit float are way beyond our perceptible limits, as well as beyond actual hardware capabilities. Why pay double for RAM and hard drives?

Anyway, I spent three hours last night knocking out a proposal for a plug-in interface. Have a look and see if it's anything at all like what you'd want to see: VST Plugin Replacement API. Note: it's a quick suggestion, not a finished proposal.
Some design points:
- C callable API
- support for sample-accurate automation
- support for MIDI control messages and parameter mapping
- support for input/output negotiation
- support for window size negotiation
- well-defined threading model
- support for sample-accurate time codes
- should be possible to generate VST/VPR wrappers (both ways)

[Angus_FX]

jwatte - you need to fix the line breaks on your server

Also - better to join up to the mailing list for the design effort and post in the forum once it's set up and everyone that should have been is invited.

[deadbeef]

OK I got through 15 pages but gave up after that..

We've looked at VST3, and are not planning on supporting it in REAPER (at least unless a ton of third party plug-ins support and require VST3).

We have our VST2.4 extensions listed here: http://reaper.fm/sdk/vst/

And we also are excited about helping define a new, open plug-in API. Much of what Angus has written makes a lot of sense to us.

The biggest thing, though, I get excited about, is having a plug-in API that is compatible with open source licenses. The fact that VST effectively prevents LGPL or even BSD licensed plug-ins is completely ridiculous...

Justin Frankel
Cockos Incorporated / REAPER
www.reaper.fm

[jwatte]

jwatte - you need to fix the line breaks on your server

Also - better to join up to the mailing list for the design effort and post in the forum once it's set up and everyone that should have been is invited.

Hmm. Source looks great in Firefox, but not IE. Crappy IE CSS support

I must have missed the mailing list link.

[stefancrs]

FYI, any developers:- Ben has kindly set us up an announce-list for organising efforts to develop an open plug-in API. Mail me (angus _at_ fxpansion _dot_ com) if you would like to be involved.

[Rock Hardbuns]

The biggest thing, though, I get excited about, is having a plug-in API that is compatible with open source licenses. The fact that VST effectively prevents LGPL or even BSD licensed plug-ins is completely ridiculous...

Indeed. And the same is partly true about the specs that have come out of the FOSS community. GPL and even LGPL are not attractive to most commercial developers. (LGPL should work in theory, but it instills a fear of unforeseeable consequences. No one wants to step into a FOSS licensing quagmire. )

If a new standard appeared that worked perfectly for both scenarios, that would be a nice selling point in it self.

The "brand" can be protected through validators and general spec compliance as opposed to license restrictions on the SDK. (I.e, to call your plug a foo-plug it must fit this spec. Arrive at it however you want.)

[WilliamK]

Question, is it too hard to open a VST3 inside a VST 2.4? For instance, we got our Wusik VM - VST Manager - that is turning out to be great. Maybe we could also turn into a wrapper for VST3s to run in VST 2.4 Hosts.

Wk

[HanafiH]

If you're going to give it a name, give it a name not an acronym. Like bluetooth. Switchblade, something like that.

[stefancrs]

If you're going to give it a name, give it a name not an acronym. Like bluetooth. Switchblade, something like that.

Lazershark!