[ossia-max] parameter in poly~ always adds voice # to parameter's name

[matcham]

if an ossia.parameter is inside a poly~ , voice number is always added at the end of the parameter. (if the model is outside of the poly~)

ossia.parameter myParam
in the voice 1 of a poly becomes ossia.parameter myParam.1

here is an example patch params in poly naming issue.zip

I guess this is an inheritance of how models are auto-renamed inside a poly voice (adding instance number) but should it be the same for parameters ? I don't know if it's a feature or a bug... but in my user-case, that's very annoying !

maybe adding an attribute to enable / disable auto-renaming could be useful in this situation ?

[avilleret]

Yes this is a feature, implemented as specified and designed by users. This feature is there since the beginning, in the age where you couldn't create parameter without a name argument. I agree with you, in you're particular case, it seems weird.

If I remember correctly, the voice number is added explicitely because we firstly rely on abstraction creation order which was not consistent, in some case voice 30 where instanciated before voice 21 and then some user complain about that behaviour.

Adding another option to enable/disable this feature sounds feasable but I don't have much time these days to work on ossia-max.

[jln-]

Yes this is a feature, implemented as specified and designed by users. This feature is there since the beginning, in the age where you couldn't create parameter without a name argument.

Well, not totally sure that's what was designed by users, although most likely poorly stated. Given second point (that we couldn't create a parameter without argument), adding parameters in poly~ indeed introduced duplicatas in the namespace thus the need to automatically adding instance numbers. But implicitly there's no such need if there are no duplicatas.

Adding another option to enable/disable this feature sounds feasable but I don't have much time these days to work on ossia-max.

If someone is to work on this at some point, imho Mathieu's case should be made to work rather than adding an attribute.

[avilleret]

well in fact, it is more a side effect of how a feature has been implemented which is no more compatible with some newer advanced capabilities so let's say it is a bug but fixing it seems a bit tricky (I can elaborate on that feeling but as I said, don't have much time right now :-( ) as a quick fix, you can use a workaround : declare the parameter outside the poly patcher and put a remote inside the poly~.

[matcham]

Well, as it is now possible to create a parameter without argument and set the address afterward, it's easy to give it a name based on voice # . So I would say that this auto-renaming "feature" is not needed anymore. What about just removing it ? :-)

[avilleret]

why not but that would break patcher relying on it but who cares about backward compatibility ?

[matcham]

I actually have at least 6 different versions of ossia-max for different projects, because lots of things have evolved, old bugs fixed, new one introduced... so IMHO : let's go ! Backward compatibility will be more an issue when ossia-max will have reached the package-manager ;-)

[matcham]

(+ that will maybe break old patchers, but it would be very easy to fix)

[avilleret]