Debian 10 (Buster), stable, Debian 4.19.xx
With KXStudio repositories
RT == Yes
Not using a low-latency Kernel (works well w/following):
ACPI disabled on startup via GRUB
Pulseaudio installed, but disabled when using JACK with systemctl
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.
My shot at creating a 16x oversampled guitar processor. It's an attempt at a "minimalist" patch. Here's a link to the Pd patch, although the demo uses an LV2 plugin (see below video demo link):
I doubt the oversampling is done in a "textbook" way, but it sounds OK. I'd enjoy any discussion or input about oversampling -- or anything else in the patch...
The parent Dir has the Pd patch, plus Camomile LV2 and VST plugins (for linux currently). But it should be trivial to make iOS or Windows versions of the plugins. I didn't do that, 'cause I can't test the plugins. The Camomile "Example" files are included.
I've found running this from the shell:
sudo tcpdump udp -X
is helpful when debugging UDP packets from MobMuPlat, etc. PD (or any other receiving app) doesn't even need to be running. It will display all the UDP traffic, but it's pretty easy to find your messages from the babel. It works with tcp, too (substitute "tcp" for "udp").
It's come in handy, especially when nothing is coming through, and you don't know where to start...
(Linux here, but there's sure to be something similar for every OS.)
Here's a zip with four of the original patches (Bold-as-Love, Plugin, Synth, theHexxciter). I don't have more. Note that the "Plugin" patch requires the TAP ladspa plugins, and most distros have replaced those with the LV2 versions.
Beem's link looks like they can be reverted to the originals, tho.
@jyg OK, fixed my Camomile -> VST problem.
The build process doesn't put the vst shared obj file into the folder with the resources. The Camomile docs say to copy the vst build folder to the vst path (I use ~/.vst), but the object file isn't in that folder; it's in the build parent folder. The docs also show the vst as a .lib file, but that's not quite right...
I was assuming the file structure should be copied to ~/.vst, as-is. But instead I copied the .so into the resource folder and that into ~/.vst. Success !
So your VST example "TestCamomile0.0.7" works fine -- I broke it, trying to replicate the build structure I see here.