You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When exporting a patch as an LV2 plugin, the lv2:symbol (unique short name) of each inlet and outlet is taken from the MFP object's name. These names are only guaranteed to be unique if the scope is taken into account.
This is a real problem with the @clonescope method, which makes multiple identically-named copies of processors, one per scope.
Currently there's no real way to pass patch initargs to an LV2 plugin, and the inlets/outlets have to be fixed at plugin-save-time so the manifest.ttl can be created properly, so there's not a real use case for loadbang @clonescopes in plugins like there is in regular patches. So this is more a theoretical problem than a practical one until I see a specific use case that breaks.
The text was updated successfully, but these errors were encountered:
When exporting a patch as an LV2 plugin, the lv2:symbol (unique short name) of each inlet and outlet is taken from the MFP object's name. These names are only guaranteed to be unique if the scope is taken into account.
This is a real problem with the
@clonescope
method, which makes multiple identically-named copies of processors, one per scope.Currently there's no real way to pass patch initargs to an LV2 plugin, and the inlets/outlets have to be fixed at plugin-save-time so the manifest.ttl can be created properly, so there's not a real use case for loadbang @clonescopes in plugins like there is in regular patches. So this is more a theoretical problem than a practical one until I see a specific use case that breaks.
The text was updated successfully, but these errors were encountered: