Suggestions for better metadata

[falkTX]

1. plugin author is missing (it is defined as http://github.com/mikeoliphant but what this then maps to is not
2. plugin brand (via mod:brand is missing), to show alternative "author" field if needed on mod-ui (not always the same as author name, could be a team or org)
3. lv2 category should be simulator
4. tag audio ports as mono with the same URI, so hosts know they are related to each other
5. hardRTCapable property is wrong, as the NAM core engine does buffer resizes during RT

I would love to add some basic modgui, even better if it was based on the NAM plugin resources. But compared to that one this plugin is missing the EQ controls. any plans on adding those?

[mikeoliphant]

I would love to add some basic modgui, even better if it was based on the NAM plugin resources. But compared to that one this plugin is missing the EQ controls. any plans on adding those?

My intent is to keep this plugin very simple. Everyone has their own opinion about how EQ controls should work, so I think that is better left to other plugins. I don't include IR loading for the same reason.

[mikeoliphant]

• plugin brand (via mod:brand is missing), to show alternative "author" field if needed on mod-ui (not always the same as author name, could be a team or org)

Not sure what I would put as a "brand"...

• tag audio ports as mono with the same URI, so hosts know they are related to each other

I don't understand what you mean here. Can you point me at an example that does it that way?

[mikeoliphant]

@falkTX I switched the mod:fileTypes to "nam" because some DAWs (Reaper, at least) treat it as the file extension to use. Does that cause a problem for the MOD stuff?

[falkTX]

@falkTX I switched the mod:fileTypes to "nam" because some DAWs (Reaper, at least) treat it as the file extension to use. Does that cause a problem for the MOD stuff?

yes, this is a custom property that is not a file extension but a file type. see https://moddevices.github.io/mod-sdk/mod/#fileTypes for older ones

"nammodel" is the filetype chosen as per https://github.com/moddevices/mod-ui/commit/e2b40cc265f98609bdb73e13fec88be19894761b and makes more sense, this "fileType" property is not to describe the extensions but the actual "type" of file the plugin can load. that is why "audioloop" is a type, and can be a wide array of audio files.

[falkTX]

• tag audio ports as mono with the same URI, so hosts know they are related to each other

I don't understand what you mean here. Can you point me at an example that does it that way?

forgot to reply to this one, sorry.

I meant to use https://lv2plug.in/ns/ext/port-groups to set both input and output audio ports as mono, tagged with the same URI. That will add information to hosts that these ports are related (not that hosts use it this info much, but more metadata is always useful, also for posterity) Should I send a PR for this?

[falkTX]

note that at the moment there is no way for lv2 plugins using file/path parameters to specify what kind of file that parameter is meant to use. that is why for MOD I decided to just roll a custom property. there was a recent query about it on the LV2 mailing list, but no replies to it http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2023-April/002106.html

[mikeoliphant]

"nammodel" is the filetype chosen as per moddevices/mod-ui@e2b40cc and makes more sense

While it might make more sense, it results in a bad user experience in Reaper - a file dialog opens for "*.nammodel" (which, given that they have no idea what a "nammodel" is, seems like not unreasonable behavior).

[falkTX]

"nammodel" is the filetype chosen as per moddevices/mod-ui@e2b40cc and makes more sense

While it might make more sense, it results in a bad user experience in Reaper - a file dialog opens for "*.nammodel" (which, given that they have no idea what a "nammodel" is, seems like not unreasonable behavior).

this sounds completely wrong. reaper must not be reading properties it has no understanding of. this is http://moddevices.com/ns/mod#fileTypes, there is no way that reaper is following the spec. something is seriously wrong the with reaper implementation here. as far as I know it doesnt even support these kind of parameters... so what is going on..?

EDIT: I can add "aidadspmodel" and "nammodel" to the MOD spec, so the file extensions to use become defined. but anyhow this all this weird to me, whatever reaper is doing is just not right

[mikeoliphant]

there was a recent query about it on the LV2 mailing list, but no replies to it http://lists.lv2plug.in/pipermail/devel-lv2plug.in/2023-April/002106.html

My guess is that waiting for official LV2 action is probably futile - that mailing list seems pretty dead.

as far as I know it doesnt even support these kind of parameters... so what is going on..?

They finally added atom:Path support in pre-release versions. My guess is it will be out officially soon:

https://forum.cockos.com/showthread.php?t=279764

[mikeoliphant]

I meant to use https://lv2plug.in/ns/ext/port-groups to set both input and output audio ports as mono, tagged with the same URI. That will add information to hosts that these ports are related (not that hosts use it this info much, but more metadata is always useful, also for posterity) Should I send a PR for this?

Sure - that would be great.

[falkTX]

as far as I know it doesnt even support these kind of parameters... so what is going on..?

They finally added atom:Path support in pre-release versions. My guess is it will be out officially soon:

https://forum.cockos.com/showthread.php?t=279764

ah that is cool to see! do you have an account in their forums or a way to contact the author? we should tell them that there is no spec for file types or extensions on lv2 yet, so file browser dialogs are really meant to apply no extension/mime-type filters at all.

on LV2 yeah, quite some folks still interested on a fully free plugin spec moved to clap. but clap not supporting ui/dsp separation by design makes it unsuitable for projects like MOD, pipedal, zynthian and others like these.

[mikeoliphant]

To be honest, I'm a bit surprised (and pleased) that they added support for Path parameters at all, so I'm hesitant to rock the boat if I don't have to.

I get that it is non-ideal, but if we switched "nammodel" to "nam" on the MOD end, everything would just work. You've already got types like "sf2", so it isn't that different...

Going forward, maybe it would make sense to add optional file extensions to the MOD LV2 spec?

[falkTX]

I get that it is non-ideal, but if we switched "nammodel" to "nam" on the MOD end, everything would just work. You've already got types like "sf2", so it isn't that different...

sf2 is a bit different because of copyright reasons, we cant legally call it soundfonts. and the sf2 type allows unofficial sf3 files

for nam I really do not want to change it to purely "nam" as it feels wrong on a technical level. I dislike the idea of a file type being the same as a plugin type, as if they cannot be used anywhere else.. if another plugin is made that is able to load nam models (say a new plugin that loads both aidax/rtneural and nam stuff), then "nam" as file type that it loads seems wrong. the nam plugin could also maybe someday load other types, in case the LSTM based models end up with a different extension for example.

on a technical level it is wrong to just set things because of a tiny bug somewhere else. the reaper version with the bug is still experimental/beta state, for sure it will still be tweaked. and who knows if their custom ttl parser even ignores the mod file type property if we just change the order of the properties. it is surely non-standard behaviour.

so for now unless there is a very good reason, "nammodel" seems the most appropriate string to use as type.

Going forward, maybe it would make sense to add optional file extensions to the MOD LV2 spec?

yes, I even already started the code for it https://github.com/moddevices/mod-ui/blob/master/utils/utils_lilv.cpp#L1009 it ended up not being needed (so far) so I didnt finish on the python webserver side. plus it would be odd to implement on the MOD built-in file manager side, which for now has no concept at all of lv2.

[rominator1983]

Just building it myself with the change to 'nammodel' until you sorted that out. And yes. Waiting for a mod GUI patiently. Until then the mod stock GUI for "unsupported" lv2 plugins will have to do since there are not that much parameters anyway. I'm with @mikeoliphant on the IR and EQ part. Though for MOD owners a more complete plugin would of course be preferable. Is there something I might help you with? Is one of you already doing the GUI? Is there some resource on how this works? I would just go ahead and copy stuff from https://github.com/moddevices/mod-cabsim-IR-loader/tree/master and use different pngs/layout for the additional knob.

[mikeoliphant]

on a technical level it is wrong to just set things because of a tiny bug somewhere else. the reaper version with the bug is still experimental/beta state, for sure it will still be tweaked

At the end of the day, I'd just like to see it working. As the owner of the LV2 extension they are using, you may want to weigh in on that pre-release thread. I suspect that feature will drop in the next official release, and they release frequently.

[falkTX]

on a technical level it is wrong to just set things because of a tiny bug somewhere else. the reaper version with the bug is still experimental/beta state, for sure it will still be tweaked

At the end of the day, I'd just like to see it working. As the owner of the LV2 extension they are using, you may want to weigh in on that pre-release thread. I suspect that feature will drop in the next official release, and they release frequently.

I very much avoid creating any new online accounts, and am actually slowly deleting the ones I still have. Unless 100% absolutely required (say, necessary for work/job) I skip on making any new accounts. Hope you understand.

And I dont see this being a big issue, when reaper shows this odd behaviour there is likely more odd stuff happening with other plugins using path parameters too.

Is there something I might help you with? Is one of you already doing the GUI? Is there some resource on how this works?

If we manage to make NAM stuff work on for Dwarf units, I can try to get some modgui going. for trying yourself I recommend checking how abgate works https://github.com/moddevices/mod-lv2-data/tree/abgate-modgui/plugins/abGate.lv2 I did that one somewhat recently, but the gui size was too small compared to others that I ended up not using that one. but still is nice as reference because the CSS is quite clean (I mean compared to others...)

[rominator1983]

ok. that looks doable. might try it. Sorry to take over the thred a bit. anyways keep up the great work both of you!

[mikeoliphant]

And I dont see this being a big issue, when reaper shows this odd behaviour there is likely more odd stuff happening with other plugins using path parameters too.

I use Reaper as my primary DAW. Now that they support Path parameters, I use it as my primary test host for anything other than compatibility.

Correct or not, Reaper's current behavior with "nam" as the fileType is exactly what I want. With "nammodel", I have to switch the file type every time I load a model. I'm also the one who will get the support issues created when others run into this.

I very much avoid creating any new online accounts, and am actually slowly deleting the ones I still have. Unless 100% absolutely required (say, necessary for work/job) I skip on making any new accounts. Hope you understand.

I will post a link to this discussion on that Reaper pre-release thread. Ideally, there is a solution that will allow expected behavior in both MOD and Reaper. As it stands now, I am forced to choose between two incompatible situations - neither one of which I have any control over.

[falkTX]

Correct or not, Reaper's current behavior with "nam" as the fileType is exactly what I want. With "nammodel", I have to switch the file type every time I load a model. I'm also the one who will get the support issues created when others run into this.

I think you are the best to try to find a better way then. does the behaviour still happen if you change the property name, to like lv2:fileType "nam" ; temporarily removing the mod one? I bet there is some way to provide a random property that reaper will just accept blindly as it is doing now.

[mikeoliphant]

I think you are the best to try to find a better way then. does the behaviour still happen if you change the property name, to like lv2:fileType "nam" ; temporarily removing the mod one? I bet there is some way to provide a random property that reaper will just accept blindly as it is doing now.

Reaper ignores "lv2:fileType", as well as "lv2:fileTypes" (which I assume is what it should do).

Another potential solution - if I use mod:fileTypes "nam,nammodel"; it uses both, which effectively works fine. Would that work properly with MOD as well?

[rominator1983]

I made some progress on the mod gui https://github.com/mikeoliphant/neural-amp-modeler-lv2/compare/main...rominator1983:neural-amp-modeler-lv2:main Knobs and selection are working. But it has of course to be styled since at the moment it's just "working" and still using the abgate-images. But now is definitely to late for doing CSS.

I'm still not sure if this should be placed in a separate repository altogether (or mod-plugin-builder?) or in a fork of this repository if its to be used in MOD. Most MOD plugins are referenced as git sub module. A MOD enabled lv2 plugin does still work in other lv2-hosts. Right?

[rominator1983]

Another potential solution - if I use mod:fileTypes "nam,nammodel"; it uses both, which effectively works fine. Would that work properly with MOD as well?

I just tried that on my fork and this worked. But @falkTX will know better if that's a good idea from a MOD point of view.

[falkTX]

Another potential solution - if I use mod:fileTypes "nam,nammodel"; it uses both, which effectively works fine. Would that work properly with MOD as well?

I just tried that on my fork and this worked. But @falkTX will know better if that's a good idea from a MOD point of view.

err how is this possible. I am beginning to think reaper just looked at some plugins, saw the property and implemented it blindly in their own way, causing this breakage.

so while better in a way, it is still technically wrong... my fault I guess for not having the spec at the URL they specify, I dont know how to set that up on top of a wordpress site. if the "mod" URI prefix becomes a valid online resource, it might help to prevent future cases like this. just seems so weird that reaper would just grab random non-lv2 official properties errrr

I'm still not sure if this should be placed in a separate repository altogether (or mod-plugin-builder?) or in a fork of this repository if its to be used in MOD. Most MOD plugins are referenced as git sub module. A MOD enabled lv2 plugin does still work in other lv2-hosts. Right?

depends on what @mikeoliphant prefers. lately for my own plugins I keep the MOD-specific bits in https://github.com/moddevices/mod-lv2-data/, but if a plugin is meant mostly to be used for MOD and is not a generic one I keep them in the repo.

[mikeoliphant]

so while better in a way, it is still technically wrong...

If it works, I'm going to call it a win. I'm happy to change things if/when a better solution comes along.

depends on what @mikeoliphant prefers. lately for my own plugins I keep the MOD-specific bits in https://github.com/moddevices/mod-lv2-data/, but if a plugin is meant mostly to be used for MOD and is not a generic one I keep them in the repo.

I think it makes sense to keep any mod-specific gui stuff separate from this repo.

[falkTX]

so while better in a way, it is still technically wrong...

If it works, I'm going to call it a win. I'm happy to change things if/when a better solution comes along.

not going to question it, I understand the reasoning. just cant say it is a supported thing. happy to be able to move from the subject, into other more relevant things.

[rominator1983]

Ok then no PR for the mod gui. Then I'll go forward with some submodule magic I guess? @falkTX How do you think about a permanent fork with automatic syncing by GitHub instead of git submodules? I find submodules a bit brittle when you think about deleted/moved repos as has been the case with wolfshaper...

I will separate things after I have a working/styled GUI.

@falkTX you mentioned the original resources of NAM. I guess you meant background images of the plugin GUI. Any idea, where I can find those?

[mikeoliphant]

I'm going to close this, as most issues are resolved and it has gotten off-topic.

@falkTX - feel free to open up new issues if there are any outstanding parts of this you think are important.