Don't know if anyone noticed... VST3

[Sequoia_user]

Why not call it Trogdor?

I mean it will strike fear in hearts of mere mortals and woo the ladies and make the enemy crouch in dispear...

never mind...only strngbad can make that crap sound cool.

[AdmiralQuality]

[Sequoia_user]

It wasn't anything I said was it?

Hey do you know anybody who makes a real good mutron III plugin?

[stefancrs]

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.

In that case you just mean a wrapper and I think those will be thought of, but I don't see why that makes things with JACK or something similar any better? It's still not a plugin standard? Wrapping specific hardware in a VST shell is quite different, imho

[docdued]

Hey do you know anybody who makes a real good mutron III plugin?

I'd propose BUTT = "Best User Transferring Technology".

So what's the best butt plugin out there?

[Tonmann]

Hey do you know anybody who makes a real good mutron III plugin?

I'd propose BUTT = "Best User Transferring Technology".

So what's the best butt plugin out there?

Seems you've been watching too much gayporn lately

[docdued]

Nah, just been hanging out on kvr too much!

[Aleksey Vaneev]

if you just code your VST3 properly.

I've missed the point then... So, you can embed an old VST-ID into GUID?

[jouni]

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

Hmmm... we'll see...

From hosts point of view it's not big deal. Host need to enumarate the plugins anyhow so there's list of class GUIDs and the VST ID is in the song (or should). No big deal calculating the special GUID (the SDK has function for it in the FAQ part - strange place though) and checking if such VST3 class exists and loading the old state in it. Of course plugin developer needs to be old-chunk aware when doing the state loading.

[heeb]

Hi dear Devs,

I don't know if anybody pointed this out already (I'm at work and don't have the opportunity to read all posts ATM...), but it would be really, really nice if any new plug-in standard (API, SDK) would be as easy as possible to translate into other languages. My language is Delphi and FreePascal/Lazarus.

Example of how NOT to do it: the DirectX plug-in standard was made in such a way (bad, bad M$!!!) that it turned out to be utterly impossible to natively write a working DX plug-in in Delphi! Various people (including me) have tried and failed. Trevor Magnusson created a workaround to this problem, but he had to resort to using C(++) to build a kind of wrapper-dll's... It works, but it's ugly, and I doubt many people are actually using it...

I guess we don't want *that* problem in any new plug-in standard! So, please, keep it simple & standard, following all good conventions, tried and tested, to allow programmers using other languages to use it without any problems!

Only if programmers of other (serious) languages are allowed in, can a plug-in standard be truly considered "open"!



Regards,

Heeb.

Edit:

P.S. I guess here some do's and don't's (written from my approach as a Windows / Delphi developer!):

Do's:

- Plug-ins should be simple, standard, loadable libraries. E.g. under Windows: dll's.

- Calling convention of any function exported from the plug-in should be something standard. E.g. 'stdcall' or 'cdecl' under Windows.

- When passing strings: standard null-terminated, C-style.

Don't's:

- Please, please, don't have plug-ins be COM objects or something like that...

I'm sure there's more. When I think of something, I'll update!

[duncanparsons]

heeb, I know exactly where you are coming from... I am more than sufficiently c++ aware, but Delphi is my dev platform of choice.

DSP

[heeb]

heeb, I know exactly where you are coming from... I am more than sufficiently c++ aware, but Delphi is my dev platform of choice.

DSP

Hi DSP (the coolest initials, BTW!),

thanks for the support. If you have any more ideas about do's and don't's, please post them!

Thanks,

Heeb.

[asseca]

Hi heeb,

I agree 100%, as Delphi is my preferred programming language, most probably I only need the low-level API, something very similar to VST2.4 ...

[jouni]

Interfaces are nothing to fear even in Delphi. Personally I like interfaces, it's elegant, clean and easy way to extend without worrying about backwards compatibility problems. One of my favourites features in Delphi language is the super easy interface syntax.

[duncanparsons]

'tis true, working for Sage (accountancy software) using Delphi (and c++), they were pretty hot on that sort of thing for the applications I worked on.

Having said that, I don't particularly want to be the one who does the port!

wrt FP, I can't recall that it fully supports COM yet, but with VST3's 'actually, I'm not really COM' approach, it will probably be OK. But they could do with ensuring that the LCL works in DLLs without major hacking...

DSP