Hey, I'm fairly new to the concepts around block size, so this may be an entry level discussion.

I'm working a pd patch, essentially attempting to make a modal polysynth/vocoder.
It takes input "exciter" signals (external audio, noise and oscillators), runs them through a fft-filter (copied from the example 3.8.2.1 Filters http://www.pd-tutorial.com/english/ch03s08.html) and then runs them through a pitched-feedback delay (Karplus).

It uses the following patches:
_main.pd - patch with analog-in controls and an 8 voice poly synth structure. default block size.

Karplus - an abstraction that runs "exciters" through fft-filters and a pitched feedback loop. default block size.

FFT-analyse - a fft-filter abstraction (pictured) which uses a block size of 512 with 4 overlaps [block~ 512 4]

The patch works fine on a computer but has underruns and disconnects when running it on the bela. I've tried changing the Bela settings to a number of different block sizes including 64, 128, 512, 1024 (just taking shots in the dark) also playing with block size on the pd patches but I get 'bad vector size', 'overrun detected' or 'The sample rate of analog and audio must match. Try running with --uniform-sample-rate'. I tried putting --uniform-sample-rate in the command line arguments too, but no luck.

What should I try next here?

Thanks!

alt text

    kyle 'The sample rate of analog and audio must match. Try running with --uniform-sample-rate'

    this is probably because you changed the sampling rate of he analog channels . That is supposed to stay at its default value (22050) when running Pd on Bela.

    kyle 'bad vector size'

    I guess that's a Pd error, did you try to put a [block~] object in a subwindow containing [adc~] and/or [dac~]?

    kyle 'overrun detected'

    I guess you mean "Underrun". That normally means one of two things (or their combination):

    • your peak CPU usage is too high
    • your average CPU usage is too high

    Given how you have a step size of 512/4 = 128, I would expect that if you select a block size of 128 on Bela and you still have underruns, it probably means that the average CPU usage is too high. Could you send the whole patch? If the Karplus-Strong uses a [block~ 1], then that may also be a huge CPU sink.

          Hey,
          Ok- I set the analog sample rate to 22050 and Bela's block size to 128. I removed all [block~] objects except for the one in the 'FFT-analyse' abstraction, which has no [adc~] [dac~]. That abstraction is used for filtering audio by the abstraction 'Karplus', which does contain an [adc~], but I assumed because they are separate files it should be fine. The Karplus-Strong patch itself doesn't contain a [block~] object.
          Here's the patch: https://github.com/kyleluntz/Modal

          Hello. I am building a synthesizer and in order to avoid aliasing I upsample the subpatch where the oscillator and the filtering is. This results to "Underrun" errors and terrible sound. I guess it's the "block~" that creates the issue, correct? In this case, how can I avoid aliasing? I am running Bela on 22050Hz.

            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.