Don't know if anyone noticed... VST3

[jwatte]

Fnord.

[Aleksey Vaneev]

Anyway, I spent three hours last night knocking out a proposal for a plug-in interface.

A good start (though, wchar_t is not desirable as its size may vary on different compilers even on the same platform AFAIK)... However, it's IMHO a bit too early in the morning, so to say, to define internals to such detail. But your coding style is clearly visible, that's important for project's code keeper selection. We should have coding styles to select from. I'll post my own 'sketch' obviously (though, I'm not as experienced in doxygen constructs ).

[jwatte]

wchar_t is not desirable as its size may vary on different compilers even on the same platform AFAIK

wchar_t is well-defined per platform, because the size is part of the standard libraries. It's 2 bytes on Windows, and 4 bytes on Linux. I wish that the general editor/library/code infrastructure had turned out to be UTF-8 for in-source internationalization, but that ended up not happening, so wchar_t is the default way to support non-Latin scripts. And I think non-Latin support is more important than any objection to data type size differences between platforms, because there are no persistent wchar_t strings written to disk/network in the API (unless you make it so yourself).

[Urs]

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

The problem is the other way round. VST3 is more special than VST2. You can wrap a VST3 into VST2 but not the other way round. Hence the proper future is:

- build plugins in VST3
- add wrapper/loader in VST2 that loads/wraps the VST3 version

(provided they find a proper solution for aribtrary Midi events)

Urs

[Aleksey Vaneev]

I wish that the general editor/library/code infrastructure had turned out to be UTF-8 for in-source internationalization.

If this question is ever touched in the open API, I would vote for UTF-8 for all strings (I can contribute a piece of code that reads UTF-8 string char-by-char, with pleasure , composing a string is easy, too).

[Aleksey Vaneev]

I think VST3 won't make its path into plug-in developers' plug-ins at the moment, at least not into version upgrades. The problem is, if a customer used version 1 of plug-in which was released under VST2.4, it's dangerous to replace that said plug-in with version 2 released under VST3: you will either have to give it a new DLL name, and ask customer to keep both versions, and to use them independently, or you'll have to break customer's projects that rely on VST2.4 plug-in (if you replace VST2.4 plug-in DLL with a newer one). Beware

[lowkey]

What do you mean with the frontend suggestion?

I ment like your synth shows its knobs and sliders to the user, its parameters with total recall to the VST host but has its engine separate.

[Aleksey Vaneev]

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

I've studied Nvidia's CUDA a bit, and from the architectural point of view, it's safer to keep channel sample blocks in different buffers (non-interleaved) so that gfx card's on-board processors do not access (read or at least write) the same data location together. I may be wrong, though - it depends on many factors.

[Tallisman]

Hi Liqih,

Speaking only for myself.. right now I see no compelling commercial reason to support VST3, no real user benefit, and a lot of work. So I don't have any plans to work on it right now, and I don't see many that do.

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). After all, Steinberg is hardly the only big-dog developer who's caused unnecessary work and pain to developers around here. Apple is if anything more guilty, and while my experiences with Digidesign have only really been positive, others here will tell a different story I'm sure.

So, until we have an independent API that can be promoted on its own merits, I don't see any point in doing anything specifically anti-VST3.

Regards,
Angus.

This is mostly a bump, because I think this is a fantastic point well articulated.

I agree totally. Well said.

.t

[stefancrs]

What do you mean with the frontend suggestion?

I ment like your synth shows its knobs and sliders to the user, its parameters with total recall to the VST host but has its engine separate.

Not sure I would see what the point of that would be? Why not just use the outer API instead of adding another, redundant one, internally? I must be missing something here

[jouni]

I think VST3 won't make its path into plug-in developers' plug-ins at the moment, at least not into version upgrades. The problem is, if a customer used version 1 of plug-in which was released under VST2.4, it's dangerous to replace that said plug-in with version 2 released under VST3: you will either have to give it a new DLL name, and ask customer to keep both versions, and to use them independently, or you'll have to break customer's projects that rely on VST2.4 plug-in (if you replace VST2.4 plug-in DLL with a newer one). Beware

What do you mean? VST3 can easily replace VST2 plugin, if you just code your VST3 properly. Host generates special GUID from old VST2's 4-char ID and check if such VST3 GUID exists. If it does, the VST3 is loaded instead and the old saved state is set to the VST3 plugin. Atleast this is how it's supposed to work per the SDK.

[Urs]

Atleast this is how it's supposed to work per the SDK.

Hmmm... we'll see...

[Paulie Phonick]

Very interesting read this. Looks like Steiny made a big mistake of not giving their new spec the right name - they should've called it ViSTa I hope that they'll end up shooting themselves in the foot with this petty attempt to stifle competition instead of doing anything innovative.

In contrast to Steiny's actions, the open plugin standard initiative is a great thing. I fully agree with what's been written on the need for such an API. Fingers crossed for it to work out and get widespread host adoption.

For my non-technical 2 cents, I'd propose including development of wrappers for existing plugin standards in the new API/SDK development process. Providing new spec wrappers for VST2/3, DXi, AU, etc. would assure that the huge pool of existing plugins can be used within hosts that support the new spec - and the hosts could then support multiple existing plugin standards effortlessly through the new spec. This could motivate host devs to support the new spec - first the ones without their own plugin APIs, then the remaining ones through market pressure. If at the same time plugin devs started producing native new spec plugins, multiple plugin formats could become a thing of the past (and good riddance!) :dreams:

As for the name for the new API - how about DUPS = Devs United Plugin Standard?

We'll probably end up having a name poll here on KvR, but I wouldn't be surprised if the outcome was Fish

[lowkey]

What do you mean with the frontend suggestion?

I ment like your synth shows its knobs and sliders to the user, its parameters with total recall to the VST host but has its engine separate.

Not sure I would see what the point of that would be? Why not just use the outer API instead of adding another, redundant one, internally? I must be missing something here

No worries

I mean using vst's, for instance, like these people have...

http://www.hypersynth.com/hypersid.html

http://www.tcelectronic.com/Default.asp?Id=11852

http://www.focusrite.com/global/product ... iquid_mix/

As far as the host is concerned it's a VST like any other. Instead of sending information to hardware it could be another programme. The developers can start their research and development on the engine until programs support it natively.

It could by-pass the "chicken and egg" when a new plug-in format comes out because the bit that does the work is separate. It would be like using VST/AU or any other plug in format like a web browser connected to a server.

[Tonmann]

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

Then I'd suggest "dynamite", since it can shatter any "Stonemountain"

cheers,
Chris