Debian 10 (Buster), stable, Debian 4.19.xx
4 Gb, 2 cores
With KXStudio repositories
- separate local installs of Pd 0.50-2 and 0.51-2 (they don't always work with 0.49 externals, but pretty much doing vanilla anyway)
Also: Ubuntu 20.10, Kxstudio repos
16 Gb, 16 core
Pd 0.51-2 installed
RT == Yes, on both
Now using a low-latency Kernel
ACPI disabled on startup via GRUB
Pulseaudio installed, but disabled when using JACK with systemctl
CPU scaling works correctly for this machine
Will still disable Pulseaudio when using JACK
Reading this with great interest!
My two cents... Katja Vetter's expochirp
Thanks for Katia's expochirp link. I've used both Aliki and jack-ir (x42/R. Gareus), so more options == better.
Making impulse responses as F/X is (IMHO) as much art as science...in a non-technical, non-rigorous context, of course.
A couple incremental updates to this project (Pd code not functionally changed, so the above non-plugin version OK):
- The sample rate wasn't being correctly recognized in the plugins, due to differences in Pd and Camomile conventions (see the pic to compare). The Pd version always worked correctly, but the Camomile plugin didn't set the lowpass filter values correctly. Tested at 96000 and 192000 sps.
(Pd code left, Camomile right)
This makes some sense -- for a plugin, when does loadbang actually happen?
- Fixed some annoying xruns on an older machine's Debian install of the plugins, which occurred following a preset file load. Probably resulted from weird values being passed to JACK ports, due to the "rolling" parameter order updating. Fix is to mute the output during update.
Possible future updates (???): make oversample rate changeable...having adjustable aliasing w/greater harmonic distortion can be good...
Fix the lowpass filter values to reflect actual frequencies.
Again, should have included the non-plugin Pd version for evaluation:
There's a folder in the archive (.AUCOP) that holds extra presets. On a Linux system it should be in the user's home path (I've never tested that on other systems). It's not absolutely necessary, and the "Load Presets" file dialog should just open in the default Pd dir, if it's not found.
Edit: Oops, I kinda already did that above. This is different only in changes to the extra preset file...
@ricky It's actually set in the [inlet~] obj, and the padding documentation is buried four clicks deep in the help file (under "pd up/downsampling"). It took me some time to find that.
If (my) memory serves, one lop~ stage didn't have a sufficient cutoff, and I liked having the option (and sound) of setting the resonance in vcf~. At this point I've replaced that two-stage scheme with a single biquad~ filter. It seems to be a bit quieter with the higher gain patches (and might even hit the cpu less).
Anyway, there's a new version (with somewhat different version style #, 0.1.71) of the Pd patch:
I'd planned on making a short demo vid before updating this thread, but no time like the present...
The github page has the Camomile LV2 and VST3 plugins for this version (still Linux only -- but the Camomile code is there, so it should be easy to build plugins for Win & Mac).
Loaded the original in Purr Data on my Debian install, and the patch didn't sound correct. It was clear the default upsampling in Purr is zero-padded, unlike stock vanilla Pd. I knew the upsample schema was an issue with the original (aliasing-wise).
This is good; a chance to examine the patch with a fresh perspective.
The changes required weren't radical -- first needed to recover some amplitude that's lost with zero padding (where that's done mattered). Added a Pre-Level control. The differences do change the waveform, so tweaked most of the presets as well. I think it's an improvement, particularly for the higher-gain presets.
Zero-padding is explicit now, so that's for vanilla too. This might effect (positively) other flavors as well.
Sorry, no demo currently, just the updated patch. And nothing changed on github -- no Camomile plugin versions yet. Upcoming...
One corrupt line in the 0.63 preset file ("red clay") caused errors. Here's V0.64:
@ricky I guess (as I understand it...or not), the upsampled signal should be zero-padded, and followed by a "textbook" FIR filter (sorry for the "textbook" again!) or alternately, another low pass filter with similar characteristics.
I initially couldn't find any info re: Pd's upsampling algorithm. And I was fairly constrained to vanilla (by Camomile). I did eventually find the default upsampling when reblocking is not to pad (sample/hold). But the patch was written, and seemed to work ok.
Re: low pass after upsampling -- I used a vcf~ filter, followed by a regular lop~, hoping that might hit the cpu less.
Sorry again about the textbook thing. Fact is, I don't have one.