PD Granular/Sampler noise problem

OWL Patches
, ,
#1

Hi everyone !

So, I’m pretty new to PureData, and recently started to try making my own patches. I’m currently trying to make a simple Granular/Sampler kind a thing, with control of the playback speed (and reading direction), starting and ending point, and a grain size.
The patch itself work pretty great on my computer, but once I upload it on the Lich (via pd compiler), I got some kind of bitcrushing/aliasing noise going on. So far I tried lower the array size, bypass the grain size and start/end point parts, but got no luck.
I’m thinking maybe this is due to the compiler, or maybe some kind of refresh rate of the knobs ADCs ?
In any case, any hint would be more than welcome ! Here is the uploaded patch Granulatorix11 (I hope the link will work since it’s private for now, but I don’t mind publishing if needed).
Thank you very much !

#2

Yes, direct links for patches always work, there’s no need to publish it until it’s running without issues.

ADC values always contain some amount of noise. Unlike a widget on computer, it’s not truly constant even if you’re not changing it. So using raw ADC parameters for settings something like delay line length or buffer position is a common pitfall. This can often be fixed by smoothing/filtering parameters that are sensitive to noise.

One obvious way to test for this is by replacing all ADC input parameters with constant values to see if the issue is gone and then return parameters one by one to find which is causing artifacts. Or you could change the parameter IDs to be outside of the ADC inputs and set them with a MIDI controller.

#3

Hmm I see, so that’s indeed the culprit I had in mind…

I tried using line objects to generate a smoother transition between values, seems to kind of do the trick. I tried to implement the gen~ version on the last post of your link, but no luck so far. The funny thing is, it mainly happen with value received from the B Pot.

Midi might be a solution, but I’ll loose the interaction with the onboard knobs and CV inputs. Or maybe, if I patch them so that they control the midi parameters ? But I might encounter the same raw data problem :confused:

Anyway, thanks for the hints ! If anybody wanna try the kinda working patch, it’s here

Other question, is it better to compile pd patches via heavy or pd compiler ? Heavy seems to be way faster

#4

If you think that the problem is with particular channel only, you could make a trivial patch to read value from parameter and send it to audio output. This way you can compare amount of noise for different ADC channels. Is that a DIY Lich or factory assembled, btw?

Better by what metric? Heavy is used to generate code that can run as a C++ patch on OWL (or on other targets). Desktop PD just executes your patch (it’s not a compiler at all). They solve different problems and I don’t even understand how they can be compared directly.

And another thing to consider is that Heavy can’t handle 100% of objects that desktop PD understands.

#5

It’s a DIY Lich, but I only have had this kind of noise problem on my own patches. Never happened on community’s patches (tried a few one, mainly reverbs and grain delay loopers).

I meant, when uploading a pd patch, I can either use “Heavy” or “PD” for the online compiler. I remember reading a tutorial where the used compiler was “Heavy”, but there’s also a “PD” option. Both seems to work and compile my patch to C++, but the heavy one seems to be way faster.

#6

The heavy compilation type is only for generating C code from Pure data, i.e. running the Heavy compiler. We provide it as a service now that the original version from Enzien audio is no longer available (back story here).

So for making OWL patches you need to select pd, which will also compile the C/C++ code and generate sysex and JS.

The names though are super confusing and should be changed. Quick poll:
what should we call the Pure data -> OWL patch compilation type?
and what should we call the Pure data -> C compilation type?

#7

We could use something like “Pure data patch” / “Pure data C export” as labels and rename other targets as “X patch” from just “x”. Potentially we could allow exporting FAUST patches as C/C++ too, but not sure if there’s a good reason to do that.

#8

Are you sure that it was a tutorial about OWL? Desktop version of PD won’t run on a microcontroller, web patcher uses Heavy in both cases. But with something like Bela that is running on microprocessor board and a Linux OS, the situation is exactly like you describe. So they’ve ended up supporting both PD (using libpd) and Heavy compilation, but Heavy was resulting with much better performance and was the recommended target.

#9

I think I know what happened : I must have read the link @mars provided about the heavy compiler, and thought that was the way to compile puredata patches for the Owl. Which explains my confusion about the two compiler options. But now I get it, both works, but “pd” is optimized for Owl and web player.

Anyway, thanks to both of you for your help clarifying things !