How important is VST3 support for you as a customer

[AdmiralQuality]

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.

There's no "add" rasterop. It's all just "blend". Still, you'll see I pull off glows with my LED buttons. The glow is built into the alpha channel (and the two states of the button are in the filmstrip, one bright with glow, the other dark with no glow).

They don't get ugly when they overlap. There's some things that aren't quite as in reality, shadows dimming light glow underneath them, etc. But the eye is a lot more forgiving than the ear.

You're trying to composite controls in code, rather than in Photoshop. Why assemble layers when you're always going to get the same composite every time? Compositing the glow on the fly doesn't save space, and (while infinitesimal) it doesn't save time either. Better to can the answer and just comp it once over the BG (and whatever other controls may happen to underlap it). You're trying to be too cool. No points for that this business, the customer will never know how cool your code is.

Anyway, we should take this into the Dev board. There's a VST3 thread there already I believe.

[aciddose]

how can you manage realistic coloration without add? two states ok - but my lights are continuous, not on/off. i'd need a led strip, plus the edges still wouldn't mix correctly. plus overlays like reflections wouldn't work at all.

i don't really care what customers think about things if they're things they wouldn't even notice. i notice.

anyway i did an edit in the previous post regarding the reason for the off-topic which is: vstgui can't justify vst3, that would be ridiculous unless you're using unmodified code - which in my opinion and i think yours also is unmodified code which sucks.

combined plugin formats? if midi cc is thrown out in vst3, wouldn't your vst3->vst2 plugin also lack midi cc? in which case it's throwing out the baby with the bath water so you can use the tub for sweet liquor.

"only for a single company" threw me off - he means multiple plugin types. yes, i would have preferred if vstmain were passed a plugin parameter, or "list all plugins" opcode, and that also applies to accurate automation - i wish they'd just use the features already in vst2 which implemented that.

[AdmiralQuality]

how can you manage realistic coloration without add? two states ok - but my lights are continuous, not on/off. i'd need a led strip, plus the edges still wouldn't mix correctly. plus overlays like reflections wouldn't work at all.

i don't really care what customers think about things if they're things they wouldn't even notice. i notice.

That's why you do this as a hobby, not a profession. I'm a perfectionist too, but c'mon, a shadow over a light isn't going to make anybody's music sound any worse.

Aside from that, it's just art skills. If you blend something bright over something dark, you get something lighter. So my RGB channels have a bright yellow blotch around the LED-button, and the alpha channel is solid within the button, but with a very soft "glow" in the alpha around it that would normally be 100% transparent. Presto, glowing buttons.

If the background was lighter than the glow, then it wouldn't work. But as that would look ugly anyway, it's never a problem. It's what I call a "Dr. it hurts when I do this" problem. (Solution: "Don't do that!")

[AdmiralQuality]

Check it out, shadow AND glow. All in one PNG.

[aciddose]

well it would be best to get back on topic - but still like i said it creates extremely visible issues with larger elements. try making your buttons mega-huge and make the glow's edges round and you'll notice. there will be a straight line where the glow from another button is suddenly cut off when they're placed side-by-side and it'll look real weird, then you'll have to figure out what's going on and fix it.

if not, it's not a big deal and i wouldn't encourage you to change any code because making it easy to work with involves throwing out a lot of the way vstgui does things, in my case i wrote 100% from scratch rather than modify it because i'm pretty certain a total of zero percent would be in common. in my case though i went that direction anyway, so it's a lucky coincidence it makes the overlay thing easy to implement.

what about a rebuttal of the other things in urs' list?



it occurs in overlay problems like this, text under glass, glow on glass, overlapped glow.

[AdmiralQuality]

what about a rebuttal of the other things in urs' list?

Like I already said, most of those things have little to no value to any product I'm currently working on or even in the idea stage. There were also a few items where I wasn't sure exactly what he meant.

[aciddose]

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

well, you technically "could" have done that in 1983, if the concepts existed in the first place. i'm sure we can dig up an example of each and every feature listed from pre-1983.

