This is a plea for developers to be more careful about how they tag their modules for searching in the 1.0 browser. At the moment, if I search “filter”, I get 7 modules, while if I search “vcf” I get more than 40 (a couple of which are, as far as I can see, not filters at all). These two search strings should clearly produce identical results.
If I search for “oscil” I get TWO results, while if I search “vco” I get more than 70. That is flatly ridiculous. All oscillators should be tagged with “oscillator.” Not because it’s especially difficult to think of searching “vco” but because the browser should not be a puzzle for the user to solve, not even a little tiny puzzle.
Some users who are new to modular may not know what “vco” means.
On the other hand, I knew I wanted to use Impromptu 4-View, so I searched for “4-” and didn’t find it. Turns out the module says “4-View” on the panel but is actually named “FourView”. Again, the search fails. If the name on the panel is not the same as the registered name, it seems to me the panel name should be added to the searchable tags.
Here’s another cheerful example. I just downloaded a set of modules that, on the Library web page, are listed as PackOne. But there is no PackOne in the browser list. They’re listed under “stoermelder”, which is not a name shown on the Library page.
Is it too much to ask that developers choose one name for their own devices and stick with it?
“VCF” is a tag available in Rack. “Filter” is not (although modules with a “Filter” tag will be automatically changed to “VCF” by plugin::normalizeTag() and the tagAliases database). So when you type “filter” in the search box, you are searching for modules having “filter” somewhere in their name, not their tags.
Similarily for “VCO”. “Oscillator” is remapped to “VCO” by normalizeTag(). You will notice that all modules that appear with “oscil” have “oscillator” in their name.
So this is an issue with Rack. Currently, the Module Browser searches for your query in a string it constructs for each module equal to <plugin brand> <module name> <module slug> <tag1> <tag2> .... For example, VCV VCO-1 would generate the string VCV VCO-2 VCO2 VCO. A solution is to expand tags into all their aliases. The string would become VCV VCO-2 VCO2 VCO oscillator.
This is a different issue. There is currently a three-level hierarchy. A brand (e.g. “VCV”) can have multiple plugins (e.g. “Router”) which can have multiple modules (e.g. “Octal Router”). If the brand of a plugin is not set, it defaults to the plugin’s name. For the example you gave, the brand is stoermelder and the plugin name is PackOne. Currently the VCV Library does not list brands so you won’t see “stoermelder” anywhere on the web app, but this will be changed when the Library web app is overhauled.
Sorry, what about several Vult filters and the JW XYPAD showing up under the “VCO” tag?
If it was done for self oscillation purposes… well… ok I guess… although I’d still rather not have them among all the other oscillaltors and sound generators.
It can be a raw dirty oscillator. I have made videos with this a while ago. If it really bothers people I can remove the tag but I don’t see the big deal.
If you see tags you disagree with, it seems like a request best handled by a friendly note to the individual developers to make your case. Explain why you think the tags could be improved, the use-case, the impact, and maybe they’ll agree. Maybe not.
For example, “hi developer, while I recognize your VCF can function as a VCO in self-oscillating mode, that may not be a common enough use-case to warrant a VCO tag, which has the impact of cluttering search results with VCF’s when users are more interested in VCO’s. I think it would improve the user experience to eliminate the VCO tag for X filters. I think most users would understand that self-oscillating filters could be used as VCO’s and the additional tag is unnecessary.”
Maybe they’d agree, maybe not, but leave it up to them rather than having a third-party enforce a standard. As long as we don’t end up in Omnisphere situation where there’s a million custom tags (which I’m not saying would be the case here - just making a point on the ills of custom tags with lots of developers), I’m good.
Best solution, let’s go with that. ^ The exception is when the tags are just completely arbitrary, but we’ll notice that when submitted to the VCV Library repo.
@jeremy most definitely not a big deal, neither something which really seems to bother people as far as it’s just me
I bought the Vult stuff, love JW modules use the XYpad extensively (haven’t seen anything like it for automation-like behaviour).
I was simply wondering, if it was to be expected to have self oscillating stuff under the VCO tag, as I’ve seen other modules (including the very VCV VCF) not falling under the VCO tag.
Vortico himself just chimed in, says it normal. Perfectly fine by me.
@funkybot Ideally and generally I’m totally for with you. Then, for this particular case I was genuinely curious to hear some “general direction” kind of answer, which I got.
And I also very much agree on what you said about custom tags defined by developers.
On the other side, custom tags “internally” defined by the user would be the only thing I’d use, If I could.
