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 wrote:

16 "LFOs" to "breathe" up and down the volume slider

How does your modulation LFO look like?
Is the modulator a signal or control-object?
Does it offset or master the fader ?

Did you try what I mentioned in your other thread?
https://forum.pdpatchrepo.info/topic/14291/need-a-simpler-way-to-change-slider-background-color-when-on-and-off/6

If you update the GUI on each block
= SR/64 = 44100 /64=689 times per second,
this is overkill and is going to drag down performance, even if the two parts run asynchronously.
<25 frames per second should be enough for the GUI.

Setting many faders and their colour once in a while should not cause any trouble. Limiting the update rate might be enough to run stable. (see the patch below)

Benefit from separating GUI- and audio-parts across two PD-instances would be, if the GUI is lagging, audio still runs without drop-outs as PD-instances run asynchronous.

Ideally run the PD-instances on different CPU-cores (and audio in higher priority) by setting this in the operating system.

(btw offtopic, to complicate things even further: in case you are not aware of it:
there is also the [pd~] object, which does simple multithreading, splitting patches across the CPU-cores. But the parts are running synchronous.
Running one instance of Pure Data only, without [pd~], everything runs on one core only.)

For real-time audio a synchronous chain between input and output is important.
So no, unless you know what you are doing, don't split audio into several PD-instances.
(but yes, on different cores with [pd~], in case the audio-part runs out of CPU-time and you don't want to increase latency).

Sth like this is what I thought about in the other thread, slowing down GUI-update-rate with [metro] and [snapshot~]
and detaching it from the deterministic chain with [pipe],
while maintaining signal-rate amplitude modulation:

fader-abstraction.pd
slider-guts.pd

(I don't have Vanilla here right now, and doesn't work on web-PurrData,. But should work on Vanilla, if there is no bug!?)
EDIT: changed [pipe 5] and added [change] and set fader properties to "jump on click"

@esaruoho

( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).

number boxes?

popup window?

incorporating tabs into the bpatcher?

alt-dragging a sllider for more resolution than pixels?

@lacuna said:

@esaruoho wrote:

16 "LFOs" to "breathe" up and down the volume slider

How does your modulation LFO look like?
Is the modulator a signal or control-object?
Does it offset or master the fader ?

so this is how it works. when i move the amplitude slider, the toggle toggles on, and the process starts.

and here's what receives it (the plom1s, plom1a and plom1m)

i'm fairly sure this could be done in a better way.

and nope, it doesn't take into consideration "what's always there", that's what the channelstrip global volume is for, i.e. this modifies the "track volume" if you will.

and one slider changes the speed of the counter, and one slider changes the amplitude of the results, i.e. if i put it to max, it'll be 0...1 otherwise it'll be something else.

i hope this sheds some light to this. i'm fairly sure this could be done better and easier.

@lacuna said:

Did you try what I mentioned in your other thread?
https://forum.pdpatchrepo.info/topic/14291/need-a-simpler-way-to-change-slider-background-color-when-on-and-off/6

hi, i tried all two or three different methods i was given for changing slider background colour, but unfortunately every single one ground the UI to a halt, even made it just so sluggish that macOS decided PD had become unresponsive/crashed. so i had to basically load the abstractions and remove the changes.

but, since you sent a different method, i'll try that next!

Benefit from separating GUI- and audio-parts across two PD-instances would be, if the GUI is lagging, audio still runs without drop-outs as PD-instances run asynchronous.

actually, even though GUI is lagging, in my case, the audio is still playing without any issues. I'd have started panicking last year and started reducing "all kinds of stuff" if the GUI-sluggishness affected live audio during a liveperformance.

(btw offtopic, to complicate things even further: in case you are not aware of it:
there is also the [pd~] object, which does simple multithreading, splitting patches across the CPU-cores. But the parts are running synchronous.
Running one instance of Pure Data only, without [pd~], everything runs on one core only.)

if i understand correctly, it might be that an Apple Silicon M1 would be good with multithreaded cores. i'll have to see what [pd~] really does, i.e. can i put content into it and how. this is a lot of new stuff!

Sth like this is what I thought about in the other thread, slowing down GUI-update-rate with [metro] and [snapshot~]
and detaching it from the deterministic chain with [pipe],
while maintaining signal-rate amplitude modulation:

what's so weird is that all these "step with a timer, instead of 100% realtime" solutions, so far, have ground UI/PD to a halt. i don't know what to think! i mean, is it just that there's so many different metronomes for this (like 200+) that it just is too much at one go..

the only thing i can think of is creating a patching logic where if i activate the breather, the colour-changing is halted. maybe that's the solution that would be less flashy GUI-wise, but would keep the app running.

You gave a lot, and I appreciate it, I'll try and have a look as to how I could incorporate them. thanks loads!

@Obineg said:

@esaruoho

( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).
number boxes?
popup window?
incorporating tabs into the bpatcher?
alt-dragging a sllider for more resolution than pixels?

i'm using very visual EQs which just let me draw a peak EQ for each of the loopers, and for my purposes they need to be available, instead of opened and closed with clicks (popup windows). also hiding inside tabs would be problematic.

granted, if i was using numberboxes and sliders instead of this visual peak EQ ( [else/bicoeff] ), they could be incorporated easily into the my 16 looper abstractions.
maybe the solution is to have an [else/circle] and have it be tiny and talk to the bicoeff..

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