Since many of your here are pretty good at pD, let me ask here as well…
I’ve made a very simple 4-track sample player (to be used on a headless Rpi+Pisound system) using tabread4~ and it gets all glitchy (and pD often become slow and unresponsive).
I’m running pD on the latest Raspbian on a Rpi 3. The patch is a relatively simple one: I have 8 tables (for 4 stereo samples) and read those using a phasor~ object, adding some MIDI control over pitch, volume and some lowpass filtering (using bob~).
When checking CPU load inside pD it tells me I’m at 77%, but the system graph only says 25%. The load does not seem to change when removing channels, though one channel alone (hence 2 tables) seems to play ok.
I wonder if this is this normal or maybe if it’s my patch that is buggy?
I checked this patch and the CPU usage doesn’t look too far from what I’d expect… and not as high as you report. (Though I checked this on my Mac, not my Pi… though I have a decent sense of the mapping).
The meters, eat significant CPU. In my patches, I have a toggle to turn metering on or off. The meter value calculation (env~ & *~ in your patch) is in a subpatch, controlled by switch~.
The unsig patches and number display also eat some CPU - not as much, but updating at 300 Hz is using resources for no value.
Are you certain you are running Pd at the sample rate of the PiSound: 48kHz? The resampling in the PiSound driver is “good”, which means, slow!
It’s a lot of bob~ units (32 in all), but I doubt it’s that big a deal. However, wouldn’t bumping the resonance be almost the same effect with this unit? Not sure…
Your phasor~ isn’t scaled quite right: If there are n samples, then you need to multiple the phasor~ output by (n-3) and add 1. This ensures no glitches at the edges.
This patch will be much easier if you use abstractions in separate files. That way you can update that one patch and have all four samplers update.
I have a bunch of other small things you could fix, but none of these will save significant CPU.
Ive not had a chance to look at the patch… so perhaps a red-herring, but perhaps the cpu % are misleading?
the rPI is quad core, and a single pd process (without using pd~) is single threaded, so perhaps PD is reporting % one core (its using) , whilst your ‘system graph’ is reporting % of all cores .
(upshot PD can only get a max of ~ 25% of the quad cores/cpu, without spinning off other PD processes with pd~)
if you use top then you can tell it to report each core separately, which might help to see if PD is maxing out.
also… cpu% are averages, whereas you’ll get audio glitches even if you only have a few ‘cycles’ causing underruns on the audio thread.
what id probably try initially is to increase the audiobuf/delay size in audio settings, and seeing if that helps (and it should) , if it does, then you that might tell you that the patch has some inefficiencies.
finally, with something like a rPI, what I would recommend is, when developing (so using the GUI) , increase the audio buf size - but for ‘performance’ run PD with -nogui and reduce the buffer size and so get reduced latency.
btw. does anybody have an idea about how to get the creation variables into a message box. Soundfiler does need a message with the info on which file to lead into which table, but that of course won’t take the $1 – $3 variables inside the abstraction
sorry, but I either have totally not understood what you mean, or it doesn’t work. Guess it’s the first of the two. Why would I have to multiply the phasor’s output by the samplerate?
Interestingly I don’t get any glitches at the edges. I do get some random glitches here and there though, but where they appear seems a bit random.
Maybe these glitches are xruns?
Not sure, I think it’s due to the samples being longer than the max number of samples allowed for a table in pD. I know there is a fix for that, but for now I’ve just cut the loops a bit and it looks like the glitches are now gone.
btw. figured out the thing with adding 1 and subtracting 2, I need to do that from the amplitude of the phasor~ not the frequency I think. that’s because tabread4~ is not supposed to go from sample #1 to the last sample due to the interpolation scheme. If I have understood this correctly that is.
But back to the glitches. On my macbook the patch now runs ok. On the Rpi it’s a total glitchy mess. It actually sounds pretty cool, listened to it for a bit tonight. Def. usable as an fx if it were an fx. Unfortunately I’d like it to not do that.
No idea what could cause that. I did even convert all the samples to 48K just to be sure.
I’m sure the Rpi runs at 48K because I am running pD from “thebutton” which launched pD selecting the correct sampling rate automatically.
edit. on the Rpi Pd complains about an “audio I/O error” when loading the patch.
my methodology would be to first configure the RPi to have it in its intended “production” state (headless (minimal system, no desktop packages), low-latency optimizations, using the intended sound interface) and then patch on it through another computer (via ssh -X to access the GUI).
This makes it easier (imho) to test various pd runtime options and be sure there nothing unintended (pulseaudio, desktop things causing interrupts or cpu spikes etc) getting in the way. It also helps keep the patch realistic with regards to processing power / latency / controllers reactivity.
Little update on the matter.
Looks like the patch works ok if I only have one instance of the sample player (so only one sample is playing). I guess the rpi just doesn’t have the juice to run more than one and Pd is probably just the least efficient software to do it. Or both.
I do not know how to go about removing desktop packages without breaking things. But I did disable the automatic launching of the x server, which should have the same effect, shouldn’t it?
accessing the rpi via ssh -X now finally works without the raspi crashing (probably running the x server on both sides was creating some conflicts).
Still… Pd seems very unstable, slow, crashes sometimes needing a complete reboot of the system, sometimes it won’t load a patch etc.
I should add that I have another patch that just plays short drum samples (8 of them) and that works totally fine… so maybe the problem is in the patch.
I have to admit that I am getting a bit frustrated with trying to make this work. every time I patch a hole, 3 new ones show up, and literally nothing I have tried to do has worked seamlessly without requiring hours of – often vain – troubleshooting and searching for solutions online. Tried to make samba work, doesn’t. Manually mounting a USB stick, doesn’t. Getting Pd to save the settings when run as root (the Pisound button does that) won’t work. The list goes on.
It’s been a big learning experience though. The main lesson learned is that there is a clear limit to how much time and energy I am willing to invest in something like this and on how much I depend on the community to get things to work somehow (and btw. I’m really grateful to all of you for the kind help so far!). Which also reflects on my decisions about how to proceed from here on and on my thoughts on the new monome norns.