panostsigkos I guess it's the "block~" that creates the issue, correct?

not necessarily, it may well be what you have inside the patch that does it 🙂 what values of [block~] are you using?

    Thanks for the quick reply. It's "Block~ 1024 1 16". I am using it as it appears in the J.07 Oversampling example in Pd Help, but without the "buttercoef" object.

    That's a lot of oversampling really ... it increases the CPU usage by 16x, and also, by processing the signal in blocks of 1024, it does not get distributed evenly, so that you may end up getting underruns while the CPU is not actually at the limit.
    Can you please try with smaller values of oversampling (like 4), and also use as the first argument to the [block~] a value that is the same as the block size that you have in the Bela settings (default 16)?

      giuliomoro I put "block~ 16 1 4", recalculated the filter parameters and now bela is not complaining. However, I am still getting alias. Should I increase the block size on bela and in my patch?

        You can try to increase the oversampling now. If you were to change the blocksize , set the same value in the Bela IDE and in the [block~] object, and there is no real advantage in going above 128.

        panostsigkos vsaw~.pd_darwin

        You would need to recompile it for ARM. Where is the source code for it/what library does it come from?

            Wow! Thank you!!! However, I don't think I can find any band limited oscillators like "bl.vsaw~" in the zip file.

              giuliomoro You can try to increase the oversampling now

              I left block size at 16 and increased oversampling to 8, readjusted the filter coefficients and the aliasing is almost imperceptible. This is all very helpful.

                panostsigkos Wow! Thank you!!! However, I don't think I can find any band limited oscillators like "bl.vsaw~" in the zip file.

                that's what the library built ... turns out the bl. ones are just abstractions. They can be found here.