Win VSTs

[spamatica]

We have several kinds of VSTs listed in various places in MusE,
Wine VSTs, Native VSTs, Linux VST, VSTs, etc.

This probably stems from the fact that we had (have) internal detection of DSSI-VST plugins.

But, DSSI-VST is long dead and I don't see us getting any replacement support for Wine plugins any time soon. And I'm definitely not sure we should, there are already plenty of projects trying to convert Wine based VSTs into VST or LV2 plugins.

I'm of course bringing this up because it is confusing, it's not the least evident in the Settings dialog for plugins where we have VST and Linux VST. I'm not sure if they end up being used for the same thing but in my mind we should just call it VST everywhere and removing any confusion.

What do you guys say?

[terminator356]

Actually the name 'Native VST' and 'Linux VST' are exactly the same thing.
As time went on I sort of mixed the two names.
Should pick one and stick with it. Fix any confusion there.

I think one problem is that each type needs its own folder.
One cannot really mix all their Win and Linux VSTs in one folder.
DSSI-VST may be dead to many but I just got it working.
So I would like to keep that option open if possible.

In Settings Plugin Paths there is LinuxVST and VST.
I don't think we could join them. They need to be in different folders. It's dll vs. so.
And the DSSI-VSTs are handled by the DSSI folder.
So I think we're OK there actually...

[terminator356]

About the plugin cache file named 'vst_plugins.scan':
Yeah, that one is a bit superfluous.
I already have linux_vst_plugins.scan, and the dssi_plugins.scan takes care of dss-vst.
So why the vst_plugins.scan?
Well, I was just being thorough, it was to potentially hold vsts scanned by
some future built-in Win vst support - such as our dead FST support module.
But for now, vst_plugins.scan ends up being blank always.

Tip about my scanner: I added a neat trick I felt would be good:
The scanner will pick up any plugin type found anywhere in all the given folder paths.
The idea was that sometimes people accidentally drop one plugin type into
a different plugin type's folder.
My scanner will find it and show it for the user, helping them find 'lost' plugins.
Thus if there's say, a Win vst hiding in a ladspa folder, the scanner will find it.
This is not to say that users should mix types, but if it happens, the scanner will happily find it !
This is also not to say that we could unify all folder paths into one, no, there must be different paths
to begin with so that the scanner has somewhere(s) to scan.

[spamatica]

Den lör 15 feb. 2020 kl 18:00 skrev Tim <[email protected]>:

Actually the name 'Native VST' and 'Linux VST' are exactly the same thing. As time went on I sort of mixed the two names. Should pick one and stick with it. Fix any confusion there.

Yeah, I understood it was likely the same and that was part of my point.

I think one problem is that each type needs its own folder. One cannot really mix all their Win and Linux VSTs in one folder. DSSI-VST may be dead to many but I just got it working. So I would like to keep that option open if possible.

Really? As I remember there was a change in the kernel regarding futexes that caused it to stop working, futexes started working or you found another syncronization mechanism?

In Settings Plugin Paths there is LinuxVST and VST. I don't think we could join them. They need to be in different folders. It's dll vs. so. And the DSSI-VSTs are handled by the DSSI folder. So I think we're OK there actually...

DSSI apart, all the other "proxy"-plugins that I know of (airwave, LinVst) create a .so wrapper for each DLL, so to MusE they appear as a native plugin. Hmm, I realize I'm a bit confused, I thought the VST was for DSSI-VST but as you say it's handled by DSSI, and we don't support DLLs directly. Then I don't see what the VST folder would contain?

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/30/comments/1?email_source=notifications&email_token=ABCFAN2OG2HPLYZVJ263QNDRDANRRA5CNFSM4KVZETH2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAVV6Y>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFAN3WCIHRFBBUSCO4Q6TRDANRRANCNFSM4KVZETHQ> .

[terminator356]

Oops. No I'm confused and blind.
I looked in settings and didn't see a VST path. Hence my previous comment.
Now I looked again and yeah, we have one.
So it is rather superfluous as per my previous comment:

Well, I was just being thorough, it was to potentially hold vsts scanned by
some future built-in Win vst support - such as our dead FST support module.

I suppose we could hide it. Nothing will go there for the forseeable future.
Go ahead if you wish.

[terminator356]

Wait... Not so easy.
That VST tab is actually used.
I copy the paths to the VST_PATH environment variable.
Whereupon anything that would use VST_PATH has a place to search.
So the DSSI_VST support uses that.

And yeah, I forgot. You are right - all those xruns caused by the kernel futexes.

[Sigh]... Lemme think about this.
I suppose it would mean we'd have to remove all dss-vst support...
Still, I wanted to keep the door open in case we ever added built-in Win vst support of some kind.
There are options.
And... soon we may have built-in VST3 support !
Thus we'd need a VST path list all over again.
Hmm....

[terminator356]

STOP THE PRESSES!
DSSI-VST is now working 100% no errors, no xruns.
Recall I mentioned I got dssi-vst running but with errors/xruns and found your old post (scroll down):
https://github.com/muse-sequencer/muse/issues/681

Well, something has changed, I believe it is this:
https://lkml.org/lkml/2019/7/30/1399
https://lkml.org/lkml/2019/7/30/1398

