that is POSSIBLE of course... but I don't think that's what it was. This wasn't the same kind of crash as the [until] loop crash. I got many more red-font errors and TCL complaints in the main window. I still think it had to do with some sort of DSP issue, and I think the PD engine was no longer communicating with the GUI elements. It's definitely not the sort of error I'd seen until more recent versions of PD.

The errors looked a little like this person's: https://forum.pdpatchrepo.info/topic/14361/pd-error-stuck

Maybe though. Minimized SAVE dialogue is a definitely real thing.

Good news, everyone! Even though my PD windows weren't updating at all (showing me the warning, unsaved! asterisk *), my Ctl-S saving actually DID save. Aren't you happy for me?

Argh. And it actually wasn't that (though I've certainly done that plenty of times). It had to do with maybe trying to writesf~ with a random duration that was, I dunno, 0 ms. I cleared the console in my efforts, but there was some complaint about my audio file...

Thanks for the speedy answer, even if it's not what I wanted to hear!

I know, save early, save often... but usually, nothing crashes anymore!

PD "server"(?) is still running, MIDI and audio work, and the windows I was working on are open, but I can't do anything (including "save") with the windows. I can drag them around, because that's my desktop manager not PD, and drop-down menus do drop down, but I can't close windows and - again - I can't save.

Any ideas before I lose my afternoon's work? I could screenshot, but most of the good stuff is in sub-patches.

I'm on Arch Linux, using XFCE4 desktop environment. The chance of someone responding before I reboot is very slim indeed.

@fishcrystals yeah, that's what I ended up doing as well. Mind you... AFTER learning the hard way on "stage" (ok, I don't usually get a literal stage to play on).

I'm still not sure why different PDs over the years have given me different options for MIDI connections (it's partially a Linux issue as well), but now I've been using the software Jack ports, then making the connections to the hardware in Jack, and everything has been predictable and reliable.

OK... one crash-during-performance later, I'm looking more closely into this.

If I have the USB device set to "Output Device" as well as "Input Device," and unplug it while PD is running, PD will crash. If, however, the device is only "Input Device" and not an "Output Device," unplugging it is no problem.

Also, if I have PD set to "MIDI Through-Port [0,1,2,3...]" (instead of looking directly to the device) and make the nanoKONTROL2 -> MIDI Through-Port in, ie, qjackctl, then I can unplug without a crash.

So! Maybe I should file a bug report? Or maybe someone else who has an input + output USB MIDI device and is running PD on Linux (or, who knows? any platform?) wants to try this out and see if it's just me?

Hear, hear. I've been getting into the habit of (trying to) ALWAYS use [t whatever whatever], even when it seem unimportant. Too many times have I been bitten by a seemingly-innocent execution order (egad that sounds sinister) from the earliest experimental stages of whatever patch I've been building.

@oid thanks for checking your system. It's probably an Arch-thing or, more likely, a me-thing then.

I haven't changed anything about my setup, and I've used this Arch & PD installation for at least two years now. I use Jack for audio and MIDI, and usually use PD itself to make the connections (although to be honest - and this is a question I've had for ages now - I'm confused about PD MIDI connections / ALSA MIDI / Jack MIDI, and how sometimes I can make all choices in PD, and sometimes (depending on the PD version?) I have to use Jack).

This is new, I believe. At least, I've never encountered it before, and I'm sure I've hot-swapped in the past.

So: in PD 0.54.1, if I unplug the USB MIDI device (ie, tested both Korg nanoKontrol2 and nanoPad2), PD just up and quits. I don't need to be monitoring anything (like with [ctlin]) though the device needs to be one of my input/output devices.

I'm running up-to-date Arch Linux, kernel 6.7.1. Anyone else? Just me? Bug report, or is there a bug in my brain?

@beep-beep Hot dog - your comment actually pointed me towards something that works good enough for me!
Using [abs] will at least keep everything positive, so the discontinuities aren't crossing the zero line... and then, to make it even prettier, I inverted it with [* -1] to make a mirror image.
Since this is just for looks, I think it'll be good enough... it may turn out that I need a smaller viewer (less than 2000 points) even still, but so far, no glitches, and it looks reasonably like the 7-minute file I loaded.
/home/scuttlebutt/Pictures/Screenshot_2024-01-23_21-42-53.png

Thanks - it's good to know, at least, that it isn't just a simple obvious object I was overlooking. And thanks, @nau, I'll take a look at those libraries when I get home!

It's SO satisfying to have a little [hslider] moving along under an [array] which shows the waveform... maybe you can even grab the [hslider] and drag it to a new point in the file/sample...

But they're SO BIG! Any long sample is made of of many points, even if the display is shrunk down. That makes my PD hiccup whenever it needs to redraw the waveform (ie, minimize then maximize the window).

I've tried making a duplicate of the real [array], but forcing it to be "lower resolution" (say, 1000 points). Sadly, sampling every "arraySize / 1000" points and writing that to the arrayView doesn't look anything like the original. Neither does averaging all the samples within a given chunk... though it DOES take a long time!

Is there another, easier, more commonplace solution I'm overlooking?

wait wait wait... are you telling me I don't have to use [this( and [next( !?!?! How else does one do it? Oh... can I keep a counter in my main patch, and send messages to successive [clone] 's? So then I'd know I was on #47, and I'd send all my details to #47... is that how that works?

Brilliant.

Hold on, I'll be back in a few hours....

not to get all High School Yearbook, but... "sorry so sloppy."

The cloned part is "changeGrain." My front-end patch has four of the "quadSamp," each one of them relating to a specific sample. They get triggered quickly (as fast as 5 ms), so there can be a time where four different samples are triggered within 5ms of each other.

quadSamp is also where I can set, ie, the rate or the filter to be different for Sample A than for Sample B.
quadSamp:

quadSamp.pd

And so the problem is that, for instance, Sample A is Duran Duran's "Fame" but filtered and slowed down - no problem - but when I occasionally trigger Sample B (David Bowie's "Fame") I hear bits of Sample A at normal speed and unfiltered (following Bowie's parameters).

changeGrain (that which is cloned):

changeGrain~.pd
This might not make sense, and my patches might be too personal/messy for anyone to want to take a look...

Trying to fully fathom [clone]...

I am working on a granulator patch which uses many [clone]s, and four possible samples to choose from/mix between (ie, 25% chance of grain A, 75% chance of grain B ). I think Carl Stone might already do something like this, but he uses Max, so, totally different.

Anyway. I'm using a [t b b b b...] to, first, a [next newName $1( to choose the sample, then a bunch of [this rate $1(, where the "THIS" messages are attributes (rate, filter, whatever).

When I'm mixing my grains (ie, anything other than 100% of grain A), the "THIS" attributes sometimes get applied to the wrong sample. That is, if I know grain A should be slow and heavily filtered, and grain B is fast and bright, I hear some A's fast and bright.

I thought using a [t b b b b] would ensure that the the same sample chosen by [next( would receive all of the appropriate [this( but... no?

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