Hello there,
I started developing a sampler/looper with Purr Data a couple of months ago (and I've used this forum a lot!), to be used with a 8*8 MIDI launcher. In order to avoid audio drop-out and glitches, I spent the past 2 weeks separating the UI and DSP patches, communicating via OSC (so the UI can be launched with -nrt and -noaudio while DSP is using -rt -jack -nogui) (I'm on Debian 9.0).
To avoid dynamic patching and array creation, I then have 64 instances of the track's DSP abstraction, waiting for the UI to use them, even if only 3 or 4 tracks are actually used.
I find however that the idle DSP instance of Pd - all tracks' abstractions loaded, but not recording or playing any audio - uses 28-29% of my CPU when monitoring with Pd's load meter, while the idle UI instance uses only 5% (I'm on an old machine, but still). I have narrowed it down to the tracks abstractions, since I get only 5% CPU use (DSP side) when there is only one idle track patch instead of 64.
Looking deeper into it, I find that if I delete the 2 [tabread4~] objects (each track has 2 arrays for stereo) I significantly reduce the CPU load, from ~28% to ~17% with 64 idle patches. 17% is still significant, but I couldn't identify any other object with such an important impact.

Is it known that [tabread4~] (tabread~ does no better) uses significant CPU even if idle, both with a phasor~ at 0Hz or not connected at all to the phasor~? Is there a way to make it "sleep" completely? or is there no/little risk of audio drop-out if I create that tabread4~ object dynamically once I actually need the track?
The CPU load increases too ~40% when I turn DSP off, I guess because of errors or confused messages with empty arguments when processing audio signals.

Any other advice to reduce the CPU load is of course also welcome
Thank you!

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

Thanks so much @beep.beep, that sounds like exactly what I need!
The help documentation about [switch~] is very concise to say the least, but I'll try to figure it out!

All right, for reference, I read some explanations here (2.4.4) but not easy to get it to work without an example, and finally the answer to my main question in this thread: just send [1( or [0( to [switch~] (no argument) to activate or deactivate DSP in this window and all sub-windows (this is weirdly the first time I hear of objects that work for the window rather than the patch or abstraction).

I have just implemented it and my abstractions do [throw~] the outgoing sig[nal, and now the CPU load is down from 30% to 7-8% when no track is playing!!! Amazing !! Thanks so much @beep.beep!

Major trouble I've had, for whoever might read this in the future: [switch~] should not be in a subpatch of the abstraction, but in the highest-level window it should act on.

Cheers!

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

@beep.beep I actually haven't seen [pd~] before, thanks again! Since DSP needs to be running, I'm not sure how I can actually use it (if I had my 64 tracks as [pd~] subprocesses, they would all have to be "DSP on"), but I'll keep it in mind. It might be more efficient than OSC messages between several DSP instances of Pd, but my machine only has 2 cores anyway, so I'm not sure whether there is much more to optimize there (for now - at some point I might very well be using my patch on other computers, and other people may use it).

I'm now in the process of implementing [switch~] in the different subpatches of my track abstraction, so as to shut off [tabwrite~] when playing and shutting off [tabread4~] while recording, let's see how this goes.

In general, I still hear quite many clicks and glitches when playing, when the [phasor~] reaches 1 and jumps to 0, or just randomly in the middle, even when the DSP instance runs in -nogui, without debug or verbose and without printing OSC messages. Increasing the number of frames per period in Jack from 128 to 1024 doesn't really help. Not sure whether this can be a problem of CPU power or sound card, I may try on another computer to figure it out - I'm on a 10-year old laptop using the embedded sound card (funny thing, I also hear tons of clicks and glitches when opening the emoji panel to write this message, so I suppose it really is a hardware shortfall).

I don’t know the answer to your question but I’m also building a multiloop looper (I’m thinking either 10 tracks total or 10 loops of 4 tracks each.)

We’re probably solving a lot of the same problems. Right now I’m working on latency and overdub timing. Next up will be learning how to use switch for CPU savings...

Would be very interested in any updates from you.

Best, Tom

Haha, sure, with pleasure to join forces @Tombot7 ! Not sure what the best way to communicate may be - I'll definitely be back on this forum if you post something, and I have a github repo with the latest more or less usable code.
Latency is not a very big deal for me however since I start playing the tracks as per the main metronome's beat, and I'm not overdubbing but I'm interested to see what you've got anyway!

Hi zigmhount!

This is a copy paste of a message I (hopefully) sent via chat as well:

I figured I’d tell you a bit more about my patch so we can see if there’s overlap. Switch is definitely an overlap. I’m not using a metronome at all on mine. The inspiration was two loopers I love: the line 6 DL4 and the EHX 45000. It’s going to be 4 foot switches. Record, play, previous and next. Record and play function the way they do in the DL4. Record to start a new loop, record again to set length and start overdubbing or play to simply set length and start looping. From there record works like overdub on/ off toggle and play stop or restarts the loop. Previous and next are where it gets interesting.

There’s a 7 segment display (meaning a 1 digit number read out) that tells you what loop you’re “focused” on. It starts on 0. You can’t change focus until you have a loop going. Once you do, prev or next change focus. If you change focus while recording, it closes the loop you’re on and starts playing it, then immediately starts recording the next loop. The next loop though can be as long as you want. However, silence gets added to the end of the loop when you are done so that it matches up with a multiple of “loop 0”

In other words, loop 0, acts as a measure length and all other loops are set to a multiple of that measure length.

But...they can start anywhere you want. To the person playing the looper, it will feel like individual loops are all overdubs of the first loop, just at any length you want. I don’t know if I’m explaining this so well, but the point is, you don’t have to worry about timing or a metronome with this. You don’t have to wait for the beginning of measures to start or end loops. Once you have the timing of the first loop down there’s no waiting... you start recording and playing whenever you want as long as you want t and if it’s in time when you play it it will be i the recording.

So far I have recording and overdubbing down on loop 0 WITHOUT CLICKS. this took a lot of work and messing. Sounds like you are struggling with that now. Hardware is important yes.

I’m running it on a rasberry pi 4b 4 gig memory but with a pi sound audio interface. It’s more expensive than the pi but the latency and sound quality are GREAT. I also wanted to make the hardware all independent eventually and have the whole thing fit i it’s own box. The foot pedals run on an arduino that talks through comport to the pi and pure data.

In pure data I’m timing the loops and recording them via tabwrite. I’m then playing them with tabplay with a 0 $1 message box where 0 is start and $1 is the length, rounded to block size, of the recording. I record and play the same arrays for each loop at the same time while overdubbing, but delay the recording so it’s a few blocks back from the tabplay. The delay on the recording seemed to help elimate clocks as well. So did using tabplay instead of tabread 4. I think the phasor is CPU expensive or something. I don’t know. When I start / stop recording I use a line ramp on the volume going into the recording of 5 msecs. This is also necessary to eliminate clicks. Also, I had to stop resizing or clearing arrays as both cause clicks. Now I just overwrite what I need and don’t read from what I didn’t overwrite (If that makes sense).

If you are getting clicking I would try upping block size, buffer size and just delaying the actual recording (delay the audio in the same amount) giving the computer time to think avoids drop outs. Also you don’t want monitoring if you can avoid it. I don’t know if you are using a mic or what.

Hopefully some of this made sense.

I’m on a phone, so sorry for the typos.

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

@beep.beep Very useful, thanks again! Note that some of the glitches I hear (like the one I mentioned with the emoji window) can be heard also when Pd is not running at all, so while I'm certain that a higher delay will help, the root cause is somewhere else I will try.

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? I've seen other discussion threads about windowing, involving for example interpolation between the end of the array and its start when beginning a new ramp with [line~], but I'll probably have to quite some time to get this to behave properly.

More questions though :
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?

@Tombot7 Thanks so much, very interesting. My looper's approach is however very (very) different from yours, since I took inspiration from midi loopers such as Seq64 or "matrix-based" (not sure what the proper term may be) audio loopers like Luppp, launching the clips with a midi controller with the same matrix of 8*8 buttons. So far using only audio input (from mic or [fluid~]) but I plan to include some MIDI sequencing at some point, at least for CC automation.
My first attempt included graphical visualization of the waveform and resizing of the array, but I quickly gave it up!
Interesting considerations about tabplay vs tabread4 and line~ vs. phasor~, I'll just trust you and implement this right away . I figured that tabread4~ may be handy in case of changing the tempo after recording arrays, but I guess that's something one may not even want to design for on modest hardware.
Thinking about it, I should probably consider removing [fluid~] from my main dsp patch and put it into a [pd~] subpatch, or (if it makes any difference?) yet another separate Pd instance.

Well well, this thread is giving me enough work to fill another Covid lockdown - I'm in Spain

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

@beep.beep Thanks so much! I will look into all that and test and implement stuff, and I'll come back here if I have more questions!