- multiple formats or implementations in the same binary glob (ok, a valid thing. almost definitely already done then though...)
- transmitting messages? (note expression, key mapping, etc, obviously this can all be implemented pretty much anywhere, anytime)
- not writing obj-c? (no cocoa) (anybody can do that, unless you're forced by threat of a strangling turtle-neck)

you could also do all these things in vst2. so why suddenly change to a class-based interface? it's all about the legal strangle-hold other format creators have over their formats. sure, this might be a paranoid conspiracy theory, but it also makes a lot of sense. nobody can write AUs on windows, it's impossible because apple wouldn't license it. nobody can do RTAS without a license. nobody can do DXi, period, because it sucks. now, nobody can write VST3 without worrying about legal consequences unless they sign contracts. who knows where it leads from there? they can demand anything of a vst3 developer now, the contract doesn't grant any rights, it merely takes them away in return for a "promise" not to sue, which isn't even explicitly made.

edit: i forgot to say why nobody can do RTAS for those who wonder; because they decided to implement half the host inside the plugin format, and therefore each and every plugin. it has a million classes and weird functions nobody wants to use except maybe that one guy, but he's probably the lunatic who wrote it.

[AdmiralQuality]

- 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.

Saves Resources? Like, a handful of disk clusters or FAT entries? I just don't care, I can't imagine distributing a suite of plug-ins anyway, I'd be more inclined to have them separate so the user can decide which they want in their system.

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

Yeah, that's nice. But nobody should be using buffers that long anyway (yes you can reduce CPU load a bit by relaxing latency, but you quite quickly bottom out, long LONG before you reach ridiculous latencies like your example here). If I had my way, everything would be audio, there'd be no distinction between an audio signal and a control stream, and anything would be routable anywhere. Then you could build modular synths out of disparate products.

But of course they didn't do that, that would be enabling to the user instead of restrictive. Just not how they roll. Instead we got automation++. Might as well be audio, but isn't. Why have one signal format when you can have two? (Or more...?)

- 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.

This is the one I didn't get. "Mappings of special keys"? Do you mean like the name of a drum map that appears on the piano roll and other note editors? Doesn't VST 2.4 already offer this somewhere?

- 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 believe the host delivers them and you respond to them. But semantics aside, again, I'd do this with monosynths on separate tracks. Why anybody thinks editing separate tracks would be more tedious than editing notes all crammed in the same view is beyond me.

That would also let me do things like place the different instruments in different parts of the room. If I can pan them, I damn well want to be able to place them in different parts of the reverb field (and with a third party reverb plug-in, not a welded-on effects section). Something you can't do when they're all mashed into the same track.

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

Appreciated, but doesn't save me a massive re-write of all my custom extensions to VSTGUI.

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)

It's not just pain. It's confidence. I'm sitting on a very well tested product with virtually no bugs (there's one actually, but it's teensie). To change that removes the confidence that my customers and I have, and you KNOW it will introduce a whole bunch of new issues. That's just a kick in the pants, and again, for absolutely no benefit to the existing customers. Sorry, but they were nice enough to send me money, so they count more than possible customers. If prioritizing my existing customers over trying to rope in new ones is wrong, then I don't want to play this game anymore. It's Admiral Quality. Not Admiral Gotcha.

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

I praise Symbiosis for saving me the hassle. So I'm interested in the VST3->AU wrapper too. Again I ask, is this working OK? And do you have results on x64 OSX yet?

There AD, happy?

[aciddose]

Saves Resources? Like, a handful of disk clusters or FAT entries? I just don't care, I can't imagine distributing a suite of plug-ins anyway, I'd be more inclined to have them separate so the user can decide which they want in their system.

not to rebutt your rebuttal when i've demanded it, but there are unfortunate cases on mac where you'd need this. i only heard this so it's 2nd hand, but something to do with packages having to contain their own data files (no all users storage like "application data" on windows) and other packages not being allowed to look at or access outside their own package.

so it's really about apple being retarded combined with the need for some plugins to have very large shared data-sets (for example, samples) that couldn't justifiably be duplicated.

for automation no, doesn't really make sense to do sample-wise automation at all, ever, but even if it were needed it could easily be used in vst2 - where it pretty much already exists except for a specific structure definition. type one in yourself, in fact i already did in a kvr thread, we can start using it and if hosts support it, boom, sample-accurate automation in vst2. minus one point vst3, even in the eyes of the user.

