so, i started with this (using toggles and colouring them with abstractions)

and then ended with this (using sliders and having a colour-sweep on each)

but i still am having issues with just wanting to simplify this stuff further.

this is the sliderc abstraction in use, but it feels so weird having to use so many of them..
any ideas?

Build an abstraction with graph-on-parent around a single fader!?

@lacuna said:

Build an abstraction with graph-on-parent around a single fader!?

im not sure puredata or my laptop will be able to handle using gop for every single fader on this:

that's 14 sliders per inouts~.pd abstraction, and there's 25 of them.
my script basically chokes already when i start using these timed "breathers" on volume control of 16 loopers, they change the 16 looper volume slider color and volume itself, and if i have more than 3 of these modulations on-going, all sliders stop updating.

so if i were to now then add further gop abstractions to the tone of 350 of them (14 sliders * 25 abstractions), i'm sure the sliders and any kind of graphical screen updates would just stop working.

@esaruoho perhaps a multislider would be more efficient? https://forum.pdpatchrepo.info/topic/10756/vanilla-struct-multislider-with-jump-on-click-and-drag If I understand how pd works (maybe?) the multislider only requires pd to keep track of one bounding box instead of 14 and the bounding boxes are the major cause of GUI slowdown in pd. Should be able to add your colors/labels to it without too much effort.

@esaruoho
I see. High speed rate updating GUIs are a bottleneck in Vanilla's performance, but I doubt that GOPs are.
I tried with 476 of those abstractions, and everything runs smoothly.

This is my [pd color]:

The color fade might not look satisfying yet, but [pipe 0], or maybe try [pipe 5] - detatches it from the deterministic chain, it's urge of updating the colour before sth else gets computed down the chain.

As you are using ints exclusively, put the [int] on top, right after the pipe. Also maybe put a [change] right after the [int]. This way there are less frequent updates and less computations.

I really believe that the expensive part of your patch is sth else,
but ultimately you could also try to use [speedlim] (there are several: iem_vanilla, cyclone, maxlib) to further limit the rate (color only, not actual volume changes).

First time I hear about bounding boxes slowing down, so i might be wrong. Also your second example looks fairly clean.

...have been trying to attach

[phasor~ 0.2]
| [bang~]
| |
[snapshot~]

to 28 of those abstractions, and yes, GUI is slowly responding.

You should detach the GUI part completly from the control part with |set(

If you modulate the faders with a signal, let that signal modulate the volumes directly [*~]

and poll the modulation input occasionally with

[loadbang]
|
[1(
|
[metro 60]
|
[snapshot~]
|
[set $1(
|
to fader in

for the GUI part

Fluidly moving images require much slower update rate than audio.
(I didn't look into multislider mentioned by @oid )

@lacuna It was explained fairly well a year or two ago on the mailing list, at least I think it was on the mailing list but I am having trouble finding the right search terms to dig out that post. Best I have found was an older post from 2007, pertinent section excerpted below and the post here

I had started making cross-platform optimisations in Tk itself, just
before Pd Convention 2007, but it's somewhat tricky to speed up some
common cases without also slowing down some other common cases. During Pd
Convention 2004, the late James Tittle had identified that the most
horrible slowdown was due to the least-common-bounding-box algorithm of
Tk's redraw. What I implemented is a dirty-tile algorithm (make a reduced
map of the screen, mark areas that have to be redrawn). It's not that
good: huge speedups are compensated by huge slowdowns in other situations.
If I modify much more of Tk, I could get to a point where individual items
can really express their usage of space in terms of tiles instead of
bounding boxes, so that a diagonal line doesn't take the same number of
tiles as the rectangle that the line is a diagonal of. This could
accelerate the dirty-tile method so that it becomes clearly superior to
the traditional redraw. I believe that it's still easier to modify Tk than
to switch to a different toolkit.

@esaruoho Off topic (a little, but it might help).
On the audio side you could reduce the patching and remove the audio from your abstraction by using cyclone [matrix~]
Messages from control in the abstraction could control just one [matrix~] for the entire audio chain.
The same [send] address for every fader, and the corresponding [receive] address for [matrix~]
The [dump( message also lets you construct a state saving mechanism for control parameters.

I use it for a 64in 64out mixer, with eq on all ins and outs..... so a lot of fader abstractions although my colour changes are only occasional (new mix templates update colours on the GUI and touch screen tablets).
David.