How to avoid [instance number] in short name when using bpatcher in M4L ?
If you name a parameter, it will be used as the title of the info window when hovering with the mouse.
But if this parameter is contained in a bpatcher, there is a [...] added after its name. Is there a way to have more control on this name ?
For instance, have "smooth 1", "smooth 2", etc... instead of "smooth", "smooth[1], etc ?
I tried stuff like "smooth#1" but arguments don't seem to be useable to set up the short name.
The solution is to provide custom Info View Titles instead of relying on the copied object name.
Info view titles can be the same for all objects.
A best practice would be to rename all objects and give them proper long names The numbers in brackets are there because you copied objects and can be random if you copied and deleted multiple objects. (You could end up with smooth[6], for example)
However, since these long names must be unique, you still need to use some form of numbering (or make the names distinct in another way). If you don't mind using those proper names in the Info View, then you don't need to use the Info View Title.
In my example, the 4 lanes are actually 4 bpatchers, so the "smooth" float boxes cannot be edited from the main patch.
Am I missing something ?
instead of using 4 copies of same bpatcher,
make 4 unique ones with set names
Set the Info View Title inside the bpatch to "Smooth," and the numbers in brackets will no longer be visible, as the Info View Title overrides the Long names.
You can't number them because you only set the Info View Title once (assuming it is the same bpatcher used four times). I'm not aware of a special syntax to do so.
Since all Smooth objects do the same, that should not be a big problem for the Info View.
"In my example, the 4 lanes are actually 4 bpatchers, so the "smooth" float boxes cannot be edited from the main patch."
you can edit them with view>Parameters
Perhaps it works when you "Embed Patcher in Parent"
@Source Audio :
That would work of course, but using arguments is one of the main strength of bpatchers, so it feels not as elegant and maintainable.
@Rivanni :
Valid for my example, but it was just an example. In many case I'd like to be able to have a different name (but an intentional one) for each instance.
@Double_ug :
Embedding bpatcher does probably allow it indeed. But while working on M4L devices containing bpatchers, I try not freezing devices or embedding bpatchers, because it's easily a mess...
EDIT @Double_ug : Also, I just tried renaming a param contained in a bpatcher using the view>Parameters method....instant crash.
EDIT @Double_ug : managed to rename them this way, without embedding the bpatchers. But had a few crashes.