What is the deal with DAWs and Sequencer's VST recognition?

[elephant stone]

I agree with grymmjack about Tracktion scan:

1. you can edit the list of the corrupted vst to fix.
2. Complete scan take time if you have 750 vst to scan (what's the use ?) but you only do once !
3. When you add new vst then you have the "quick scan" function to scan only new or modified plugins. Take 5 secs.

Simple and powerful. Tracktion's way !

[tony tony chopper]

the problem isn't hosts, but crap VSTi programmers. Either you just scan & list DLLs (pretty safe, it's what FL does by default) or you open the DLLs to get more details about the plugins (mainly number of in & outs) to sort them better.

This would work.. if some dumb programmers didn't choose to show their dumb 'hello, this is my first plugin' messagebox whenever their DLL is opened, or the usual 'please register' box. In fact, message boxes should be banned from any plugin, a plugin should just not suspend the host at unexpected times. And then there are plugins that just crash when closing the DLL if no instance of the plugin was created.

What's to blame is VSTi programmers and the fact there's no 'quality insurance' VSTi test app from Steinberg. And sometimes the user himself who moves VSTi DLLs manually, or doesn't install them correctly, so that they can't find their associated data files & crash.

[bduffy]

I agree with grymmjack about Tracktion scan:

1. you can edit the list of the corrupted vst to fix.
2. Complete scan take time if you have 750 vst to scan (what's the use ?) but you only do once !
3. When you add new vst then you have the "quick scan" function to scan only new or modified plugins. Take 5 secs.

Simple and powerful. Tracktion's way !

I don't know if the demo's different than the real version, but I found Tracktion took a disappointingly long time, every time, to scan and load up - even with the "quick scan" on. Am I missing something?

[brambos]

It seems to me that there'd be way Steinberg figured out that just works
with the way they created the VST standard.

Problem is that many plugins simply don't fully comply to that VST standard. And beside, any VST developer will be able to tell you that the VST standard isn't exactly the best documented and unambiguous standard on the planet

[elephant stone]

I don't know if the demo's different than the real version, but I found Tracktion took a disappointingly long time, every time, to scan and load up - even with the "quick scan" on. Am I missing something?

I have no experience with other host I could compare to (except Tobybear minihost and few attempts with cubase vst).
But I can tell you a complete scan takes no more than 5 minutes for me for a hundred of vsts, some of theme beeing "huge" (Proteus x, Korg Legacy collection...). Maybe depends of your computer ? Mine is a basic one (HP Pavilion AMD 3000 + 512 Mo).

[bduffy]

I don't know if the demo's different than the real version, but I found Tracktion took a disappointingly long time, every time, to scan and load up - even with the "quick scan" on. Am I missing something?

I have no experience with other host I could compare to (except Tobybear minihost and few attempts with cubase vst).
But I can tell you a complete scan takes no more than 5 minutes for me for a hundred of vsts, some of theme beeing "huge" (Proteus x, Korg Legacy collection...). Maybe depends of your computer ? Mine is a basic one (HP Pavilion AMD 3000 + 512 Mo).

Not the initial scan, which I expect to take awhile with any host, but each time I open Tracktion 2, it takes about as long as Cubase to open, which I'm a little disappointed with, as I've been thinking about switching to or at least incorporating another host. One that opens immediately, like Sonar, and doesn't have to have a long-winded scan every time. Because Tracktion is designed to be more immediate, with that all-in-one interface, I'm just a little surprised that it's so slow on loading. And at work, I can't get it to open, period; it crashes on the initial scan.

[elephant stone]

All you have to do is unchek the "scan vst folder at startup" function in the settings menu. Sorry I'm not on my Tracktion PC so I can't be precise about the location / name of the function - but this is the way.

[grymmjack]

Yes, grymmjack, that i exactly what I mean.
Audition does this? I can barely believe this is allowed to happen.

Say you install a new program (Audition as an example).
Some VST you have crashes it.
Now imagine the amount of time it would take to figure out which of 600 VSTs
was doing this.

Ok, so now imagine how long it would take to figure out which 35 of 600 are
crashing your program...

And the program literally will never start until you do this.
Factor in the fact that until one meets this problem and figures it out
they may just not even know what to do about it.

Exactly, this is the problem. ACID 6, for example, when I tried the demo, it crashed and burned on the scan and I had to sort through the plugs to find the one to move it temporarily -- it turns out acid hates GTG synths (among many others).. It took me an hour to sort through the mess, indeed. And then when I finally got it up and going and added an instance of CM-101 (one of the most basic synths you can get) it *poof* crashed and disappeared. This is inexcusable for a "pro" level product. What a joke.

This is exactly the problem and you are right, runagate, for being concerned about it. I feel very lucky/fortunate because T2 and FLS are all I need and both of those have great plugin scanning/addition/removal/skipping abilities, and I need nothing else.

[grymmjack]

I've pretty much stopped demoing all the
nice daws and seqs because it takes too long, or isn't possible,
to get them to work with the plug-ins that I have. FL not only doesn't
have this limitation but it will load all but a handful of plug-ins.

I'm glad things are working good for you, but to be honest, after all the threads Iv'e seen regarding Fruity Loops, I wouldn't touch it with a ten foot pole regarding the VST problems Iv'e seen posted. Fruity Loops was never known for smooth VST integration, and not a day goes by that I don't see yet another problem regarding this app. In fact my brother actually gave up on this program regarding it's VST handling. He couldn't take it anymore. Anyway, to each his own. I guess.

This is what I mean. Because FL adheres to the VST specification 100%, and makes no exceptions or guesses/workarounds on it's own as much as other hosts, it takes flak. There is something to be said for the adherence to a spec but then there is also something to be said about "just working" hosts with majority of plugins. Sure, Cubase so far in my experience, has the most success with all things VST -- I have never had a single problem with a plugin crashing Cubase, but I am not willing to succumb to other things I really hate about Cubase just for it's VST implementation. Like I said, T2 has been okay for me so far -- I am very selective/picky about what goes in my c:\vst directory though

I can appreciate the end-user wanting a program to "just work" even if it breaks protocol or specification to "just work" as an end user I don't give a shit either if it adheres to a spec, and I don't give a shit to hear excuses why my favorite plugs aren't working on FLS or if my favorite plugs which work in other hosts but have issues in FLS -- as a user I just want stuff to "just work"

This is a shame though, and I commend the FL team for standing up against the masses for adherence to the specification. I know now why using only the FL official generators are the only way to provide 100% stability too. Still, I use T2 in combination with FL to achieve the best of both things -- T2 has better success with some VST's and I can sit FL into T2 via rewire or VSTi, and enjoy both worlds.

[grymmjack]

the problem isn't hosts, but crap VSTi programmers. Either you just scan & list DLLs (pretty safe, it's what FL does by default) or you open the DLLs to get more details about the plugins (mainly number of in & outs) to sort them better.

