• 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
  • beep.beep

    @liamorourke By the way, I find the [text] object to be much more useful than [textfile] in general. It might be a little more complicated to get the hang of at first, but it gives you many more options with its various functions ([text define], [text set], [text get], and the super useful [text sequence}). I use it for reading/writing presets as well as sequencing, and it pretty much makes both [textfile] and [qlist] obsolete.

    posted in technical issues read more
  • beep.beep

    @jjjjj Hi, welcome!

    I'm a Mac user running Catalina (10.15.4) and Pd vanilla 0.50-2. In general, I have noticed that the default security settings on recent Mac OSes are ultra-sensitive, and it doesn't take much for any non-Apple application to trigger lots of prompts requesting access permissions (sometimes rather random, such as the one you encountered).

    I find this rather annoying personally, but it hasn't led to any problems. It seems very unlikely that Pd itself could harm your system (or your calendar...) in any way. You might want to use a bit more caution in installing externals, as it's theoretically possible that someone could write malicious code & compile it as a Pd external, but I have yet to encounter this or hear of it happening anywhere before.

    By the way, you likely will want to grant certain access to Pd, such as microphone, network, documents/library folders, and possibly camera if you're using Gem.

    posted in technical issues read more
  • beep.beep

    Actually, the version on Deken ("Find externals") is 64 bit. Perhaps more likely, the library is not being declared, such as with:

    [declare -lib timbreID/timbreIDLib]

    See the INSTALL.txt that's included in the timbreID folder for instructions, you may have to adjust the path in order for Pd to find & load the timbreIDLib.pd_darwin file (which is where all of the objects live).

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!