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

unless I'm mistaken [savestate] requires you to remember to save your patch - if that's the case you can also use a [table] or [array] with save contents ticked,this is usually not a big deal

but I'm a little flakey so I made a way to create and save a textfile in the same folder as the patch that tracks the filenames.

There's a lot of approaches - one thing I really like is to go check out the [else] external - it has objects that can help you just do the thing you want and the Live Electronics Tutorial that comes with it is a really helpful interactive walk through of a lot of topics. You can interact with things, see them and hear them. Because it's a compiled external vs vanilla externals (which are just made out of vanilla objects like [mkmr] or [audiolab] which you should also check out) it's harder to port what you make (you have to install it each time with different types of computers) But it will save you so much time starting out

came up with a naming & storage system for wav files using a text file in the same folder as the pd patch that has some logic to let you know when its missing/hasnt been made yet - so you know to check the wav files in case it would overwrite anything.

just ignore the unfinished recorder I was playing around with, I wanted it to warn about overwriting but it turns out theres a lot of new stuff for checking files in vanilla 0.54. also still not sure about some edge cases like big files, slow computers with it but the text is solid.

be pretty easy to modify this to get a random value based on its size too

/mac rant time - got a 2010 13" macbook pro about 5 years ago because it was an incredible value - (the 13" didn't have the graphics card problems) - I hate it now - its such a brick - but it will never die so I could justify getting a better laptop. the battery life is about 2 hours at best but you can open it up and change it but it still feels like a broken battery

my mom tho decided to go to art school a while ago so I bought her a decked out 2015 15" macbook pro one christmas so she could edit video and look like a cool person (she switched to interior design and ended up working at an SBC but that thing was always a champ at anything) - so jealous of that screen - the 13" is like 30hz 1280x700 - that 2015 mbp is really the best value right now - except the battery is legit glued onto the frame- they replace the whole bottom shell when they fix it at the genius shop - you can buy a repair kit that comes with glue dissolver. Well she was using crappy chargers and it quit charging so either the power part or SMC or the whole thing is broken and it's not worth it to try and fix it - fortunately the newish 16" is finally a decent replacement for it - so merry christmas - she uses it to watch TV when she travels - the audio on that sounds so good, and the over a day long battery life, its just the best laptop because its such a huge amount of tradeoffs to get a laptop right - I kind of wonder if people complain enough about the latency theyll focus in on fixing it. Theyre really deep into their own lore at this point - its annoying - even rosetta 2 - if they follow it then things will smooth out around version 6 and version 12 will be the high point

in summation: dongles

I'm curious tho - pretty sure opening the pd doc for the camomile VST3 with plugdata would fix the midi problem (because theyre both libpd under the hood the midi problem might be with the helper code or the JUCE backend besides the older version of PD/libpd camomile is at) and you can just run plugdata and patch live in reaper as a VST3 - has some extra DAW objects too.

it looks like focusright and motu are in a usb3 dac latency war as well .. I dont own anything with a usb-c port - I got dongles tho

don't feel like you need to let it go -- but think about how to prove this - m2, m1 whatever is aarch64 - everything was recompiled nothing was the same - latency in coreaudio is not low anymore like it was with intel macs helping a lot of people in pd vanilla cant get audio working and fix it to up their delay msec. It's not an intel mac anymore and for example a lot of compiled externals dont work because they need to be compiled for OS+arch. (mac is d-arwin, windows is ms-icrosoft, linux is l)

its not a mac like you think it is, intel mac was a combination of x64_86 processor that said any 32 bit (86) was banned and couldnt run after mojave even tho it can - and openDarwin at the lowest level.

camomile uses libpd and is frozen in an older version of PD right now - the dev for it, going to college, life is too busy to poke this bear - personally I get it - puttin somthing out for free - honestly I dont understand how it even works without being recompiled for darwin aarch64 (even then it would be for like PD 0.50 because the dev is busy with a normal life) -

your best bet is to try and switch to plugdata because it started with camomile but is super up to date - runs as a VST, you can complain and it gets fixed and you can redownload the nightly (which is the most current stable/dev version with all the new fixes) and does all sorts of magic tricks imo

@ddw_music good question - hadn't really thought about why I always find myself going to it (or something like it) even tho I could use PD for everything - it is a lot like an oscilliscope vs a PD as a multimeter for the timestamp (and the one that lights up what channels/systex/mtc are sending/receiving)

but also it's a dedicated tool that I've used for decades that's been reliable vs a programming environment that I have to program - that's just code wiff experience - Its great to visualize what is happening for debugging and acts as a sanity check, PD requires you to program it and could possibly have weird edge cases across itself and the low level midi code it uses in the various operating systems. So they make a great team.

A funny thing I just realized looking at it over on a mac - the version of wine thinks of the mac's core audio roland gm soundfont as though its like the ms one you can connect to - that's why it was so easy to connect and use it like its just a midi port instead of having to summon a AU Vst (it's got near zero latency unlike the windows one too)

@alexandros Only pitchbend uses data1 and data2 for the 14 bit value.

It combines CC and CC+32 for a MSB and LSB value. In midi-ox a CC is Status 176, Data1 is the CC number Data2 is the value

There's a copy of an old 32bit build of wine for mac on winhq so I got lucky, I keep an older macbook pro around that can run 32bit for all the prosumer firewire music gear. >:)

@alexandros the software editor for your device is always the best place to look into (and occasionally they have updates that add functionality or fix things) https://us.novationmusic.com/components

@whale-av toss them up on archive.org like this champ https://archive.org/details/@bubba_jones i bet ill run across it, ive been collecting and looking for old music/synth books/manuals - cheaper hobby than collecting synths, kind of want to look at the back of the BCR manual

@alexandros yeah I'm sure* - I send it to reaper and in reaper tell a knob on a VST to be a 14 bit CC. I was testing the Korg MS-20 VST with the resonance cranked doing a filter sweep to try and hear the stepping... for science

*I'm not sure about hardware like a Behringer B-Control Rotary BCR 2000 - 14 bit is esoteric and was never really used, they went off with MPE which is still pretty fun when patched right - if I had something hardware that does 14 bit midi I'd just open up Midi-OX (it runs great in wine btw, I like how you can set it to show decimal) to see what two CCs its sending on.