This would work.. if some dumb programmers didn't choose to show their dumb 'hello, this is my first plugin' messagebox whenever their DLL is opened, or the usual 'please register' box. In fact, message boxes should be banned from any plugin, a plugin should just not suspend the host at unexpected times. And then there are plugins that just crash when closing the DLL if no instance of the plugin was created.

What's to blame is VSTi programmers and the fact there's no 'quality insurance' VSTi test app from Steinberg. And sometimes the user himself who moves VSTi DLLs manually, or doesn't install them correctly, so that they can't find their associated data files & crash.

The problem is never going to get better for sure either. I wish there was some initiative though, to help us all both developers and end-users alike - a seal of VST standard adherence or something - to put on the box/ads/interfaces/manual to let us know for sure that the VST plug complies with the standard entirely.

This would make the whole problem a non-issue. And would force plugs that were out of compliance and broke the specification rules to adhere to them via pressure from public opinion, etc.

I am shocked that no such initiative yet exists or is supported at all, TBH, because it is standards like this that protect and save time and money and frustration. I think you are doing the right thing man, but it's a uphill battle. The VST wrapper in FLS has a bunch of flags/toggles in it which workaround some of the issues so in some ways it's trying to solve the problem of non-standard I guess, but in some ways it could be making it more confusing for end user too.

I've mentioned this before on looptalk and so on about a VST compatibility list/some kind of standard committee and the existence of plugs to 'snoop' on a vst to check for it's adherence to a standard couldn't be that difficult to make? I mean as it is from what I know the scanners look for dll's then look for their 'hook' or whatever to recognize them as plugins, then try to instantiate them and do other snooping (this is why scans can take a while) but plugs that, for instance, read from the registry (such as your own plugs from imageline; wasp, dx10, simsynth) also break other hosts -- whether or not this is part of the 'spec' I don't know, but it's stuff like this that needs to be corrected so that we can all get on with making music already.

The web and it's myriad of protocols has standards and committees and validation tools, why not VST plugins?

[brambos]

