Don't know if anyone noticed... VST3

[Chris Walton]

no, FST

I've got plenty of ideas and everything, just waiting for the place to be set up so I can post them .

The question is still if a C API should be used ... Windows and OSX are safe but what about the ABI under, say, linux?

[stefancrs]

That question is to be discussed later, no?

[Crandall1]

Eduardo, I agree with you. My point was that it isn't really important, inasmuch as it didn't happen, so there's no use talking about it now.

But if you read the VST dev list, you'd certainly know that there are a lot of developers who maybe shouldn't have a say in the platform, but are perhaps better off just dealing with what they've been given. I feel that we (Audio Damage) fall in to this category, as we're cross-platform, and would prefer things to be simple. Someone that only develops for Windows or OS X, or only for VST, is going to have much different concerns than us.

[mystran]

and the were going to release it one full year ago, so it makes you wonder, what the hell have steiny been doing?

I think I can guess, but I won't write it here, 'cos even on KVR such obscenity would probably get be permanently banned, and kinda I like the site.

[djex]

'm not sure how one determines whether a VST developer is "major" or "minor," but we weren't invited, and I think it's safe to say that we sell far more VST plugins than AudioEase does. No other developers I know were invited. I'm not sure what this invitation consisted of, but as far as I can ascertain, it wasn't on the VST dev list.

Just to set the record straight: Audio Ease wasn't invited either--you may want to reread both my and Fredo's replies. And I don't know of anybody else who was.

-- dj!

[lowkey]

LV2

What is LV2?

A plug-in spec from Linux land. It's been around a while now, but I think Linux native VSTs sort of knocked the wind out of them, as well as DSSI and what ever else was in the works.
I.e there is already more Linux native VSTi:s than there are synths in all the other specs combined. EnergyXT2 is probably to thank for this.

It might be worth looking into though, depending on the licenses.

Unless I'm mistaken, the LV2 spec was only very recently (like, this month) finalised, so I'm not sure if it's quite right to say VST's knocked the wind out of them just yet.

License-wise, the main header's under the LGPL, which could scare commercial devs off, though it should be possible (based on my limited understanding of software licensing) to keep the LGPL LV2 code in a separate dll to their own (proprietary-licensed) code to avoid any legal issues (this is what I do in Fragmental, which uses some LGPL code).

In looking to port my own plugins to it though, I have to say that all the RDF stuff (while I think I understand why they did it that way) is going to make for a lot of extra typing, in order to enumerate and provide descriptions of all the parameters, particularly in something as big as Fragmental. I'll probably just end up only porting the simpler (and less interesting) plugins.

- Niall.

So LV2 is like a communication protocol? Isn't that a good thing?

[mystran]

I don't think Linux is a good platform to look at for a plugin standard. There's no sensible way in X11 to do plugins with custom GUIs without having the GUI run in a separate process, unless you happen to have a specific toolkit written into the plugin spec, and if you search freshmeat.net or something, you'll notice that in the Linux land there isn't much of a consensus what would be the right toolkit to build stuff with.

In Windows such a thing is trivial: give a HWND and people can do whatever they want, and it'll work as long as nobody is stupid enough to write custom event-loops into plugins (like mm.. VSTGUI2.x did).

In Mac OSX I assume something similar is possible, though I've understood life is even easier 'cos from what I hear I'd assume it goes basicly like "whatever Apple claims is the way, will be the way, whether you like it or not."

[jwatte]

Btw, is it just me, or would VST be more convenient if you could get streams as interleaved channels. Stereo as a single buffer of L/R interleaved samples, etc?

[Aleksey Vaneev]

Btw, is it just me, or would VST be more convenient if you could get streams as interleaved channels. Stereo as a single buffer of L/R interleaved samples, etc?

No, it's not. As for me, I would have to de-interleave and re-interleave the stream. (I do that already if host supplies such data to an AudioUnit).

[jones-y]

Routing Possibilities
Plug-ins can be connected to the host environment in many different ways: Future VST3 Instruments can have audio inputs.

So when are we gonna see plugin samplers that can actually sample???

[stefancrs]

Btw, is it just me, or would VST be more convenient if you could get streams as interleaved channels. Stereo as a single buffer of L/R interleaved samples, etc?

If anything along those lines should be added, it should be optional. For both the host and the plugin. As in the plugin could ask the host for interleaved streams, and the host MAY provide them but doesn't have to.

For certain scenarios it makes perfect sense to have them interleaved from a performance point of view (vectorized code and whatnot).

[eduardo_b]

But if you read the VST dev list, you'd certainly know that there are a lot of developers who maybe shouldn't have a say in the platform, but are perhaps better off just dealing with what they've been given. I feel that we (Audio Damage) fall in to this category, as we're cross-platform, and would prefer things to be simple. Someone that only develops for Windows or OS X, or only for VST, is going to have much different concerns than us.

Interesting...hadn't thought of it this way. I certainly understand that the term developer covers a lot of varying circumstances. What I was thinking when I used the term process is that issues that may affect small devs more than larger ones should be heard and considered. Not saying everyone gets to set standards, but everyone should have an opportunity up front to discuss common concerns.

[mystran]

No, it's not. As for me, I would have to de-interleave and re-interleave the stream. (I do that already if host supplies such data to an AudioUnit).

Either way has merits. Per-channel processing is easier (ability to pass buffers as is to things like off-the-shelf FFTs isn't bad) for separate buffers, though processing channels in parallel with something like SSE would benefit from interleaved buffers. If I got to vote, it'd still vote for the VST2 way of separate buffers.

[djex]

So when are we gonna see plugin samplers that can actually sample???

Morgana already does this--so it is perfectly possible under VST 2.4. Admittedly we had to work around the VST specs as opposed to with them, but the good part is that we ended up with a solution that is way more flexible than what even VST3 will allow. For example, Morgana can not only sample from arbitrary tracks within the host but even from audio sources in other hosts running at the same time, as long as they support either VST (that's 2.4!) or AU. So you could, for example, sample the output of an Ableton Live track into Cubase. Or the other way around... the sky is the limit! (Well, the computer you're running Morgana on is--sampling across networks is one thing it cannot do.)

Even so, I personally will be more than happy with the VSTi audio inputs that VST3 provides.

-- dj!

[Aleksey Vaneev]

For certain scenarios it makes perfect sense to have them interleaved from a performance point of view (vectorized code and whatnot).

Still not useful. We can't vectorize 4 doubles on current processors - we can only vectorize 2 and that limits its applications to 2 channel audio only. If you think about graphics card computing, they do not require interleaved data - it can even hurt performance AFAIK.