@ddw_music said:

I also admit some ignorance here and I suspect we are going to enter the clashing worlds of digital and analog, the brutal absolutes of the digital world are alien to my analog sensibilities where we can just ballpark it and generally get closer to the real world result than the math would get us and get there in a fraction of the time (talking circuit design and the like here, not physics). And like you I am not 100% certain what is meant by warble tone, I based my answer on what was likely to kill a speaker which assumes the salesman that scolded jameslo had a clue.

One of the sines is too low to be audible

How does the amplifier and speaker know what is audible? We can hear the tremolo effect of this beating so the speaker has to be moving at that rate and those tones we hear as tones are moving on top of that beating, the 4hz looks sort of like a carrier frequency as far as the speaker is concerned. Beat frequencies can cause large extension to the point of over extension (voice coil pops out of the gap) and sustained beat frequencies of these low frequency sorts can cause heat to build up in coil faster than it can dissipate it leading to warping. Getting a good strong beat frequency going and feeding it into a speaker with decent extension will let you see that beat frequency, change one oscillator to half or double the frequency of the other so there is no beating and it will barely move, just a nice even tremble. This of course is dependent on the frequency characteristics of the entire setup but generally if you get one of those beat frequencies going that you can feel than you will be able to see it in the speakers movement.

Beating can be produced from any waves, not just sines.

@jameslo From what I understand a warble tone is a beat frequency and an amplifier which does not limit low frequencies can kill speakers because outside of sub woofers most speakers can not deal with the sort of extension required by those frequencies for very long. A midrange or fullrange speaker can not reproduce a 4hz waveform directly but can reproduce it as a beat frequency, in most music a beat frequency is a fairly brief thing and causes little grief to a speaker but when they are maintained or exploited they quickly cause either over extension or heat build up in the coil (depends on the speaker) which are not good things for speakers. It is really easy to kill a speaker if you know how, even if it is rated for 120 watts and is only being driven by 10.

@Il-pleut That looks great and I was even able to find a copy with a sane price, most copies were $100-250 and there were not many to choose from. I do like Malagasy music quite a bit, especially D'Gary whose guitar playing is infuriatingly difficult to figure out. I have really been trying hard to not buy more books and you are making that difficult, already got me to buy two and there are a few which I am rather tempted by.

@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.

@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.

@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.

@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...

@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 Generally I attach a symbol to the UI element's name and then run them to a [send] which sends to a single [netsend] but that is mostly because the [send] tends to be useful elsewhere in the UI, it could be replaced with the [netsend] itself. All of your label updates and the like can be handled through this.

The else channelstrip and other such externals will probably not help much here since your issue is that you are running out of time between blocks and they will only help during the DSP block, you still have all those UI updates to do which are where you are running into problems. It is a lot of work to separate the UI and the DSP on a large project and it sucks to do but sometimes it needs to be done but maybe someone else will have a simpler solution for you. There could be other/better ways to improve things, hard to say without seeing your entire patch but I assume your channel strip is an abstraction so it would be much work to test it on just that one abstraction to see what happens.

@esaruoho If you are trying to save CPU than I would just separate UI and DSP, run the UI in its own instance of PD and DSP in another, communicate between them with [netsed]/[netreceive], there comes a time in PD when you just have to either separate UI and DSP or sacrifice. Beyond that it is difficult to say, I do not know what your needs are and what sacrifices are acceptable. What are your requirements? I can optimize these patches in a dozen different ways but I have no idea if any of them will meet your needs since I do not know what your needs are or even why you are trying to change things beyond a vague notion of there possibly being something better.