expression maps i'm not sure about, but having an implementation in vst for safely getting names for anything would be really nice. the current implementation is ridiculous in vst2 and vst3 with the length limitations and so on. the safe way to do it would be for the host to pass a buffer plus a length, and then the plugin would copy up to the length, whatever it wanted to display. if the host had a valid reason for a short length, that would be fine, but it wouldn't be in the specification how long things can be maximum, it could be how long by minimum as a guide to implementers of hosts instead.

note expression is just plainly dumb, just like the side-chaining support. why call it that? you might want to sent another signal that gets processed in some way other than as a side-chain, such as a ringmod for example. or maybe have a pre/post input so users can bypass some eq or something on the input and go in "dry". calling it sidechain is an appeal to users who only ever thought of one possibility, and might be confused so much they'll cry if they're forced to use something called "ext route".

both are things which with minimal effort could be added to vst2.

in fact vst3 could just be vst2 with some major additions, but instead they wanted to change the very format of the code itself in a way which provides no real advantage to the programmer, but rather a disadvantage. why would this be? incompetence?

ok now i'm happy.

[koolkeys]

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

well, you technically "could" have done that in 1983, if the concepts existed in the first place. i'm sure we can dig up an example of each and every feature listed from pre-1983.

- multiple formats or implementations in the same binary glob (ok, a valid thing. almost definitely already done then though...)
- transmitting messages? (note expression, key mapping, etc, obviously this can all be implemented pretty much anywhere, anytime)
- not writing obj-c? (no cocoa) (anybody can do that, unless you're forced by threat of a strangling turtle-neck)

you could also do all these things in vst2. so why suddenly change to a class-based interface? it's all about the legal strangle-hold other format creators have over their formats. sure, this might be a paranoid conspiracy theory, but it also makes a lot of sense. nobody can write AUs on windows, it's impossible because apple wouldn't license it. nobody can do RTAS without a license. nobody can do DXi, period, because it sucks. now, nobody can write VST3 without worrying about legal consequences unless they sign contracts. who knows where it leads from there? they can demand anything of a vst3 developer now, the contract doesn't grant any rights, it merely takes them away in return for a "promise" not to sue, which isn't even explicitly made.

edit: i forgot to say why nobody can do RTAS for those who wonder; because they decided to implement half the host inside the plugin format, and therefore each and every plugin. it has a million classes and weird functions nobody wants to use except maybe that one guy, but he's probably the lunatic who wrote it.

I was making a joke. I'm done arguing with brick walls about all the rest.

Though I will say that the dev in this thread that I would tend to believe the most is Urs above anyone else here(for several reasons), so I still do hold high weight in his views and the points he has made.

But regardless, it was a joke, so no need for the monologue to prove it wrong, haha.

Oh, and MY bet is that the reason RTAS isn't used by many devs is because of the application and approval process. Only going by what various devs have told me, so it could be a wrong assumption. I'm not terribly concerned about it, though I do have ProTools.

Brent

[AdmiralQuality]

Saves Resources? Like, a handful of disk clusters or FAT entries? I just don't care, I can't imagine distributing a suite of plug-ins anyway, I'd be more inclined to have them separate so the user can decide which they want in their system.

not to rebutt your rebuttal when i've demanded it, but there are unfortunate cases on mac where you'd need this. i only heard this so it's 2nd hand, but something to do with packages having to contain their own data files (no all users storage like "application data" on windows) and other packages not being allowed to look at or access outside their own package.

so it's really about apple being retarded combined with the need for some plugins to have very large shared data-sets (for example, samples) that couldn't justifiably be duplicated.

Nothing's stopping you from using the regular file system for shared data. My keyfile and .ini live outside the package, not a problem. As for shared graphics, they can live outside just as well (see my custom background feature http://www.admiralquality.com/products/ ... ackgrounds "On Mac, place the Poly-AnaBG.png file in \Library\Application Support\Admiral Quality.")

So nothing HAS to be in the package, other than the executable payload. Which of course is going to be unique for each plug-in.

for automation no, doesn't really make sense to do sample-wise automation at all, ever, but even if it were needed it could easily be used in vst2 - where it pretty much already exists except for a specific structure definition. type one in yourself, in fact i already did in a kvr thread, we can start using it and if hosts support it, boom, sample-accurate automation in vst2. minus one point vst3, even in the eyes of the user.

I certainly do fine with a typical buffer size and control smoothing in the plug-in. I wouldn't shun sample accurate automation, but I couldn't tell you in an A-B test which was which, except for the most extremely ridiculous examples (like Urs provided;) ).

