• beep.beep

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

    posted in technical issues read more
  • beep.beep

    @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~]

    posted in technical issues read more
  • beep.beep

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

    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.

    posted in technical issues read more
  • beep.beep

    @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. :collision: :grimacing: :confounded:

    posted in technical issues read more
  • beep.beep

    @zigmhount said:

    In general, I still hear quite many clicks and glitches when playing

    Sounds like the most likely culprit is setting the delay too low in your Pd audio settings, which will lead to dropouts when the CPU isn't able to keep up with Pd's computation deadlines. I can sometimes push it as low as 6ms on my 2016 Macbook Pro if most parts of my patch are switched off, but sometimes I have to bump the delay up to 25+ms if many modules are working hard simultaneously.

    The only time I've used Pd on Linux was on a Raspberry Pi 2, which needed at least 50-100ms (if not more) to run even very basic audio patches. I haven't used Jack, so I can't say whether that could cause any glitching trouble. But an easy first step is to increase your delay & see if that helps.

    Another possible source of clicks could be discontinuities in the loop waveforms, which seems likely if you're hearing it when your looper wraps around. You'll need to add windowing, or a short fade in/out anytime a loop starts, stops, wraps, or jumps to a new position. And, you also need to take care when using [tabwrite~], otherwise discontinuities can be recorded into your loop. For example, something like this:
    tabwrite_fade.png

    posted in technical issues read more
  • beep.beep

    @zigmhount Happy to help steer you in the right direction! Indeed, the documentation is rather vague for some objects, and the [block~]/[switch~] object is particularly confusing. Alas, learning to dig for answers outside of the help patches (the html documentation, this forum, Pd-list, etc.) is a big part of learning one's way around Pd, so hats off to you for getting it working so quickly!

    I imagine you may have also stumbled across some of the other CPU-saving methods, but might be worth mentioning the [pd~] subprocess object, as well as the option to manually run several other instances of Pd to spread out the load among several processors (since you're already doing so with the separate UI/DSP instances). But [switch~] is definitely the quickest & easiest way that I know of.

    posted in technical issues read more
  • beep.beep

    @zigmhount Hi there,

    You can stop audio processing in specific subwindows/abstractions with [switch~]. All tilde objects ([tabread4~], [phasor~], [*~], [+~], etc.) will calculate their output after every DSP tick unless you switch them off, regardless of whether their output is actively changing (including the cases you mentioned: a [phasor~] at 0hz, or a disconnected tilde object). You won't reclaim 100% of that CPU load, but the savings are quite significant.

    Dynamic creation will very likely cause audio dropouts, so if you're trying to avoid glitching, that might not be the route you want to take.

    If you do go with [switch~], be sure to ramp up/down the output amplitude of your abstractions, so that you avoid discontinuities. (i.e., ramp down to zero before switching off, and ramp back up to one after switching on)

    HTH!

    posted in technical issues read more
  • beep.beep

    @yealace Hi there, I believe I found this technique in one of @Maelstorm’s patches & adapted it, so I’m a bit fuzzy on the math.

    But yes, [cos~] plays a part in creating the window. It’s fed by the same [phasor~] that is driving [tabread4~] (the audio table playback), and generating a slice of the positive part of the sin function ([phasor~] -> [cos~] is equivalent to [sin~]) which is being amplified & clipped to shape the window.

    I made a quick attempt to add some calculations that make the length of the window consistent at any playback speed (for example, 25ms fade in / fade out at either end, regardless of whether you’re playing the loop at 0.5x speed or 4x speed). It kinda works but is definitely not accurate at all loop sizes & speeds, so anyone who wants to improve on it is most welcome to do so!

    Here's a vanilla version of the patch I posted earlier in this thread, which should be easier to get working if you're just interested in the windowing part:
    single_precision_looper.pd

    posted in technical issues read more
  • beep.beep

    @s.elliot.perez I'm not a coder, but I do get the sense that there will always be certain programming techniques that can be realized faster in code than in Pd.

    That said, I feel like my biggest breakthrough in Pd was in learning how to quickly build abstractions. Anytime that you're repeating similar calculations & connecting dozens of cables, you can likely create a new abstraction & realize the idea in a fraction of the time it would have taken you otherwise. I don't think it'll ever be quite as efficient as a few lines of code, but at least will get you much closer.

    You can also pull off some fairly advanced trickery with [expr], although I'm not the one to ask about that.

    posted in technical issues read more
  • beep.beep

    @paste I think I may have used @Maelstorm's windowing technique that @whale-av linked to above — it's been a long time so I can't remember for sure, but it does sound like the same approach (amplified/clipped cosine as crown window), which I find works pretty well!

    This was the looper patch I used it for:
    https://forum.pdpatchrepo.info/topic/11353/tabread4-example-or-alternative/3
    The full patch probably won't work for you as-is because the iem_dp library can be hard to get working, but you could certainly check out the [pd window] subpatch & modify it for your own sampler.

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!