Just Back from NAMM and more Tracktion info for you.

[rich_h]

I certainly remember years ago Jules said that the plug-in scan was more in depth than most hosts. I think the upshot was that most hosts check any DLL it finds for the required export functions for a VST, whereas Tracktion also attempts to open the VST as well which is what takes the extra time.

[P.T.]

Yes, that's well and good, but couldn't it store a list of previously scanned vsts in the settings and then just check for new ones well you do subsequent scans?

[Juanjo]

I also kinda dislike the plugin scan process in T2 as it is now (it might very well be the only thing I dislike about T2 mind you)... i can certainly see its advantages, I don't scan at startup, and I always look for new plugins (as opposed to doing a full rescan), but it's still a bit frustrating for me i.e. say you have a few hundred plugs, you betatest more or less often, and you like to be up-to-date with your stuff... this means you have to spend minutes updating the plugin list TOO often for my tastes... I love they way eXT handles this: ultrafast, unobtrusive, and gives all control and responsibility to the user... yet I'm sure this won't happen in Tracktion anytime soon...

But there's a potential workaround that would at least speed things up in most cases:

- FR: Selective plugin scan
Ability to apply the plugin rescan process to single subfolders and/or individual dlls within the defined vst plugin folder(s), and add the results to the existing vstcache

I'd say this should be trivial to implement

[pough]

I've always thought that if people have enough time to come here and voice their complaints, then surely they have enough time to think of a possible improvement.

There's a 24 hour race and I'm stuck at work for the duration. I have enough time to complain, but I'm a 20 minute drive away from my music computer. Also, this scanning issue isn't huge as long as I'm not changing my VST list. Those two hours aren't often an issue and I'd prefer to spend what little time I have actually making music than tracking down a rogue VST or two; probably VSTs that work fine except when being scanned!

I would put this way down on the list of things to deal with, I just can't help wondering what Tracktion is doing to each plugin and why. BTW, my suggestion for possible improvement is to have a less thorough scan as an option.

[Lunch Money]

Well, FWIW, I'm not against the option for a "cursory" scan, either.

On the other hand, that 2 hours isn't much compared to Tracktion allowing a dodgy plug-in that crashes your project in the MIDDLE of tracking when actual musical work has been done. At least you're eating fries and watching TV while waiting, rather than investing that time.

In any event, no doubt 2 hours is abnormal and therefore represents and issue that can be addressed. I've never had it happen here (I keep my VST list fairly lean) but I've heard from more than just pough that it happens. I'd be happy to see those people have shorter scans, whatever it takes.

Greg

[Rock]

It used to take me hours and I never really discoverd why. It just stopped taking so long. Maybe I threw a bad vst plug out or threw out my Tracktion prefs. I really don't know.

[NAD]

FR: Selective plugin scan
Ability to apply the plugin rescan process to single subfolders and/or individual dlls within the defined vst plugin folder(s), and add the results to the existing vstcache

I'd say this should be trivial to implement

Sounds like a good idea.

[Rock]

That way you could test a new plugin on the fly.

[original flipper]

HI

Don't be too hard on T: I have had crashes and lock-ups in both Cubase and Live during scanning - in fact I can't think of many host programs that haven't had issue with certain plugs at one time or another.

How on earth the 2 hour scan took place I don't know - I would never have the patience to wait more than a few minutes before forcing a program to close.

I would say 'strip' the VST folder bare and put them back one at a time.

Flipper.

[Juanjo]

That way you could test a new plugin on the fly.

Exactly!

[Beno]

Beno, do you have any info on this?

"Automation lock to clip"

Midi clips?

Does this fix this problem...?

If I have midi tracks with automation on them and then decide to change the tempo of the song, the automation does not align properly with the midi any longer and cannot be fixed because the spacing between the midi notes has changed and the automation has not.

Sorry must have missed that one before.

I'm sorry to say not quite. Automation lock moves automation when you move a clip manually, but not after a tempo change. It is a slightly different mechanism under the hood so we didn't get this one for free when added the automation lock feature (it was the last thing to be added based on forum feedback on he AES preview). Its on our list for sure and hopefully in the first 3.0 update we will be able to add it.

Ben

[Beno]

Regarding plug-in scan. There are definitely ways to improve it and there are some great ideas in this thread.
Ben

[Integratron]

I don't think the plugin scan takes any longer then other software that does a scan. And with it set to not scan on startup, Tracktion starts up for me in about 5 seconds.

It doesn't really matter what you think. It also doesn't matter what I think, either. What matters is that a scan takes a few minutes for me in FL Studio, energyXT and Cubase; it took over two hours last time Tracktion did one (and about the same time the times before that). So no matter what anyone thinks, two hours is noticeably longer than a few minutes. This is what leads me to believe that Tracktion loads each plugin, invites it in for tea and strumpets, indulges in some sex (straight and otherwise), has a smoke, checks the fridge for a snack, watches a little Letterman, then moves on. I like its style, but I haven't the time to wait for it.

That's the quick scan, BTW. I turned off scan on startup and I weep whenever I think about the fact that there's an option to do a longer scan.

Your mileage may vary.

Isn't it tea and trumpets?
Just curious - how many plugs are you scanning?

[aMUSEd]

Regarding plug-in scan. There are definitely ways to improve it and there are some great ideas in this thread.
Ben

imho The best plugin scans are those that run before the audio engine fully loads so that if a bad plugin causes a crash it doesn't lock up the ASIO drivers or crash the whole app (2 examples I know of that do this are Orion Platinum and Reaper)

On the other hand the fastest and most stable plugin scan I know of overall is in Audiomulch - I just don't know how the dev managed it, it's quite astounding, even the initial scan is only a few seconds and after that startup is almost instant and I've never known it to crash while scanning. Maybe you should commission the dev to work with you.

[Lunch Money]

A cursory scan SHOULDN'T crash while scanning. That's half the problem with it. It'll just let any old plug through. The stability of the scan itself isn't really the problem, it's the stability of the plug-in. A plug-in that makes Tracktion crash during scan will be disabled for the next scan (unless you choose to rescan from scratch again). The 2hr hang doesn't seem to have an elegant solution, which is why the issue should be addressed in general, but a 2-second scan simply is NOT doing a comprehensive job and I wouldn't trust it.

Greg