@Obineg said:

the max external for example does not support signal input, therefore a custom patch is there also preferred.

why?

only reason I can think is if you wanna do FM, which is unlikely. In the code we have signal ramps by the way and it's more efficient

Here's a revised version, there were minor mistakes...

see:
triple-nested-allpass-2.pd

here's the CSound triple nested example from that tutorial translated to Pd using objects from ELSE.

see
triple-nested-allpass.pd

from the referenced nested allpass structure, this is what I make of it...

see nested-allpass.pd

what you need for reverbs is not a 1st or 2nd order allpass filter, but an allpass reverberator with a delay time, so forget about H14. Here's a proper allpass unit from my tutorial

This is where the example is and I'm sending another screenshot as the one before isn't showing somehow

Hi, I have a deep section on filter theory in my tutorial, and how to build some reverbs with it and comb filters. It is part of the ELSE download!

Screenshot 2026-01-13 at 19.48.07.png

Also, note that [rev1~] uses a series of allpass filters in Vanilla, but not a nested one. Give me a minute and I can try and make nested ones.

@Ice-Ice by the way, please don't use illegal arguments in inlet/outlet objects, it's not a good practice.

mine might be crappy too, see [else/grain.live~]

For the record, formant~ was now also added, so I have formlet~, formant~, vosim~ and paf~ (all with multichannel support) already inclued into ELSE, and I'm gonna stop here for the time being...

@ddw_music Thanks for the clearer explanation.

To reiterate: the code is exactly the same on any OS. That was the point of my question “what Windows code?” — to indicate that there is no such distinction. I was not asking anyone to debug my code. I was asking for a more careful identification of the actual issue, rather than assumptions about OS-specific behavior that does not exist here.

If you're gonna claim something, you gotta have something to back it up...

I don’t have access to Windows. I haven’t used it for over two decades. This is volunteer work, and I would expect a minimum level of respect and collaboration instead of being blamed because early, experimental code is not yet working on Windows.

Making confused claims without being able to properly test or report the issue is not helpful. It did not feel to me like there was an intent in trying to help; it felt like complaining, while also stating I shouldn't expect people to debug the code for me...

If there is no interest in helping—and not even in supporting the work financially—then it’s better to disengage. So yes, sorry if I wasn’t patient enough in my explanation.

And the most incredible confusion here was to assume I had a different algorithm that wasn't supposed to be called "paf", which was "invented by someone else" (who cares anyway?). So, to be cristal clear, this was simply a bug on windows where, for some obscure reason outside of my reach, the compiled code behaved differently. This was supposed to be evident when I, for multiple times, proved that the object was working as intended on macOS. So it was clearly the same technique/algorithm.

Having said all that, I’ve now implemented multichannel support in the object and asked an AI for hints about potential cross-platform issues. I made a few changes and tested them on a virtual machine, and everything now seems to work.

I honestly don’t know what, if anything, actually fixed the problem. I didn’t really touch the paf source code itself; I only made some minor changes to the buffer.c dependency.

see https://github.com/porres/pd-else/actions/runs/20669314244

And a screenshot