How important is VST3 support for you as a customer

[trimph1]

The poll numbers do not bare out the arguments herein.

The only thing that seems to be going for VST3 right now are the mudfights around it. What does this really prove?

Everything I've seen and read, as far as I understand this, does not convince me that VST3 is a necessity. Nearly as much as some seem to think it does. Hence the numbers on this poll...

[Urs]

VST3 is not a necessity, that's true. But it's neither all that complicated nor is it all that simple. Both of which some seem eagerly convinced of.

For me it's rather uncomplicated because I already have AU and RTAS which require separation of gui and dsp. Not having pointers isn't a problem.

However what I gain is

- I can deliver a whole bundle of plugs in a single binary. Which I can't in VST2 thanks to a watered down shell api that hosts implement only for a single company. That means I can save resources, also on the user's machine. I also have a plugin (not published) that needs this for shared memory (and no, I won't even dare to do dynamic linking). In the end, good for user.

- I can deliver more accurate automation, e.g. for those offline rendering orgies with 8000+ samples per render call. Good for user.

- I can deliver expression maps (mappings of special keys) which I havn't seen in any other plugin API. Good for user, saves him work.

- I can deliver note expressions. Not a big deal, I can do something similar in other APIs, but I bet it's going to be well implemented in Cubase. Good for Cubase users.

- I can deliver 64bit VST on Mac without rewriting my horredous implementation of the VST editor for Cocoa. Good for me, really.

It's only a few things. Easily worth the "pain" (it is none, we've got most of it going, it's a great learning project for my second dev)

If neither of this fits the believe system of the competition. Fine. Reminds me of the AU hatred back then (and the praise for AU when they did it and actually sold some plugs)

YMMV

[trimph1]

However what I gain is

- I can deliver a whole bundle of plugs in a single binary. Which I can't in VST2 thanks to a watered down shell api that hosts implement only for a single company. That means I can save resources, also on the user's machine. I also have a plugin (not published) that needs this for shared memory (and no, I won't even dare to do dynamic linking). In the end, good for user.

- I can deliver more accurate automation, e.g. for those offline rendering orgies with 8000+ samples per render call. Good for user.

- I can deliver expression maps (mappings of special keys) which I havn't seen in any other plugin API. Good for user, saves him work.

- I can deliver note expressions. Not a big deal, I can do something similar in other APIs, but I bet it's going to be well implemented in Cubase. Good for Cubase users.

- I can deliver 64bit VST on Mac without rewriting my horredous implementation of the VST editor for Cocoa. Good for me, really.

OK.

I can see now why it might be of use in your case...I am in a position myself where I might want to look into this a little further if, and when, I get into this VST stuff a little more...

Thanks for clarifying it a little more here for this one...

[koolkeys]

I think another hidden benefit is being more accessible to the Cubase user base. Like Steinberg or not, they have a very large group of users. And making plug-ins that will benefit them, whether due to Steinberg's purposeful limiting of the program or otherwise, opens you up to a larger potential customer base(even if you blindly hate Steinberg, which I'm sure nobody in this thread does ).

Brent

[koolkeys]

VST3 is not a necessity, that's true. But it's neither all that complicated nor is it all that simple. Both of which some seem eagerly convinced of.

For me it's rather uncomplicated because I already have AU and RTAS which require separation of gui and dsp. Not having pointers isn't a problem.

However what I gain is

- I can deliver a whole bundle of plugs in a single binary. Which I can't in VST2 thanks to a watered down shell api that hosts implement only for a single company. That means I can save resources, also on the user's machine. I also have a plugin (not published) that needs this for shared memory (and no, I won't even dare to do dynamic linking). In the end, good for user.

- I can deliver more accurate automation, e.g. for those offline rendering orgies with 8000+ samples per render call. Good for user.

- I can deliver expression maps (mappings of special keys) which I havn't seen in any other plugin API. Good for user, saves him work.

- I can deliver note expressions. Not a big deal, I can do something similar in other APIs, but I bet it's going to be well implemented in Cubase. Good for Cubase users.

- I can deliver 64bit VST on Mac without rewriting my horredous implementation of the VST editor for Cocoa. Good for me, really.

It's only a few things. Easily worth the "pain" (it is none, we've got most of it going, it's a great learning project for my second dev)

If neither of this fits the believe system of the competition. Fine. Reminds me of the AU hatred back then (and the praise for AU when they did it and actually sold some plugs)

YMMV

But...but...but.....you could do all this already in 1983!

Brent

[AdmiralQuality]

- I can deliver 64bit VST on Mac without rewriting my horredous implementation of the VST editor for Cocoa. Good for me, really.

That's the one item that has some interest for me (at least given my current products, perhaps someday I might do something where some of that other stuff mattered).

Is their AU wrapper working? For x64 too? I too would rather avoid the Cocoa, though whichever way I go there'll be a lot of wheel reinventing as again, I've extended an older version of VSTGUI and essentially need to throw it all out and start again to migrate to the new.

[aciddose]

i used abstraction interfaces for all system-dependent stuff so that last point against cocoa would only be useful if i didn't need to use anything else mac related at all, which unfortunately will probably make up a majority of my work, while implementing my gui using cocoa will take a matter of an hour or two probably mostly due to the crap documentation and horribly written open source code, when available, for mac related stuff.

i was actually going to ask "how? do they use wine or something?"

are you just referring to the new version of vstgui? vstgui still sucks as it always has sucked, it can't do compositing and doesn't manage objects in a sane way. i'd think anyone would need to amend it a huge amount to make it workable, by which time you'd write my gui library five times over due to it's massive advantage in simplicity and power.

(my code already works on xlib with zero changes, just using the system-specific windowing and canvas implementations, with the exception that i use getopenfiledialog on windows because it's easy, and substitutes don't always exist)

[AdmiralQuality]

vstgui still sucks as it always has sucked, it can't do compositing and doesn't manage objects in a sane way.

We're getting a little off topic here, maybe we should revive the thread in the Dev board. But what makes you say it can't do compositing? Where do the shadows and antialiasing of my controls come from?

And I believe there's a new xml based format for describing your GUI, where you need to write virtually no GUI code (at least to do plain vanilla implementations). Is this correct Urs?

Which VSTGUI comes with VSTSDK 3.5 anyway? Is it 4 (which AFAIK is still Beta) or is it still 3.6? Can't be bothered to look.

[aciddose]

We're getting a little off topic here, maybe we should revive the thread in the Dev board. But what makes you say it can't do compositing? Where do the shadows and antialiasing of my controls come from?

do they have an implementation of compositing layers now? you can do most effects with three layers, but that's generally a minimum. you need at least background, foreground and overlay to get most composites working.

that is: always drawn first, always drawn middle, always drawn last.

other issues can be delt with by using z-orders in a lot of cases, but you still need the individual layers.

[AdmiralQuality]

We're getting a little off topic here, maybe we should revive the thread in the Dev board. But what makes you say it can't do compositing? Where do the shadows and antialiasing of my controls come from?

do they have an implementation of compositing layers now? you can do most effects with three layers, but that's generally a minimum. you need at least background, foreground and overlay to get most composites working.

that is: always drawn first, always drawn middle, always drawn last.

other issues can be delt with by using z-orders in a lot of cases, but you still need the individual layers.

You can pile controls on controls on controls. It's kind of cool actually, though not of much use. But say the shadow from one control falls over another, not a problem, you just need to decide which control is on "top". (And the mouseable area of a control can be bigger or smaller than the bitmap area.)

Z-order seems to be controlled by the creation order. (Note that this is VSTGUI 3.0 I'm talking here, things may have changed since then.)

My shadows are built into my PNG sources. They have alpha channel built in (the 3D software let me render shadows to alpha). Antialiasing, same thing. None of the background is built into the control images, they composite on the fly.

My "filmstrips" look like this...



They even composite into the browser!

[aciddose]

yes... so vstgui has a background layer now, it's forced to redraw first, before any control on top is redrawn then.

edit: ah i remember - vstgui used to have a single background pointer that it used to do a blit before a control is drawn. if that's still the implementation then yes "escaped lunatic" applies, and "sucks" applies too.

it would also need overlay to accomplish lighting effects such as led glows, reflections and so on. that's because when anything _below_ is redrawn, the stuff _above_ must be forced as well.

i suppose that's all possible by using z-order too, but you'd have to create three groups that are always forced in order anyway, so why not just go with it and have real groups instead of forcing front/back order.

anyway if vstgui has that at least it isn't totally horrible, but i suspect if i looked at the code it would still be implemented in a way which would have to be considered the work of some escaped insane lunatic.

[AdmiralQuality]

yes... so vstgui has a background layer now, it's forced to redraw first, before any control on top is redrawn then.

It PROBABLY only redraws the invalid area, but I'm not sure offhand. Works, s'all I care about.

it would also need overlay to accomplish lighting effects such as led glows, reflections and so on. that's because when anything _below_ is redrawn, the stuff _above_ must be forced as well.

There's LED glows and transparency in Poly-Ana (right click a control for MIDI Learn to see a semi-transparent background to the custom control it brings up).

i suppose that's all possible by using z-order too, but you'd have to create three groups that are always forced in order anyway, so why not just go with it and have real groups instead of forcing front/back order.

anyway if vstgui has that at least it isn't totally horrible, but i suspect if i looked at the code it would still be implemented in a way which would have to be considered the work of some escaped insane lunatic.

Well, it is. But it works. It's also been significantly refactored since the older version I still use. But my customers don't pay for code style. It's only me who benefits from slick code, and I'd rather spend 15% more time unwinding spaghetti than take 3 months off to do yet-another-ultimate-GUI. So long as it works, I'm fine with it. I'm all about results and saving development time for features that the customer can appreciate. But I am faced with some cross platform issues now, particularly x64 on OSX. Cocoa, Objective C... I just threw up in my mouth a little.

[aciddose]

overlays are needed if overlay elements can over-lap. for example if you put two of your leds together you probably should notice one will erase the glow of the other one when it redraws itself, depending on their z-order.

that's not a big deal with small leds, but once you use bigger elements with overlapping overlays it's a noticeable bug.

[AdmiralQuality]

overlays are needed if overlay elements can over-lap. for example if you put two of your leds together you probably should notice one will erase the glow of the other one when it redraws itself, depending on their z-order.

Nope. Again, I can overlap controls to my heart's content. Try it. Right click for MIDI Learn, the BG of the MIDI Learn control is transparent (barely) and its shadow will fall over shadows, LEDS, glow, whatever, of other controls behind it, without breaking the way the underneath stuff looks. (Or works, I can still move the underneath controls!)

It just draws them in creation order. So last created controls are on top. There doesn't appear to be a limit that I've noticed.

[aciddose]

no you haven't noticed it i guess.

so you have one led, the background is drawn under it, it draws the body, then the glow is added on top.

it's next to another led which overlaps it, so the previously drawn glow was inside it's rect. now the background is drawn to fill this led's rect - uh oh, the glow has been erased.

won't occur if you update a rect including all the leds, because the background for all would be filled at the same time. that might be why you haven't noticed - or it might be because nobody would actually notice because they're so damn small. like i said it's an issue with larger objects in some cases.

but the overlay isn't pointless!

- anyway private message type stuff not really great to have in the vst3 thread

my original point though was just that if it only matters for vstgui, like you i've got code that isn't vstgui - mine isn't even related. so that kind of throws out the whole advantage then because using out-of-the-box vstgui would be like a nightmare for me.