This is what I mean. Because FL adheres to the VST specification 100%, and makes no exceptions or guesses/workarounds on it's own as much as other hosts, it takes flak

I secretly admire that stance. If I look at my Host's code it has become so dirty because of all the workarounds I had to implement just to get fiddly SynthEdit plugins to run and still there are plugins that crash it.

However, people always blame the host for crashing, never the plugin developer for misinterpreting the standard. So I fully understand why most host-coders, myself included, try and code around all the quirks our users report.

[grymmjack]

I don't know if the demo's different than the real version, but I found Tracktion took a disappointingly long time, every time, to scan and load up - even with the "quick scan" on. Am I missing something?

I have no experience with other host I could compare to (except Tobybear minihost and few attempts with cubase vst).
But I can tell you a complete scan takes no more than 5 minutes for me for a hundred of vsts, some of theme beeing "huge" (Proteus x, Korg Legacy collection...). Maybe depends of your computer ? Mine is a basic one (HP Pavilion AMD 3000 + 512 Mo).

Not the initial scan, which I expect to take awhile with any host, but each time I open Tracktion 2, it takes about as long as Cubase to open, which I'm a little disappointed with, as I've been thinking about switching to or at least incorporating another host. One that opens immediately, like Sonar, and doesn't have to have a long-winded scan every time. Because Tracktion is designed to be more immediate, with that all-in-one interface, I'm just a little surprised that it's so slow on loading. And at work, I can't get it to open, period; it crashes on the initial scan.

Yes it's what elephant said. Disable scanning on startup -- you don't need to do this with Tracktion since it gives you an option to 'rescan' when you want. The point of scanning on startup is a convenient feature but takes time to do it and with a rescan command it does the same damn thing anyway. That will have you sorted out. I start T2 in 5 seconds. Could never achieve this with Cubase

[grymmjack]

This is what I mean. Because FL adheres to the VST specification 100%, and makes no exceptions or guesses/workarounds on it's own as much as other hosts, it takes flak

I secretly admire that stance. If I look at my Host's code it has become so dirty because of all the workarounds I had to implement just to get fiddly SynthEdit plugins to run and still there are plugins that crash it.

However, people always blame the host for crashing, never the plugin developer for misinterpreting the standard. So I fully understand why most host-coders, myself included, try and code around all the quirks our users report.

Exactly and being a programmer somewhat (web programming != real programming I am told) myself, I can appreciate wholeheartedly how complex and twisty the maze must get for you guys. It's ridiculous IMO that no such VST "standard" is in place, and that hosts are expected to read the minds of all plugin programmers and their intentions and magically just "work" ... And doesn't each and every year get worse and worse? I mean even the deviations must have their own little subtle twitty sub-deviations that cannot possibly be handled properly without adding more conditional logic and taking steps and so forth, thus bloating the code even further and making scanning even more cumbersome/time consuming...I know there is a big gap between API and standard, but when will the madness stop? Same thing happened with MSIE and Netscape while the W3C sat there taking beatings to it's head, and it's still bad but atleast it's getting better. If nothing is ever done, it will only get progressively worse.

[grymmjack]

However, people always blame the host for crashing, never the plugin developer for misinterpreting the standard. So I fully understand why most host-coders, myself included, try and code around all the quirks our users report.

True, but isn't it possible to instantiate a "sandbox" type of thread where it's protected/different memory space or something from the root host and do testing there, it must be because I honestly have never had FLS *poof* on me like others have, and there have been plenty of exceptions caught and handled by FLS in my time using it -- and many of the times even though it may say it is better to quit, I dont and I have no problems and am able to save work, etc.

So some of it is the host I think, even though the plugin is also partially at fault, to *poof* and disappear from simply adding a plugin to ACID is a joke isn't it? I mean to be candid, FLS and ImageLine is much smaller team and less commercial backing than big bad Sony yea? So then WTF? FLS does it, T2 does it, why can't others? And this is part of runagates original bitchment no simple standard process for VST scan/add/delete/ignore/etc.

[tony tony chopper]

The VST wrapper in FLS has a bunch of flags/toggles

it indeed has lots of settings, because it's not me developping the wrapper, but Fred, and he does care about compatibility (and yes there are lots of confusing settings, but that's the tradeoff).
If it was my only choice, there wouldn't be any setting, and plugins that wouldn't work with FL.. would just not work at all. Afterall, if a plugin maker doesn't consider supporting every host, it's not a problem for him and not a problem for us, and as for the user, it's his decision to buy the plugin or not.