so i've been fooling around with this mixer channelstrip (kinda) for quite some time. it has global volume and channel volume, and sends to other channelstrips (effects). but since i have 26 of those (and they all have color slider control) - i'm wondering, are there better solutions than having 26 channelstrips with 14 sliders with color schemes each?

inouts~.pd

sliderc.pd

@esaruoho This could help, I reduced the color resolution so we only have 9 shades of grey and far fewer updates and I also stuck the slider and the color logic in a single abstraction to make things neater. Just run the abstraction with arguments for name and unique ID ([sloid plom1 $0] etc) . Went lazy on label color and just gave it two colors but simple enough to change if desired.
sloid.pd

@esaruoho We could also take this in a more functional way and use a single bit of logic to calculate the colors for all of the sliders;

This may be a considerable improvement depending on how exactly pd handles abstractions. From what I can tell* lesser used bits of a patch slowly get buried in the stack or what ever data structure pd keeps your patch in so a slider you just used will be right at the tips of pd's fingers while one that has not been used in an hour it will have to dig out which takes time. Having all of the abstractions use the same piece of code for the coloring will mean the coloring code will always stay near the top of the stack or what ever data structure pd uses here. But pd may use abstractions like functions (I suspect not) and using any instance of an abstraction may keep the abstraction code close by for other instances. This also reduces how much code pd has to pay attention too, cuts ~3000 objects and their wires from the data path which I suspect will help some.

*I don't actually know how this works, this is just reasoned out through experimentation and playing with the various means pd gives us to time how long a bit of a patch takes to execute, I could be way off. Either way getting your colors from a lookup table like I did will be a decent improvement on speed, saves some math and converting to the numbers to hex.

Edit: think I fixed all the mistakes in the example now...

@oid said:

From what I can tell* lesser used bits of a patch slowly get buried in the stack or what ever data structure pd keeps your patch in so a slider you just used will be right at the tips of pd's fingers while one that has not been used in an hour it will have to dig out which takes time.

That sounds odd to me. An outlet is a pointer of a linked list of pointers to inlets (m_obj.c, line 308 ff.). It would be weird if it's altering the storage structure based on frequency of usage.

You might be seeing some effect from RAM caching on the CPU...?

hjh

@ddw_music Like I said, I don't actually know how this works All I know is that according to the various timer objects more frequently run code executes faster. I suppose that means this effect is architecture and system dependent but likely present on all modernish systems to some degree? My conjecture was partially included to illicit responses from more knowledgeable people.

I am not good enough with pointers yet to make much sense of the pd source, working on it and Miller's videos explaining the innards of pd are a great help but I still get overwhelmed by all those asterisks and figuring out what they all point at.

@oid FWIW I tested the performance of banging one instance of a clone vs banging (randomly) all of them. Results were inconsistent (within margin of error).

test-unused.pd
random-abs.pd

hjh

@ddw_music I think the effect I am seeing is maybe caused by simple scheduling on the CPU combined with my test method, my clicking the bang repeatedly kept the scheduler paying attention and then when I left it alone for a bit it was not getting on the CPU as quickly or something like that, putting the CPU governor to performance decreased the effect noticeably. I would have had a picture but I banged an until with nothing to stop it, oh well. So I guess that last idea of mine will only improve things if cutting the object count by ~3000 actually helps and with that I am assuming the loadbang stuff is out of the picture after object creation since with the loadbang logic object count does not drop much.

@oid Hard to say... I don't know the internals either.

It's an educated guess, but I look at it in terms of, how are objects reachable? The target of a connection is reachable from the upstream object's outlet's list of targets. A [receive] is reachable from the list of objects associated with the symbol.

The suggestion is that some of these targets may be, somehow, made harder to access and others made easier. That seems really complex (i.e. breakable) and likely to cause more problems than it solves. I'm guessing that there's no "reachability" path in pd that depends on the object's frequency of access.

I haven't looked deep at the code, but it looks to me like outlets and "bindlists" ([send] / [receive]) both use linked lists, which are O(n) for traversal, insertion and deletion.

For the main question in the thread, I think the most important things will be: 1/ don't push updates through unless the display is really changing (i.e. use [change]); 2/ control the rate of updates ([cyclone/speedlim]); and 3/ if necessary, split the GUI to a separate process.

hjh

@oid said:

@esaruoho This could help, I reduced the color resolution so we only have 9 shades of grey and far fewer updates and I also stuck the slider and the color logic in a single abstraction to make things neater. Just run the abstraction with arguments for name and unique ID ([sloid plom1 $0] etc) . Went lazy on label color and just gave it two colors but simple enough to change if desired.
sloid.pd

hi! i kinda panicked with the complexity of this, but then realized i could just take the colouring logic and replace one [sliderc] with [sliderc2] with only the colouring logic (admittedly, it's not looking as awesome, but it works (i might eventually need to change it to maybe 18 colors instead of 9 colors). and now i can have 16 breathers without the UI grinding to a halt. do you think 18 shades of grey will still work or will that be too much?

thank you very much! i didn't change all sliderc's to this, since the volume ones for the 16 loopers were the ones that were causing the issues, so if i come across more problematic sliders, i'll replace them one by one.

@esaruoho 18 will probably be fine and you can probably even go higher without issue, the main things which makes this more efficient is the lookup table built around the [list store] saving you the math and conversion to hex and the [change] filtering out the duplicate output, The only reason I picked 9 colors was it kept me from having to think much, the 9 shades of gray and the old coloring number system was a zero thought required solution on my part.