So, I'm trying to figure out if there's prior art out there that would let me connect an iPad to a Mac and use it to control PD sliders etc? Has anyone accomplished this? I'd prefer to do a cable connection so the iPad doesn't run out of juice. Do I need a 3rd party app or is this a no-go/deadend?

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

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

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

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

@oid said:

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

ok. i have heard about this UI DSP separation. so.. is it a case of every single slider for instance needs to do a [netsend] to some other abstraction that only does DSP? or have two separate patches altogether, one for UI and one for DSP? sorry, i'm really vague on this.

So, my main painpoints with the current channelstrip is that when I set up 16 "LFOs" to "breathe" up and down the volume slider (which also has slider-color-changing while it is moved from 0 to 1) - when i have more than 4 of these LFO counters cycling from 0...1 on the channelstrips, all sliders stop updating. it might be 4, 8 or 12, but by the time i try to get all 16 of the looper volumes to cycle from 0...1 (my "breather" has a setup of cycling from "min-max every 2 seconds" to "min-max every 60 seconds") -- and that to me makes me think that the UI is not as optimized as possible.

i keep hearing that ELSE library supposedly has some larger crossmatrix/channelstrip that i could use, but i have not looked at it.

so ideally i'd prefer to take the channelstrip even further, i.e. have all effect sends be modulatable (well, that word where the effects have LFO modulation) so i could have even larger more complex things going on where the channelstrips that receive audio from loopers, are sent to specific sends like reverbs, delays and so on. this kind of larger modulation on all parameters would be really useful.

the way the channelstrip is built is that the dwL and dwR go to a separate [diskwrite~] abstraction which i use to record audio. the "p" (and p1-p8) defines that any channelstrip that has p enabled, is sending to all the other loopers - so in that case, any audio that goes to a channelstrip, can be sampled into the 64kb loopers (16 of them).

also i have thechannelstrip labels (i.e. volume slider name) dynamically written to, so i can always have them easily understandable / informative.
here's the "init state". i use bunches and bunches of loadbang -> message -> senders to get them to a specific state. .

one thing i've been toying around as an idea is to incorporate highpass and lowpass filters to the channelstrips, and EQ. but i haven't figured out how to solve the EQ issue so that the single band peak EQ could be incorporated into such a small formfactor ( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).

i also have for the 16 channelstrip looper instances, BCR2000 + BCF2000 volume slider control and so on. but i'm willing to take the whole setup "to the dock" and rewrite it, if i could be sure that it will be lighter on the cpu..

so yeah, i do only have a vague notion of "maybe it could be better, i'm not sure?".. but i've not yet seen much netsend + netreceive stuff so i'm not entirely familiar how it could be done and how much i need to rewrite (i.e. does everything need to be netsend+netreceived with a complete split of DSP and UI, to reap the benefits, or can i just try it with the 16 loopers and see what happens?

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

ok THIS was good. so i removed 16 instances of [else/detect~ hz] and their [else/numbox~] and immediately experienced a jump from 85% CPU on Pd to 23%-35%..
i also realized i didn't really need that info anyway so.. i've lost nothing and gained a lot of cpu cycles.

@seb-harmonik.ar said:

Actually the process that is 70% CPU is the GUI process, the lowercase letter one is the one doing the audio
That 70% is probably just from drawing a lot of GUI stuff

that's very interesting! so it seems like my best choice would be to start looking at optimizing the amount of GOP stuff i have, as my GUI for the main script is pretty busy.

ok looks like just simply dumping the [else/spectrograph~] (the large pink one), resulted in a massive drop

EDIT: just noticed one interesting thing. whichever part of the script i'm in (lower part or top part), has a massive effect on CPU usage. it's the one with more GOPs (the mixer strips) that ramps Pd up to 80% or more. so now i gotta figure out how to start reducing the GUI load.

hi, i had a really simple 16 array replay system that uses [tabplay~] to play the contents. i've mapped the pc keyboard to have zxcvbnmqwertyuio or so to trigger the 16 arrays.
but now i'm starting to think, having a pitchbend to warble around the playback would be pretty fun. i take it [tabplay~] is too limited for that, but what's the go-to for having pitchbend instead of single-shot with single-frequency playback?