@seb-harmonik-ar ... moonlib/mknob...

Is it just me? I haven't heard noises about this yet. But I couldn't open lots of my patches in the newest PD last night. Some small ones were OK, but any larger ones (with Graph-On-Parent? Colors?) crashed PD instantly with a Core Dump.

Anyway, I rolled back to PD 52 and all was well. Didn't do more research into the cause; rolling back quelled my curiosity. Just mentioning this for future generations.

Thanks David - I'll start trying this troubleshooting/tracing method. When this happened last, I believe it was freezing regardless of which windows were open. I should try again with everything minimized... but it's tricky, cuz it takes a long time (an hour?) for the freezing to commence.

I have a humongous patch that I won't share (it's too big and complicated and messy and undocumented to mean anything). Last night I was running it for an hour or so (two versions, actually, but all my variables are with $0- so they can go simultaneously) and it eventually reached a point where it would just stop all computation for up to twenty(?) seconds. All audio, all GUI, everything froze. Not my computer, though, definitely just PD. "Audio Error" (or whatever shows up next to the DSP on the main window) would turn red when this would happen.

I'm running Linux, and I was not getting any XRuns (which is another hint that it's just PD that's bogging down, not my whole system).

I know this isn't a lot to go on, but have people seen this before? I have some theories: I have large tables being written to, but even if I close them (to ease up on the GUI), it continues to happen. Another thought - I have lots of counters... a long time ago, I tried to put in some checks where, if they got over a certain range, I'd set them back to zero. If I missed some, could that cause PD to freeze? If I was using a simple counter and it got into the millions/billions? Hmm, a billion milliseconds is almost twelve days...

Thanks @oid and @whale-av. I had actually made a similar (but uglier) version of NRPN before I knew about NRPN; some weird powers-of-10 stuff that didn't exactly make for smooth transitions... but it is something to think about. What I'd really like, though, is something where I simply have better than 128 points of distinction on a single controller... especially if I'm, say, scrubbing through a sample - if it's very long at all, it becomes obvious that I can't get halfway between two points. A two-controller method works, but isn't as faux-analog'ly satisfying as being able to nuance a single pot (like I love to do with my guitar pedals).
So I'll probably stick with relative mode and PD-side math (which I've also done before). I was just dreaming that there was some good, potentially non-MIDI hardware interface/protocol that I didn't know about!

Hope no one minds that I'm just jumping on to this month-old conversation... but I have some similar questions.

I was going to ask if anyone has ideas for better-than-128 resolution controllers (ie, not MIDI. HID? MIDI 2.0?). But looking at what @oid said, maybe my best bet is to settle on rotary encoders (giving up on sliders) and use "relative" mode to do the math in PD.

Is that the general consensus? All my ancient nanoKontrols are getting futzy anyway, it's time to upgrade...

@alexandros yes that was very easy indeed. Downloading the source files from https://puredata.info/downloads/pure-data installed with none of the predicted dependency problems on my old-as-the-hills (but up-to-date) Raspberry Pi. In fact, if I'd bothered to read all of the INSTALL.txt before I started, it would have been a success-on-the-first-try endeavor!

So now I have 0.52-1 and a [delete(-able [list-store].

Thanks @alexandros and @dfkettle I might try something like that. I have a suspicion that there will be some core libraries I'd need which might be beyond my Linux skills to update without a total dependency mess, but I'll see...

@whale-av, yes that is a great library! I hadn't explored it before, thanks for the tip. Unfortunately, the way my patch was built, [list-delete] is very far from a drop-in solution, and descending into the fifth circle of Raspberry Pi Dependency Hell may still be the pleasanter option.

Oh, I see... I was using [list-store] messages that are new to PD 0.52. I just tried on PD 0.51.3, and I get the same error. So it's not the Pi.

Guess I need to find another way to easily remove one element from a list!

This is my first foray into the world of Raspberry Pi, so there's likely some very obvious things I'm missing.

I built this patch on a Linux computer running vanilla PD 0.52.0, but when I put it on my (very old and tiny) Raspberry Pi running (oh maybe this is the issue) 0.51.4, I get the error

list store: no method for 'delete'.

I updated everything when I started using this Pi, so I'm pretty sure that's the most up-to-date I can get with Raspbian.

Anyone know about this? I'm also new to all things [list], so maybe there's a simple workaround I don't know about if [delete $1 1( ---> [list store] doesn't work on 32bit and/or 0.51.4.

(by the way, it also seemed like I had to include the number of items to delete - that is, when I simply sent [delete 5( into [list store], to delete the sixth item, I got errors. Specifying "just delete one item" by [delete 5 1( worked. But that's another story; one question per thread!)