Here I am after an hour, playing, using dssi-vst, notice just a couple of normal spurious xruns
and NO continuous stream of errors:

[terminator356]

Based on that and some review of things, and how your changes work now,
I think having the single VST paths tab is good. I think your changes are good.

At the moment, the dssi-vst synths show up under the dssi popup menu.
Meanwhile Linux vsts show up under the new unified vst popup menu.
And they have 'VST' appended to their names.
This is good! dssi-vst is kept out of the way.

I would like to append your changes with a wee addition,
possibly this is where you were already headed:
By virtue of the fact that my config file still contains a pluginVstPathList tag,
pointing to where my win 32 vsts are, by luck the program found my plugins.
But those paths are not shown in the new VST tab.
I would like to merge the contents of the two path lists so that the VST tab points
to all VSTs - be they dssi-vst, or Linux vst, or even vst3 later.
The theory being: When we pass all those paths through dssi-vst (via VST_PATH env var),
dssi-vst will look only for *.dll files, never *.so files. Meanwhile when we pass the paths
through our Linux vst code, it will look only for *.so files, never *.dll files.
So even with something like LinVST where we have both an *.so file and a *.dll file,
each should in theory be picked up and should show up in it's respective
dssi-vst or unified vst popup menu.
The user need not even know about dssi-vst since there's just one VST tab now.
I did previously mention my scanner picks up all plugin types no matter where they are.
That's good to have going for us.

In short, I feel that I could fully concur with these efforts and now think they could work unified.
Thanks!

[spamatica]

Den mån 17 feb. 2020 kl 00:35 skrev Tim <[email protected]>:

Based on that and some review of things, and how your changes work now, I think having the single VST paths tab is good. I think your changes are good. At the moment, the dssi-vst synths show up under the dssi popup menu. Meanwhile Linux vsts show up under the new unified vst popup menu. And they have 'VST' appended to their names. This is *good*! dssi-vst is kept out of the way.

Awesome that dssi-vst started to work again, I need to check it out. For whatever reason I found it to perform better on some plugins compared to my current choice, airwave. Maybe those futex thingies are really high performance.. So I need to try it again.

I would like to append your changes with a wee addition, possibly this is where you were already headed: By virtue of the fact that my config file still contains a pluginVstPathList tag, pointing to where my win 32 vsts are, by luck the program found my plugins. But those paths are not shown in the new VST tab. I would like to merge the contents of the two path lists so that the VST tab points to *all* VSTs - be they dssi-vst, or Linux vst, or even vst3 later.

I think I'm following what you are aiming for, sure go nuts, all I wanted was to clarify and unify VST usage. If it (by magic) means that dssi-vst will find it's plugins too that sounds great. We can bring back the filter in the plugin dialog too, I'd prefer to rename it to DSSI VST instead of Wine VST though, as it will only contain plugins from dssi-vst. The theory being: When we pass all those paths through dssi-vst (via

…

VST_PATH env var), dssi-vst will look only for *.dll files, never *.so files. Meanwhile when we pass the paths through our Linux vst code, it will look only for *.so files, never *.dll files. So even with something like LinVST where we have *both* an *.so file and a *.dll file, each should in theory be picked up and should show up in it's respective dssi-vst or unified vst popup menu. The user need not even know about dssi-vst since there's just one VST tab now. I did previously mention my scanner picks up all plugin types no matter where they are. That's good to have going for us. In short, I feel that I could fully concur with these efforts and now think they could work unified. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/orgs/muse-sequencer/teams/musedevteam/discussions/30/comments/7?email_source=notifications&email_token=ABCFAN5TPBEHUAGMKU2NBEDRDHEPVA5CNFSM4KVZETH2YY3PNVWWK3TUL52HS4DFWNCGS43DOVZXG2LPNZIG643UKJSXA3DZVJRW63LNMVXHIX3JMTHAAAVWY4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCFANYLRTRK6VOYWMGGPDTRDHEPVANCNFSM4KVZETHQ> .

[terminator356]

@spamatica I tried. Really I tried. I got halfway through merging and
unifying Linux vst paths and dssi-vst paths, and then realized it cannot be done.
They really need to be separate path lists. So I had to do a partial revert to your changes.
But I improved things a bit with text description labels on the path tabs (*.dll vs. *.so etc).
The tabs are now called 'DSS VST' and 'Linux VST'.

The reason we cannot unify is that user must be able to tell dssi-vst or linux vst NOT to
include a particular directory.
If we lump the two path lists together, dssi-vst and linux vst are BOTH forced to scan
the entire list of paths. User might not want that.

In fact, if and when we gain VST3 support there will need to be a third VST tab for it !
Each plugin system uses its own environment variables, installation paths etc.
They need to be kept separate. I can almost unify them, but no, I could not make it work.

If you are looking at QTractor and wondering why it has only one VST path list, I tested it,
and as much as I can see it stumbled when dssi-vst and Linux vst plugins are both installed.
It has no separate VST path lists for each type and choked on a test I did.
And I see that QTractor is already building VST3 support.
I hope it's not going to lump all the VST types into one VST path list. I can't see that working well.

[kybos]

I think it's perfectly OK this way too, now that the labels/descriptions clearly state what is meant.