Don't know if anyone noticed... VST3

[Aleksey Vaneev]

To quote a long-time Voxengo supporter (Neil Wilkes):

Can I just ask one thing?
On the multichannel support, for the love of all the gods please do not implement things in the same way that Steinberg have done in Nuendo 4.
They have global operation of all surround plugins, and that is as close to useless as a chocolate teapot. I personally cannot think of any use at all where I would want to give the same settings across all 6 channels

(forum http://www.voxengo.com/forum/ar/1679/ )

And comment from the same person about Overtone GEQ's multi-channel support (which is VST2.4):

The grouping is superb - it works like this in the Steiny Surround Edition. Very handy being able to link, say, L/R and Ls/Rs as well.

You see, it's not about spec, but about plug-in's design.

[Fredo Gevaert]

You see, it's not about spec, but about plug-in's design.

Aleksey,

In all respect, but you should know that the multichannel support in the Nuendo 4 plugins is just the *first* phase of the development of those plugins. At this moment the plugins are not designed (read: not ready) to be used as surround mixing plugins or as replacement for the Nuendo Surround Bundle.
Steinberg has this (unfortunate) tradition to implement features in "steps".
They have good reasons for that, but it highly confuses the users.

Best regards
Fredo

[Aleksey Vaneev]

When we get to discussions of an open standard, it is very important to use polls so that nobody's ideas are left behind and nobody's [wrong] ideas prevail. It's probably useful to have 4-5 'establishing' questions voted first, getting to details later. Doing this on KVR is the best way to do it since voting and discussions will remain open (maybe read-only for everyone except the directly involved parties) for any side critics.

[Aleksey Vaneev]

Steinberg has this (unfortunate) tradition to implement features in "steps".

I do not have problems with that, but users seem to. What annoys me personally is the fact Steinberg announces some 'dynamic IO' in VST3 without actually spending time to implement it properly in their plug-ins. Why VST3 ?

[Zynewave]

That's interesting Aleksey. Would you mind sharing the details about this implementation? (my email: info_at_zynewave_dot_com).

asseca gave the example of the struct. It's the same thing. It's very simple and fully VST-compatible (except being non-standard).

So: kVstAutomationType = 7?
And what is the plugin canDo string you use to announce support for this event type?
Can you list the plugins you've implemented this in?

I think it is a good idea to have this information available at a central place. Maybe just a topic here in the development forum. If I had implemented this without knowing of your solution, I could have used event type 7 with a different structure definition (e.g. with a glide value and glide time), making our two solutions incompatible.

[Rangtangtang]

---

[Aleksey Vaneev]

So: kVstAutomationType = 7?
And what is the plugin canDo string you use to announce support for this event type?
Can you list the plugins you've implemented this in?

I think it is a good idea to have this information available at a central place. Maybe just a topic here in the development forum. If I had implemented this without knowing of your solution, I could have used event type 7 with a different structure definition (e.g. with a glide value and glide time), making our two solutions incompatible.

You've probably not understood me correctly: I'm only testing this feature together with Synapse Audio's developer, it is not present in any Voxengo plug-in. Of course, standard should be standard, it's invalid to put something on top of a standard without discussion and voting.

[Fredo Gevaert]

I do not have problems with that, but users seem to.

Because the other unfortunate tradition is that Steinberg hardly communicates.

What annoys me personally is the fact Steinberg announces some 'dynamic IO' in VST3 without actually spending time to implement it properly.

You are talking about the Native plugins and not about the SDK I suppose!?

As said it's a matter of communication, all they needed to say is that the VST3 plugins are not designed (yet) to replace the surround bundle. I know what is coming in the next updates of Nuendo4, so I can see why development works in phases/levels/steps. Unless they reveal what will be coming (and thus why things are not finished yet) users can't possibly know and understand the reasons. So they prefer to say nothing at all.

Why VST3 ?

Because they couldn't delay Seq4 anymore.
They have lost so much time with MacIntel and Vista that the userbase became very nervous.

But again, these are comments from my own point of view.
As you know, I am not Hamburg based, so ...


Fredo

[Zynewave]

So: kVstAutomationType = 7?
And what is the plugin canDo string you use to announce support for this event type?
Can you list the plugins you've implemented this in?

I think it is a good idea to have this information available at a central place. Maybe just a topic here in the development forum. If I had implemented this without knowing of your solution, I could have used event type 7 with a different structure definition (e.g. with a glide value and glide time), making our two solutions incompatible.

You've probably not understood me correctly: I'm only testing this feature together with Synapse Audio's developer, it is not present in any Voxengo plug-in. Of course, standard should be standard, it's invalid to put something on top of a standard without discussion and voting.

Ok. Reading your original post gave me the impression that this was something you already had implemented. But it's still a good idea I think. Please keep me in the loop if you decide to go further with this.

[nollock]

When we get to discussions of an open standard, it is very important to use polls so that nobody's ideas are left behind and nobody's [wrong] ideas prevail. It's probably useful to have 4-5 'establishing' questions voted first, getting to details later. Doing this on KVR is the best way to do it since voting and discussions will remain open (maybe read-only for everyone except the directly involved parties) for any side critics.

I also wonder if it would be helpful to have an election to apoint some people to act as leaders of the project, as a committee. While everything should be open and public, Im not sure it will get very far if you have to get 100 people to agree every time we want to nail somthing down.

I think that was one of the main reasons GMPI failed. I followed the list during its first months and it seemed to me that the biggest problem was sorting out the concensus from the chatter and then solidifying it and pushing the project forward.

It only takes a few unhappy people to keep banging on about somthing they see as important for the process to get dragged out 10x longer than it need be.

So a voting process & some guiding committee would be a good idea imo.

At the least we need to avoid falling into the same trap GMPI did.

[asseca]

The struct we've used is similar to your example, kVstParameterType is deprecated. CanDo's is a better protocol to check support of this kind of automation.

So: kVstAutomationType = 7?
And what is the plugin canDo string you use to announce support for this event type?
Can you list the plugins you've implemented this in?

I think it is a good idea to have this information available at a central place. Maybe just a topic here in the development forum. If I had implemented this without knowing of your solution, I could have used event type 7 with a different structure definition (e.g. with a glide value and glide time), making our two solutions incompatible.

You've probably not understood me correctly: I'm only testing this feature together with Synapse Audio's developer, it is not present in any Voxengo plug-in. Of course, standard should be standard, it's invalid to put something on top of a standard without discussion and voting.

Following Aleksey's idea, something like plug-canDo "receiveParamEvents" or "receiveAutomationEvents" should do the trick ...

If this trick was implemented, it could be implemented as a layer over the existing uAudioEffectX.h and uAudioEffectX.cpp, named say uAudioEffectX1.h and uAudioEffectX1.cpp one could then re-introduce the "kVstParameterType = 4" (effectively overriding the deprecated state in VST2.4) which was never used anyway ...

When we get to discussions of an open standard, it is very important to use polls so that nobody's ideas are left behind and nobody's [wrong] ideas prevail. It's probably useful to have 4-5 'establishing' questions voted first, getting to details later. Doing this on KVR is the best way to do it since voting and discussions will remain open (maybe read-only for everyone except the directly involved parties) for any side critics.

... agreed ...

[Aleksey Vaneev]

Because they couldn't delay Seq4 anymore.
They have lost so much time with MacIntel and Vista that the userbase became very nervous.

I guess they've lost more time because of this whole new framework. But it's still pretty strange they are forcing everyone to use their framework. It's a bad business: I also have a vastly efficient framework now, to create plug-ins, but it could be very wrong to force every developer to follow it. It's just a mistake everyone from Microsoft to Apple are making constantly. Programmers are not a herd of lambs: every developer has its own established way of producing software. So, if anybody assumes I'm using Apple's xCode or Microsoft's VC++, they are grossly mistaken: this is what I may call a bad business.

API should be a small stitch between two different pieces of cloth. It's fundamentally wrong to try to seamlessly combine two different pieces of cloth in a hope they'll stay stitched forever.

VST2 already presented THE ONE AND ONLY technically correct way of writing an API: exported entry function + dispatcher wrapped by a C++ class (with C/C++ being a world-wide industrial standard). Overcomplicating it is a way towards technical (compiler, platform) incompatibilities. Probably, Steinberg's engineers are not experienced enough in this aspect of portability (e.g. Microsoft's engineers just do not care about portability, and force every programmer to use Microsoft's own production tools - which is a sign of a monopoly-minded corporation).

[Aleksey Vaneev]

So a voting process & some guiding committee would be a good idea imo.

Automated voting with some set minimum number of voters is very important to get things done fast. After a question has been voted for, it becomes 'resolved question' everyone can further reference. A simple majority should be OK if question consists of 2-3 answers only.

As for the API code base, a single coder should be elected to maintain it (the API code won't be large and won't take much time). Ideally, every coder who wants to take this part should submit a short API 'draft' with his own coding and commenting style so that everyone can choose the best style (e.g. I'm not very happy with VST API's source code style).

[arne]

Let's face it. There won't be one plug-in API. The big players (Digi, Apple, Steinberg, etc) won't follow. They are in direct competition to each other to sell their hosts. Every one is trying to integrate plug-ins as best as it works for them and the business of plug-in companies are dependent on these hosts. So plug-in developers will be forced to follow the host development.
One possible solution for plug-in developers is to build their plug-ins in their own defined API and build up a wrapper for the host API. This is how big companies are working. This über-API and the wrapping could be build by the plug-in community.

arne

[asseca]

Let's face it. There won't be one plug-in API. The big players (Digi, Apple, Steinberg, etc) won't follow. They are in direct competition to each other to sell their hosts. Every one is trying to integrate plug-ins as best as it works for them and the business of plug-in companies are dependent on these hosts. So plug-in developers will be forced to follow the host development.
One possible solution for plug-in developers is to build their plug-ins in their own defined API and build up a wrapper for the host API. This is how big companies are working. This über-API and the wrapping could be build by the plug-in community.

err, if you carefully read this thread, that is what most of the developers posting here have in mind ...