nice implementation and very resourceful approach using the vanilla objects. thx for sharing! will save this for future reference

I've updated ambiNilla (v.3.5) to include a signal rate implementation (ambiNilla3~). Works well for fast moving sources

thx for the response @seb-harmonik.ar . I've just fixed it. In short I had a few layers of switches nested within various subpatches. I realized that turning on/off the lowest layered switch was redundant, and it seems to be fine now.

It sounds (sonically) like it may be related to the issue you posted. I'm PD 0.55-0. thanks again!

Theoretically, I'm still not sure why it was causing that issue, But regardless, I'm happy it's fixed

I'm having problems with a strange distortion sound a patch of mine is making, perhaps related to FFT processing.

The patch uses a preset system to change between settings. The system will mute the input to FFT objects during preset changes to avoid audio issues. However, when the preset changes I'm often getting a sort of distortion, which strangely clears up if I add & delete an object.

I've demonstrated it here:

My DAW is looping audio which is sent to PD for processing. The loop is on top of a preset change to demonstrate the issue.

Any clues as to what this could be?

actually macos. APFS filesystem, which i'm just reading is case-insensitive by default.

now i'm a bit worried that other patches I've shared might have similar issues ...

@alexandros thx for catching that! (for some reason my pd runs it ok even with the case mixup?) i've updated the source files for consistency. thx again

@bklindgren I've updated AmbiNilla and it now supports 3rd order (plus 0, 1, & 2) + also fixed a few bugs

thanks for the response!

edit: you're right about the need for multiple specified arrays for tabread~

i think i've got it fixed actually. was confused bc when i first ran the snake~ thru the abstraction i hadn't realized hip~ wasn't compatible. But when i cmd clicked on the error in the console, pd highlighted the *~ or the abstraction rather than hip~... even after i fixed hip~, I think the saved abstraction had populated the incompatibility to other instances in the patch, making the error log a bit confusing...

still not sure why *~ was giving errors....

i'm 'upgrading' some signal wires in an existing patch to multichannel (8 chan).

i keep getting these errors:
canvas: incompatible signal inputs (8x64 vs. 1x64)
*~: incompatible signal inputs (8x64 vs. 1x64)

they seem to happen in conjunction with abstractions within my patch.

all the objects i think are snake~ compatible, except hip~, which i un-snake for

this is the primary abstraction of concern:

any ideas?

I made a patch with corresponding Bela code to transmit data from Bela's analog inputs into a PD patch. https://github.com/brianlindgren/Bela-to-PD-over-OSC