@seb-harmonik.ar Thanks again!

For anyone else who's following:
https://github.com/pure-data/pure-data/issues/1823
https://github.com/MetaluNet/moonlib/issues/20

@seb-harmonik.ar Yes indeed, thank you! The Console app brought the crash report right up.

And I think I may have quickly found the likely culprit: mknob (from moonlib), which crashes if I bring up the help patch. If that's true, I wonder if this should be a bug report for the external itself (perhaps this repo?) rather than Pd? Or might it still be useful for the Pd devs to see this if other externals could also be broken due to a change in Pd 0.53?

One other question: when the time comes, what's the preferred format for submitting a crash log? Paste the entire thing into a Github issue, or is there a cleaner way?

@Load074 Similar (or same) issue for me on macOS Monterey, certain gigantic older patches of mine are crashing Pd 0.53 when trying to open. I've been doing a bit of initial research into how to generate a crash log (which I've never done & have no idea where to begin) for submitting a bug report to Github, but free time is a bit scarce at the moment. Any quick pointers for doing so are welcome!

The only initial thing I could think to do was to start Pd via command line... saw "segmentation fault" but no other clue about what the error might be.

@Metronome I probably experienced somewhere in the neighborhood of 8-10 headphone explosions when I was new to Pd, and possibly suffered some nonzero amount of hearing damage as a result, so I can very much relate to your question.

Ultimately I came to accept this as inseparable from the nature of Pd as a programming language, in that it gives you the raw tools to do pretty much whatever you like (including things that may not be advisable, either for your ears or your computer). Nowadays I always approach any unfamiliar patch (a help patch, demo from this forum, or anything whatsoever) with caution; I always take a look at what's going into [dac~] first, as many of my past unpleasant experiences came from patches where the author simply connected a number box with no defined upper limit directly into the right inlet of [*~] as gain control, meaning that if you mouse directly on the number box to turn up the volume (without shift-clicking), it's quite easy to slip & blast your ears in an instant.

For my own patch, I used zexy's [limiter~], which lets you specify an output limit in dB; you could make an abstraction which wraps such a limiter, and make sure to always add it in before [dac~] as a safety precaution in any patch you open. Or, when opening patches, just watch out for sketchy output levels before turning on DSP, and if necessary edit the patch first (perhaps [*~ 0.1] or [/ 100] or [dbtorms] may come in handy in these situations, if you catch my drift).

It is worth noting though that accidental volume spikes in general are certainly not unique to Pd, and keeping headphone/speaker volume low at first when checking levels is simply good practice with any speaker in any application.

@Kosmas Hi there, I haven't (successfully) used jack on Mac (I'm also on 10.15.7), but this is what I use to run Pd from the terminal:

/Applications/Pd-0.51-3.app/Contents/Resources/bin/pd /Users/*your*/*path*/*to*/*your*/patch.pd```

I also use several flags depending on what other options I want (-nogui, -channels, -audiobuf, etc.), maybe the -audiodev or -jack flags would get things working? I think I've seen some discussion recently on Pd-list/Github about jack & macos, and if memory serves, it isn't a simple solution...

@ricky Hmm, I don't have experience with that particular error, but it's possible your hunch is correct.

The first time an app requests to use the mic, the webcam, access certain directories, etc., the OS will throw a popup at you asking if you want to grant permission. Either way you answer, you can change this later in System Preferences / Security & Privacy / Privacy / Microphone.

If that doesn't work, you might need to do some more searching (this forum, Pd-list, Pd's github, stack exchange, and so on). But I hope the easy solution works out for you!

I'd try creating a [declare -path zexy -lib zexy] in your patch first to see if that loads the library. You can check the zexy readme on github for more info, specifically the part under "making pd run with the zexy external".

@cfry This sounds suspiciously like a known bug in older versions of freeverb, see here:

https://lists.puredata.info/pipermail/pd-list/2009-11/074142.html

I had the same problem years ago when I added an older version of freeverb to my patch, namely that this denormals bug would cause the CPU to grow out of control if the input to [freeverb~] fell silent. The readme in my current version says "Recent changes (1.2.2): fixed the NaN/denormal check", but I haven't actually tested to see if the problem remains. I still have my original workaround in place just to be safe, which is to add a tiny amount of noise to the input signal:

[noise~]
|
[*~ 0.00000001]
|
[freeverb~]

@yannseznec I’m quite familiar with that bullied-by-Apple-to-upgrade feeling.

Pd 0.51-1 is indeed working fine for me on Catalina 10.15.7, aside from the usual shenanigans required to launch third party software (right-clicking & selecting “open” on first launch instead of directly double-clicking on the app icon, granting permissions for microphone, network, directories, etc… feel free to ask if you’re not already familiar with how to do all of this).

I do use zexy, which works fine, but not purest_json or comport. When I upgraded to Catalina, I did have 3-4 external libraries which MacOS refused to allow to run. Some I had to manually grant permission to load in System Preferences / Security & Privacy, others I had to download source code from GitHub & recompile in Xcode. However, if memory serves I did this using Pd 0.50, and I believe the devs have done recent work that allow Pd 0.51 to load older libraries without all of these extra steps. I haven’t tested this since the new release but hopefully this should all work now without the extra hassle.

Oh, and of course if you’re still using anything 32 bit (Pd, externals, or other software), they simply won’t run in Catalina, so it’s worth going through your software library & researching alternatives before diving in head first.

@zigmhount said:

Good advice on the discontinuities. I was kind of hoping that [phasor~] would handle this better than restarting [line~] from 1 to 0, but I suppose that it also just jump from 1 to 0?

Yep. Regardless of whether you're using [line~] or [phasor~] to drive [tabread4~], discontinuities can happen anytime you abruptly jump from one spot to another. This isn't unique to Pd, if you perform edits to a waveform in any DAW without crossfades at the edit points, you will get clicks/pops (unless you get lucky & happen to edit at a zero crossing). So, if the first & last values stored in your array (loop) are not the same & the loop restarts (either beginning a new 0->1 ramp with [line~] or letting [phasor~] wrap around), you'll get a pop unless you use windowing.

In your example, you record the ramp up and ramp down into the array itself, right? Is that not audible when looping the same array over and over? Thanks to this ramp in the array, I guess that [tabread4~] may not click even if started without a volume ramp in, would it?

Yes indeed, that example essentially records the fade in/out into the array, so you wouldn't hear clicks when the loop wraps even without using a window with [tabread4~]. However, note that this is only one of the causes I mentioned... if you're eventually planning to add any playback controls with abrupt changes (such as pause/stop, start from the middle, rewind, jump to a new position, etc), you'll need a fade out before the change and a fade in after the change. FYI, my personal use for recording the fade into the array itself is because I sometimes use a phase vocoder for time stretching of my loops, which seems to misbehave if I have extreme values at the start/end of the array.

And, yes, the windowing can be audible, but it really depends on the nature of the audio that you're recording into the array. I randomly chose a 10ms fade in/out for the example above, but that could be any duration you like (you might want it to be adjustable if you're looping many different types of sounds, to experiment with shorter/longer fade times). There are also ways of shaping the curve of the fades if you really want to minimize their chances of being audible. But even if the fades are obvious, I think you'll still find them to be a million times less strident than a loud speaker pop.