expression maps i'm not sure about, but having an implementation in vst for safely getting names for anything would be really nice. the current implementation is ridiculous in vst2 and vst3 with the length limitations and so on. the safe way to do it would be for the host to pass a buffer plus a

Look into VSTXML. You can get by the name length limitations by including that in your resources.

length, and then the plugin would copy up to the length, whatever it wanted to display. if the host had a valid reason for a short length, that would be fine, but it wouldn't be in the specification how long things can be maximum, it could be how long by minimum as a guide to implementers of hosts instead.


note expression is just plainly dumb, just like the side-chaining support. why call it that? you might want to sent another signal that gets processed in some way other than as a side-chain, such as a ringmod for example. or maybe have a pre/post input so users can bypass some eq or something on the input and go in "dry". calling it sidechain is an appeal to users who only ever thought of one possibility, and might be confused so much they'll cry if they're forced to use something called "ext route".

Exactly. Not only is it overkill, but it's sadly narrow in its scope of how it can be used. Like I suggested, everything should just be audio streams. And the per-note thing is again, unlike anything that mankind has ever known, so why start now? Just use separate tracks. Easier to arrange your parts, play them with distinct "personalities", draw in fades over MANY notes (not just one), etc. And besides, most of that automation belongs to the mixer. If my plug-in's output is being panned, it doesn't need to know. That's downstream.

both are things which with minimal effort could be added to vst2.

Yep. Without breaking a thing.

in fact vst3 could just be vst2 with some major changes, but instead they wanted to change the very format of the code itself in a way which provides so real advantage to the programmer, but rather a disadvantage. why would this be? incompetence?

ok now i'm happy.

They needed a new version number. New numbers make people think they need something. And no, their SDKs, while not the worst abominations I've ever seen, are always good for a laugh or a "what were they thinking" head shake. Still, as I said, I'm 100% results oriented so if it works, I can live with whatever internal comedy is going on.

[Urs]

I guess we should have a large portion of this split into the Dev forum...

Anyhow, no I'm not using VSTGUI and I have also abstracted platform and plugin API. However, VST2 was so "convenient" to deliver its own event handling (mouse events, key events) so that this stuff resides in my VST editor class alongside the platform-specific events. Thus in case of VST2 my code for API and certain platformspecific parts of the UI reside in the same file. I really couldn't be bothered to wade through this mess and entangle it for Cocoa/ObjC++. I can see large difficulties to do fat binaries (32/64 bit) when mixing access of the core framworks in a set of files.

Regarding the 8000+ sample buffers during offline rendering or on non-selected tracks, that's something some hosts simply tend to do. Can't help it.

Regarding the resources saved: For instance in AU and RTAS my GUI code & data is shared upon instances of any Uhbik. Those big knobs take up quite some memory, so I presume that the speed increase during redraws and all is quite considerable.

[whyterabbyt]

- 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 have to ask; why do you consider this a benefit? What resources are saved in a single binary that couldnt be saved some other way?

If your plugins go down this route, would this mean I would potentially no longer be able to organise your plugins in folders by type the way I have preferred to for ten years?
That's really not something that sounds like a benefit to me.

[Urs]

If your plugins go down this route, would this mean I would potentially no longer be able to organise your plugins in folders by type the way I have preferred to for ten years?
That's really not something that sounds like a benefit to me.

Interesting point. Need to ask Clemens (2nd dev here) if VST3 has a "plugin typing" facility like RTAS has.

Otherwise of course there's still VST2.

[whyterabbyt]

Interesting point. Need to ask Clemens (2nd dev here) if VST3 has a "plugin typing" facility like RTAS has.

Problem is, where a plugin winds up in the RTAS plugin categories is defined by the plugin developer, not the user. Thats almost worse, sometimes.