@whale-av That is the same as mine, I just updated list-inter to modern objects. But I think the goal is something along the lines of this:
list-interpolate2.pd

But there are many variations on this and I can't figure a way to effectively/efficiently cover all bases and not quite sure about @mezko's specific needs yet.

Edit: Fixed a couple errors in the patch but not the image.

@mezko It sounds like you are trying to implement a bandpass filter in the message rate to determine which partials should be on and how strong they should be? If so, a bandpass filter on the output of the synth would do the same thing and be simpler, more versatile and give better control over the sweep. Something like this but you probably would not want to use vanilla [bp~] and this would change how you would set the level of each partial but I think the same results could be gotten?

Or am I missing something? If I am missing something, some more details about your additive synth or sharing the patch would probably help.

Edit: it is probably too hot to think, I feel like I am missing something obvious.

@KoaN I have never experienced any midi latency of note with pd, I would expect it has something to do with your setup. Giving some idea of how long of a latency you are talking about, your midi setup and what OS you are on would be very useful if you want assistance in troubleshooting this latency.

@mezko Like this?
list-interpolate.pd

@patricio.tics Putting the array 'delays' ontop of a second array (delaysdummy in this case) will solve the issue, or you can use the place array in last array feature and just have a single array but I just did a quick copy and paste. Mouse events always go to the bottom object so delaysdummy receives the mouse events which are sent to [array get] and then delays is updated.
multislider2.pd

@impression If you go the route of moving the GOP, [iemguts/canvasposition] will be of help, stick one in the subpatches/abstractions to get their location as needed so you don't have to track all the GOP positions manually, something like this:

@impression Dynamic patching can do all you need, [iemguts/canvasdelete] will be of great use and simplify everything, the iemguts library might have other externals which will be of use to you as well. Using [send] and [receive] and their audio counterparts instead of physical connections is nice when practical, lets you just pass the names to the [send]/[send~]/[throw~]s in the abstraction through its arguments. Previous post has some on dynamic patching and there is a good amount about it on the forum.

Moving the GOP could probably work, pd can handle a surprising amount, just stick a [switch~] inside of any abstraction which does audio rate stuff so you can turn it off and be sure to turn off any message rate stuff in the appropriate way when you hide it.

You can show a gop in a gop, what is not working for you?

@atux [bonk~] might work for you. It has been years since I have played with it but if memory serves for a simple source of 3 fairly different sounds like kick, snare, and hihat I did not even have to use the [learn( method, just get it configured right and I was able to use the color temp part of the right outlet and some [moses] to get bangs for each instrument. But I don't really remember the details and can not seem to locate the patch I used it in. The help file is not the greatest but other than the [learn( method it was fairly easy to figure out.

There is also pd-next which is mostly vanilla pd but with color themes and [closebang]/[initbang]. Nice for those that prefer vanilla but don't want to stare at a white screen.
https://forum.pdpatchrepo.info/topic/10943/a-little-pd-mod

@gentleclockdivider Realized I completely missed your point. This behavior is the same as it is with messages.

My guess is that the logic is that it will cause an error in the log window instead of possibly difficult to find problems. Imagine if you had a bunch of [text]s or [value]s or [send]s or what ever all with a common basename and one with just the basename, [v i], [v i1], [v i2] etc and were passing those names to abstractions through a float in their arguments with a [symbol i$1] in the abstraction, passing the escaped dollar argument means you get an error instead of accidentally setting the wrong [v] since it is very unlikely anyone would have an escaped dollar argument in the name of their [v] or what ever. If the symbol just combined with the empty symbol to create [symbol i] things would seem to work or might do something bad depending what your [v]s are used for and you will have no error message to control click on to find the problem, all you would know is that it did not work correctly.