@Il-pleut damn, just when I thought I was "over" Stockhausen... that piece is great!

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

I know that 10 is no problem. I have an 8-channel interface which is connected (via ADAT lightpipe) to an 8-channel preamp, and I can and do use 16 ins and outs.

It's a Scarlett 18i20 1st generation and an Art TubeOpto 8, and I'm running Linux. I don't know if any other situations would throw unanticipated roadblocks, but this kind of setup seems pretty universal.

How apropos; I just discovered the "$ pwgen 20" label on Bandcamp (all nuPg, all the time)!

A few changes I had to do to make this work:

Installed zexy, jmmmp (for f+), and maxlib (for arraycopy) from deken.

Added [declare lib zexy], and changed each occurrence of [f+] to [jmmmp/f+] and [arraycopy] to [maxlib/arraycopy]. I may not have done this the best way, libraries and externals still confuse me.

And now it's running! Haven't messed with it yet; I'm going to wait for a record contract from that label before I begin. Get me while I'm fresh!

If you are completely new to PD - is it possible that, when you re-open a patch to edit it, you do not enter "EDIT" mode? You need to ctrl/cmd-E to lock/unlock edit mode. Apologies if that's not your issue at all!

What a useful bit of knowledge. So glad you figured that out; thanks again.

Unglaublich - exactly what I needed! Thank you.

Say - how did you know this? Is it documented somewhere? Because I couldn't find it.

I'm new to the [clone] game. Is there a way to poll the [clone] object to see which instance number it's currently on?

Let's say I've got 16 cloned synths. I'm semi-randomly changing certain parameters, of one synth at a time, but it doesn't really matter which one. I've been doing this with [next( and [this(. But I'm curious to see WHICH instance I've changed, say, "rate" on, and which one had "onset" increased.

Does this make sense? Well, my particular use-case isn't that relevant; I'm just wondering about asking [clone] which synth-instance its counter, as triggered by [next(, is on.

of COURSE! The good ol' [set $1(. How quickly we forget.
I guess there's no way of putting that in the [hslider] properties, which is actually where I was receiving my "fromPhasor" (instead of using wires). But that's better really; I always forget that I used the "properties" for send/receive after a few weeks, and have a horrible time troubleshooting my work.
Thanks!

I set this up so that a [phasor~] is reading through a table, an [hslider] underneath the table provides a visual of where in the table we are, AND you can adjust the [hslider] to re-position the playback.

This works perfectly, but it seems a little... inelegant. I don't like the fact that I'm resetting the phase of [phasor~] with every [metro] bang. It's like I'm doing double work... the phase reset is only useful when I move the [hslider] by hand.

Anyone have any opinions on this? Like I said, it works fine, it just seems like there must be a prettier way to do it.

I've had issues with PD and its sound server on Linux - sometimes I'll need to kill PD with some other method (like XKILL... that's alt-F2, then type "xkill" + enter, then click the skull-and-crossbones on your PD window).
I am not at my computer, and I can't recall exactly what causes my PD to stay open (but non-functioning)... but I have, sometimes, had similar issues (though not consistently!). Anyway, temporarily, at least some other kill function can keep you from needing to reboot the whole system.