It should be enough to copy the source to the board and from within that folder do:
make PD_INCLUDE=/usr/local/include/libpd/Then copy the resulting .pd_linux binaries into the pd-externals folder:
mkdir -p /root/Bela/projects/pd-externals/ #create it if it doesn't exist
cp *pd_linux /root/Bela/projects/pd-externals/If you need more assistance with doing this from the terminal, let me know.
Whoops I was trying from ./pd-lib-builder for some reason.
On second thought I may have compiled from source this way. Will try again when I get home.
Thanks
Recompiled and performance is the same.
I can get away with using an impulse response of about 300-400 ms if the block size is 32.
If anyone has any suggestions they are more than welcome
zillaomg e block size is 32.
Is this the Bela program's block size or the partsize argument you pass to [partconv~] ? As far as I understand from a quick look at the help file and the source code, partconv~ is using single-threaded evenly-partitioned convolution, which is not particularly CPU-efficient. More modern partitioned convolution techniques would split the convolution in block of increasing size. As the convolution is implemented via a FFT, the CPU efficiency increases dramatically for larger blocks, allowing to process much longer (> 10 seconds ) impulse responses, while keeping the latency low (because the first few blocks are small enough). I am not aware of a Pd external that implements this.
You could try increasing Bela's blocksize to 128 and play around with the [partconv~]partition size
giuliomoro Is this the Bela program's block size or the partsize argument you pass to [partconv~] ?
32 is Bela's block size.
I tried various partition sizes on the convolution object and the only way I got it working with a longer impulse response was with Bela's block size at 128, the convolution object at 2048 and a block~ object at 64.
Not sure why this is the case (why it won't work without that block~ object)
Either way the latency is too much, because I'll be performing on it with live cello input.
Right now I think I'll live with the shorter impulse response and try and code it in supercollider in the upcoming months. That will provide more efficiency right?
Thanks for the reply.
Yea, I was actually using the convolution object with Axoloti but that's also using a very short response and it overloaded the CPU with everything else I had going on.
I'm fine having a short response when just trying to get a cello sound but my goal was to be able to select different responses on the fly and improvise with them, e.g., select a longer cymbal and get that texture while playing with the body or with a contact mic.
That's actually the main reason I got Bela-- I thought that the increased CPU and RAM could run everything. I can do some heavier granular stuff which is cool along with some other more CPU intensive stuff but without coding in C it doesn't seem like I'll be able to run everything in the same patch
I'll keep working on it though and also hope that the new axoloti2 comes out soon :-)
If you're willing to get your feet wet in the API the NEON C++ libraries that come with bela have some very efficient FIR filter algorithms built in.
Using the ARM specific versions of the filters I'm able to run 8 512 tap FIR filters in parallel which only consumes ~40% of the CPU. The same filter bank using multiple resolutions costs less than half that. Also I can also use the scope to analyze the spectrum of each filter band while the program is running for only a ~15% hit in CPU.
My point is that Bela is very very powerful and you can get a lot more out of it if you dig in past the user friendly stuff. Right now I'm working on making an easy to use front end for some of the NEON functions to try and help folks out and show them the power of Bela. Keep an eye out for that on this forum if you're interested, and best of luck on your project!
I think you'll get to about 11000 taps using NE10 if you do it all in the time-domain. A partitioned convolution approach would be able to use a frequency-domain approach for the later and longer partitions, comfortably stretching above 10 seconds. However, I am not aware of an open source implementation of this algorithm, but also I haven't searched extensively.
Very interesting. 11,000 is a ton of headroom. I wonder how many more you can get by using the multi resolution or sparse FIR algorithms.
Applying the filters in the frequency domain is a cool idea - recently I had the idea to use the 16n fader bank as a controller for a bela graphic eq. You make the shape of the power spectrum you want with the 16 faders then use NE10 interpolation to create higher resolution versions to multiply with the input signal. Also you could use it as a waveform designer.
I've already made a fir filter bank patch on Bela with 16n as a controller by doing convolution in the time domain. The frequency domain approach is very interesting might have to try it esp if it's more efficient.
Don't mean to hijack this thread, just wanted to share the success I had figuring out how to use the ne10 libraries. Bela rocks
matt If you're willing to get your feet wet in the API the NEON C++ libraries that come with bela have some very efficient FIR filter algorithms built in.
Using the ARM specific versions of the filters I'm able to run 8 512 tap FIR filters in parallel which only consumes ~40% of the CPU. The same filter bank using multiple resolutions costs less than half that. Also I can also use the scope to analyze the spectrum of each filter band while the program is running for only a ~15% hit in CPU.
My point is that Bela is very very powerful and you can get a lot more out of it if you dig in past the user friendly stuff. Right now I'm working on making an easy to use front end for some of the NEON functions to try and help folks out and show them the power of Bela. Keep an eye out for that on this forum if you're interested, and best of luck on your project!
Thanks for the reply!
I'm definitely interested but as I have very little little experiencing coding (my background is in music theory) I don't really know where to start.
I have a tiny bit of c++ experience though not in dsp. I'm a quick study though so if you could point me in the right direction I would definitely give it a shot.
maybe a bit late to the party, but has anybody seen this?
yup, Mathieu was in the masters program with me when he did this. This was before Bela, so he didn't have the advantage of Xenomai scheduling and had to increase the blocksize to achieve reliable performance for long reverbs. Some people have tried running something similar on Bela and got more than 10s stereo reverb with a block size of 32 samples. Unfortunately their code is not publicly available.
Just an update - I recompiled pd to a default block size of 64 and the William Brent convolve~ object works with a block size of 256 with wav files up to 1 second (16 bit 44.1khz)
Not great but works. Will try and tweak it more
zillaomg I have a tiny bit of c++ experience though not in dsp. I'm a quick study though so if you could point me in the right direction I would definitely give it a shot.
I'm going out on a branch guessing that your music theory background gives you more insight into DSP concepts than you might think. I never got deep into music theory, but I started out in the arts before I went into engineering and I was pleasantly surprised how much my minimal exposure to music theory prepared me for signal processing concepts. What I determined is you don't have to be a math guru to "get it". Just add, subtract, multiply and imagine pitches and tones changing over time. If you are comfortable with PD, the C++ just adds some twists to expressing what you're thinking, but you can get it if you have the time to invest in the technical aspect up front.
The coding part is easy, because there is a lot of detail you don't actually need to understand about C or C++ in order to code DSP algorithms on Bela. A lot of the lower level "hard" stuff has been done by a team of brilliant individuals who know it at that level.
By saying the coding part is easy, I don't want to trivialize the steep learning curve, but once you get some basic programs running, then your imagination grows, and your confidence grows with it. It takes time and attention, including time away from creating music.
As for pointing you toward a path, look at Bela examples and study the code until you understand somewhat how it works. Then start to modify it and observe how your changes to the code work out. It will seem slow at first, but if you keep at it you will start to imagine how to use what you are learning to do what you really want to do.
Here are some resources that have been helpful to me over the years of tinkering with this stuff:
https://www.learncpp.com/
https://www.dsprelated.com/ (search forums and blogs for topics of interest)
Last but not least, Bela example code is full of good ideas and coding concepts worth understanding.
My method was to study open source code that was interesting to me, and going line-by-line, searching and reading about any new syntax or concepts I saw in the code that I didn't understand.
I think there are a lot of resources out there where you can balance the amount of technical learning needed against musical creativity. Some things like partitioned convolution with non-uniform block sizes are not unreasonably difficult to grasp in principle, but very tedious to implement in practice. This is more a level of commitment rather than a level of skill or intelligence.
If you don't have the level of commitment needed to develop an open source project for this, then welcome to the club of mortal individuals who wait for somebody with the right combination of time, talent, money and combination of interests...or much much faster hardware 
Thanks for the response.
Yea I started some generic C++ courses and I see that there's now a C++ course in the Bela forum.
Definitely will take a look and start experimenting soon.
In regard to the convolution aspect of it: could you point me to any resources there? I guess don't fully understand how it works in theory
zillaomg In regard to the convolution aspect of it: could you point me to any resources there? I guess don't fully understand how it works in theory
I struggled with this in my undergrad studies and the lightbulb didn't really come on until I tried to implement a DSP convolution algorithm -- then everything fell into place and made it easier to understand the continuous time convolution as well.
I have been searching the webs for a good intuitive explanation because it is a fairly simple concept that has been over-complicated by academics. I found one that I thought particularly good for just understanding the principle:
https://aha.betterexplained.com/t/convolution/679
Wikipedia includes the formal definition and a lot of different sections describing mathematical properties and its applications, as well as some good animations, but there is also a lot to digest there.
https://en.wikipedia.org/wiki/Convolution
A couple quick tips:
1) Consider and understand the concept of a system's impulse response.
2) Consider that every continuous and discrete time signal can be thought of as an impulse train, in which the impulses are spaced closely (infinitesimally close for continuous time, or on intervals of sampling period for discrete time), and scaled by different values forming the base function.
Eyyyyy
So coding in C++ was a bit overwhelming for me but I did get a decent version going in Super Collider.
Code is here if anyone's interested. Am new to text based coding so any general practice/logic/tidyness tips
are appreciated.
I ended up using a wrapper for PartConv for convenience.
(
s = Server.default;
// Set up options for the Bela
s.options.numAnalogInChannels = 2;
s.options.numAnalogOutChannels = 2;
s.options.numDigitalChannels = 0;
s.options.maxLogins = 4;
s.options.blockSize = 16;
s.options.numInputBusChannels = 2;
s.options.numOutputBusChannels = 2;
~newpreset;
~impulse = "./cello.wav";
~ezConv = EZConv(~impulse, fftSize: 512);
s.waitForBoot {
//drysignal
{
var dry;
dry = AnalogIn.ar(1) * 0.77;
SoundIn.ar(0) * dry;
}.play;
//synthdef for convolution
SynthDef(\wet, { |out|
Out.ar(out, SynthDef.wrap({
~ezConv = EZConv(~impulse);
~input = SoundIn.ar(0);
~blend = AnalogIn.ar(1) * -0.55 + 0.55 * ~input ; // input * blend pot
~ezConv.ar(~blend, mul: 0.5);
}))
}).add;
~wet = Synth(\wet);
//re-run this task when changing impulses
~task = Task({
1.do({arg i;
~wet.free;
~ezConv.free;
~ezConv = EZConv(~impulse, fftSize: 512);
~wet = Synth(\wet);
0.25.rrand(0.75).wait;
})
});
//reading analog in from server and sending to client
~ctrl = {
var a0 = AnalogIn.kr(0);
SendReply.kr(Impulse.kr(10), '/ctrl', [a0]);
}.play;
~preset = 1.0;
~currentpre = 0;
OSCdef('listen', {arg msg;
~preset = msg[3].linlin(0.0, 1.0, 0.0, 1.0).trunc(0.07);
// [~preset].postln; // used for testing
// this is the case loop that evaluates the analog in and changes the impulse depending on value
p = ~preset;
x = case
{ (p <= 1) && (p >= 0.97) && (p != ~newpreset)} { y = 1; ~newpreset = p; y.postln; ~impulse = "./cello.wav"; ~impulse.postln; ~task.reset; ~task.resume;}
{ (p <= 0.90) && (p >= 0.81) && (p != ~newpreset)} { y = 2; ~newpreset = p; y.postln; ~impulse = "./cymbal.wav"; ~impulse.postln; ~task.reset; ~task.resume;}
{ (p <= 0.77) && (p >= 0.70) && (p != ~newpreset)} { y = 3; ~newpreset = p; y.postln; ~impulse = "./opera.wav"; ~impulse.postln; ~task.reset; ~task.resume;}
{ (p <= 0.66) && (p >= 0.55) && (p != ~newpreset)} { y = 4; ~newpreset = p; y.postln;}
{ (p <= 0.50) && (p >= 0.40) && (p != ~newpreset)} { y = 5; ~newpreset = p; y.postln;}
{ (p <= 0.37) && (p >= 0.25) && (p != ~newpreset)} { y = 6; ~newpreset = p; y.postln;}
{ (p <= 0.20) && (p >= 0.12) && (p != ~newpreset)} { y = 7; ~newpreset = p; y.postln;}
{ (p <= 0.09) && (p >= 0) && (p != ~newpreset)} { y = 8; ~newpreset = p; y.postln;}
}, '/ctrl');
}
)I have pushed a neon-based convolver to dev right now : https://github.com/BelaPlatform/Bela/tree/dev/
See the new library libraries/Convolver and the example Audio/convolver.