Different sets of modules/same developer naming conventions

[AScustomWorks]

As far as I understand the quick way is to just use a different slug for every set, for example:

 Tom&GerryTools, Tom&GerryOSC, Tom&GerryFX etc.

But this approach is cluttering the module developers list menu already, not important when typing a search but a bit annoying when looking into developers list.

I noticed if we keep the same name slug at compile time, then manually change the name of the dist folder(to avoid replacing the first module set), any extra module set will appear under the same developer name (first set, second set, etc.). Version info may be confusing for users though.

Would this be the proper approach or there's another method contemplated?

Thanks!

[AndrewBelt]

It's recommended to use the CompanyName-PluginName pattern for slugs. https://vcvrack.com/manual/PluginDevelopmentTutorial.html under Naming.

I don't know if I'd call more plugins "clutter", it's just what happens with a popular platform, along with a database that attempts to collect every plugin.

I have no idea what you're talking about with changing the "name of the dist folder"

Also, who is using an ampersand in their slug?

[AScustomWorks]

1.- Right about the "clutter", I guess I need to get rid of MY clutter hehe

2. -About changing the folder name, I made that to be able to test a new set of modules without changing the slug and without removing my old set (at testing stage, I know, lazy!) that's how I found out both sets appear under my name, and this prompted the question as it would be a way to keep things tidy. But I'll adhere to the recommended way, no problem ;)

3.- Nobody yet I hope hehe, it was just for the example.

[AndrewBelt]

1. You only have one entry "AS". What do you mean?
2. So you want to have a plugin "AS", as well as a plugin "AS-testing" or something in Rack at the same time? Simple answer: change the slug in the Makefile, make clean, make dist
3. I see. Only alphanumeric plus -_ are allowed in slugs. They will begin to be hard requirements later.

[wizardishungry]

1. Yes, slug should be globally unique. I don't believe the slug is exposed to end users.
2. The first string argument to createModel is the manufacturer name that shows up as a top level heading in the browser. Multiple plugins from a single vendor can use the same value to ensure all their plugins are under the same top level heading. (I do this because one of my plugins contains GPL code.)

[AScustomWorks]

Hi Jon, and yes, that's what I was aiming for but didn't explain correctly, thanks a lot!.

I'll leave an example as a guide, please correct me if something is wrong with this approach (tested already and is working as expected):

Same dev slugs: SLUG = XYZ (first module set ) SLUG = XYZ-SET-2 (second module set) That's for each module set, and it gives 2 separate plugins to install.

Then, to keep both module sets under the same top level heading ("XYZ" in this case): On the first module set(XYZ), manufacturer name is XYZ:

p->addModel(createModel<MyModuleWidget>("XYZ", "MyModule", "My Module", BLANK_TAG));

On the second module set (XYZ-SET-2) manufacturer name is again XYZ:

p->addModel(createModel<Set2Widget>("XYZ", "Set2Module", "Set 2 Module", BLANK_TAG));

The top level heading ends up like this: XYZ: -My Module -Set 2 Module

Now I wonder if users could be confused by not seeing "XYZ-SET-2" at the top level heading, can't win every time hehe.

[wizardishungry]

I'd consider putting the set name in the model createModel call: "XYZ", "[SET-2] FunkyVCO".