turns out the whole "momentary toggle button" doesn't exist as a UI in PD - in [else] there's [button] - but one day I woke up and realized [key], [keyup] can be used to make momentary toggles (as in it reports 1 until it's let go then reports 0) - it works great using keyboard as an input, an overlooked way to get live input into PD

it gets kind of messy with things like note priority or other multiple toggle logic - this one is last keyDown to be easy

you can delete the [outlet] messages - was from an abstraction/subpatch simpleKeyButtons.pd

the helpfile for [text] looks really promising, its not always so easy to deal with newlines and other special characters like slashes

if you have time to try reinstalling rasbian there's https://blokas.io/patchbox-os/ - which is worth it imo - its a version of rasbian already set up for audio and pure data, the wizard is helpful

another thing is to try running the patch headless meaning no UI, you just use the bash shell to tell PD to load the patch, this also helps make things run smooth because it takes CPU to just draw the interface

@EMR66 yeah you can use MME - it sounds the same but it adds a noticeable amount of Lag/delay for times between when you either process live audio in with [adc~] - from what you create or hear in the moment until it comes out of PD - or when interacting with UI (moving sliders, you will notice you hear it change well after you move it), or using a midi keyboard (press a key and instead of feeling like it happens right away, it seems to be delayed, thats lag). It can be offputting when you are intereacting in a way you expect a responce - but in possibly really slow evolving generative audio it might not be that noticeable.

An option to consider is getting an external usb audio DAC which will do asio and has been to me - more reliable for Pure Data to recognize - but in general my advice is the more you just keep working with what you have - the hardware or software - it just seems to settle in, do what you want it to, and become more reliable.

@oid that's a good comprimise & I checked - it can compile with the heavy compiler onto the daisy pod ( [expr] is not in heavy ), - have it latch until it reaches the old value. If only the knobs on the daisy pod were digital encoders instead of potentiometers ..
really hit a wall right away when I got a daisy pod .. say I have an idea I want to put on it - -- it's got four sliders, the daisy pod basically has two sliders & an encoder ... :/ .. I have a couple other "things you can put your PD patch on" and having the layout of the hardware UI already decided makes it feel weird to put a new idea on - at least for me.

Oh ok yeah I clocked that. I mean with enough creativity you can do anything with PD - for example that was some masterclass work with lists to save and recall two states.

You are better off changing your idea and working within what you can make the daisy pod do or see what others can make it do because it's too obscure to ask here. In plugdata you can turn on compile mode and that gives you a better idea of whats going to work and not. Think about it like - there is one push encoder and two pots. And also just give yourself some patience and space because you are learning two different things at once.

The heavy compiler was basically complete for vanilla pd but for objects at like 0.43 or something. We're at 0.54. Nobody really knows without getting in there and just seeing if it will compile a patch or not to see about what it can and can't do except the hero who picked up that abandoned project and is working to maintain it now.

Check out the daisy discord, they hired the sound simulator guy and there's a lot of question asking and answering https://discord.com/invite/ByHBnMtQTR

@fishcrystals said:
'Darwin-amd64-32'

huge apologies - you need ones that say Darwin-arm64-32 - it's so easy to confuse them when they are called amd64-32 (intel mac/x86_64, for non macs this is most computers as well) not Amd

you need Arm - also sometimes called arm64, aarch64, M1, M2

Maybe 0.52-1 was running using Rosetta2 which is emulating Intel. A compiled external has to be for both the operating system and underlying architecture. Intel mac is x64, and M1/M2 is arm64/aarch64.

you can go look at these https://deken.puredata.info/ - you need ones that say 'Darwin-amd64-32' to run built for M1/M2 Macs .. But lets see the mac lore is they let you keep Rosetta for two versions of Mac OS, so for now you can stick with Rosetta2 (and that means install the Intel Mac version of PD and emulate it, at some point they will release like 13.3 or whatever theyre at (I'm still using mojave) and take it away but hopefully by then the externals you need will be compiled (or you can compile them yourself), otherwise stick with Big Sur or whatever you are on to keep Rosetta2 - I really haven't been paying attention.

when the amount of Audio devices gets changed (especially when new ones are added, and I count virtual drivers as hardware) it can get confused about what it is - things like turning monitors on (monitors have frickin sound cards) or connecting bluetooth devices will futz with it.

Pd runs cross platform and almost nobody who develops for it actually uses windows so I just live with having this happen on occasion. Pd's really easy to go change those settings btw - can have dsp running and change the rate. Typically if the device is there it will try and remember but I - maybe once a week end up having to go in and change it. Remember to hit save.

Another tip with windows, once you have all your monitors and sound cards set up to the default you like - reboot the computer once, it will make its best effort to remember all the settings when you do this.

it gets in the weeds - basically you got a problem if your knob isn't a digital encoder which sends things like +1 or -1 to move numbers - typically these also have a push button.

if your knob is a potentiometer/slider/knob/pot like on an electric guitar - these only give discrete values and will Jump like on the left.

if you use one of those like I am on the right - and I apologize for it seeming messy, I'm cleaning up little problems - but the knob is still a potentiometer, so even tho I changed it into something that compares if its going higher or lower it ends up at weird places - so to do it right these needs to be an encoder type of knob - (which I'm simulating by just hitting the 1 and -1, a little surprised acting like an encoder isn't in [knob] yet.)knob-problems-pot-vs-encoder.pd