zillaomg maybe you could look into the axoloti convolution object, it works "realtime" and i use it with an IR for double bass

      lokki

      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

          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.

                a month later

                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.

                2 months later

                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 😃

                    ryjobil

                    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

                        7 days later

                        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.

                          a month later

                          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');


















    }

)
                          a month later

                          matt

                          Can we see your code of the Neon FIR filter implementation?

                            Thanks Giulio, works great straight away!

                            ideal for acoustic resonance IR's (it's doing great with bowed string impulse responses) and guitar cabs etc. I find those uses of convolution work better with IR no longer than 50ms, otherwise they start to noticeably smear the time domain. With a 50ms IR and 16 sample buffer it's using 25% cpu and great that it causes no extra latency.

                            I guess the main use for longer convolution would be reverb.
                            Seems to me that latency is not such an issue with reverb. Real spaces always have pre-delay, consider standing 5 metres from the nearest wall, that's about 15ms pre-delay. We'd be able to use longer IRs with frequency domain convolution at the cost of latency. Could it not make sense to deliberately give frequency domain convolution say 5ms to process and make that time up by chopping 5ms from the start of the IR (it would be silence anyway!)

                            I know that workaround may not be great for things like Zillaomgs cymbal IRs but seems like a solution for convolution reverb