Bela!

[Transmogrifox]

Got a Bela a little while ago:
bela.io
Just thought I would share what I'm up to.

Bela project for code used in the demo is here for anybody who has a Bela, or wants to re-use on a different platform:
http://cackleberrypines.net/transmogrifox/src/bela/05_MultiDelay_16_Mar_2017.zip

I also just finished modeling the classic inductor wah, but don't have a video yet.  I still need to come up with a computationally efficient way to apply frequency response pre-warping to get the sweep range correct, but it's 99% there.  It sounds pretty convincing as-is:
http://cackleberrypines.net/transmogrifox/src/bela/inductor_wah_C_src/
Here's the set of frequency plots for a Vox V-847 wah voicing:

[markseel]

Wow nice job!  How easy was it to use this platform for effects?  What do you think the analog input to analog out latency is?

[Transmogrifox]

Bela is super easy to use for guitar effects.  Having the 8-channel SAR ADC for control inputs and having all the low-level stuff handled for real-time performance makes it a breeze to get to work on more interesting stuff.

The other potentially useful feature is that the digital I/O is synchronized with the audio rate so digital inputs and outputs can be written exactly timed to the resolution of a single sample.  You get a digital buffer that pretty much looks the same as an audio frame buffer -- you have a digital "frame" for every audio frame, so you can (for example) drive a trigger immediately upon detecting some condition in the audio or on an SAR ADC input...or maybe more interesting do real-time stuff to audio synchronously triggered from digital I/O.

I haven't started making my code for reading/writing presets yet, but the Linux underpinning makes it really attractive for easy file I/O.  These can easily be uploaded & downloaded through the web interface. Also there is the potential to develop a web gui in which somebody could tweak knobs and make presets from a laptop or smart phone or something...or even have the sound guy messing with your sound through a tablet.

For example of development time to show-time -- a tremolo effect is a 5 minute job. 

They claim the conversion latency of the audio CODEC is about 390us AD conversion + 470us DA conversion, so you start at 860us with the CODEC.

If you have a smaller, less CPU-intensive project you can run it at 2 sample processing latency at 44.1 kHz -> 860us + 45us = 905us.

I run my project at 8 samples processing latency, which comes to pretty much 1 ms, so it's hard to see the value in going any shorter than that.

In my intended final project, I want to have a "pre" and "post" DSP loop, so the two channels are intended to connect in series instead of stereo, so my final latency when running both in serial will be 2ms.

I did this and there is no way in H3!! I can tell the difference when I stomp by effects loop bypass on my amp when it's clean (pass-through).  The +2ms latency is completely undetectable by me.

Now for what the Bela project calls Analog inputs/outputs are the SAR 8-channel converters.  There is only a single sample conversion latency, so you can get latency down to the processing latency.  If using analog anti-aliasing and reconstruction filters the latency is pretty much the group delay of your filter + (say 8 samples processing delay) 181 us.

When I calculated the possibility of running the SAR at a higher sample rate (2 audio channels at 88.2k) and application of an FIR anti-aliasing filter and decimation to 44.1k, I get about the same latency as the CODEC when using an FIR with a reasonable number of taps.

All that said, I haven't yet run the test where I generate a pulse on the output and record it on the input and measure the latency, but what they claim is believable.

[markseel]

Those are some good latency numbers    1.9 msec input to output latency is really good.  That real-time modification to embedded Linux really seems to work well then.  It's an interesting platform for real-time sensors, audio, control, etc.

[Transmogrifox]

Yes, it works well for consistently hitting deadlines.  A couple things that would make a more bare-metal approach attractive (such as your X-CORE project) are these:
1)  Currently Bela does not start the audio DSP until Linux has booted.  In the current platform this takes about 30 seconds for everything to come up.  For me it's ok because it takes my tube amp that long to warm up, so by the time I get my guitar tuned and plugged in it's ready to rock.
2)  Overhead CPU usage just for getting samples in and out is significant.  For example with 8 sample buffers about 15% RT processing capacity is already dedicated to the overhead processes.  On the other hand, it's a 1.2 GHz processor so basic effects don't add much on top of that.  There is a lot of processing that can be done within 50% CPU utilization. 
3) After about 75% RT CPU utilization Bela becomes unresponsive on the network so you can't login and modify it.  Probably the best work-around is to assign an I/O to bypass the processing loop to free CPU cycles for the kernel mode stuff when accessing the device is necessary.

And...here's a video demonstrating the VOX-V847 DSP model I developed.  I'm tickled pink    When I graduated high school I hated math and spent 2 years pursuing a non-math related degree.  Then somehow I decided engineering was for me and math is ok...so below could alternatively be titled "MATH IS FUN!!!"

[ElectricDruid]

I also just finished modeling the classic inductor wah, but don't have a video yet.  I still need to come up with a computationally efficient way to apply frequency response pre-warping to get the sweep range correct, but it's 99% there.  It sounds pretty convincing as-is:
http://cackleberrypines.net/transmogrifox/src/bela/inductor_wah_C_src/

Nice work!
If I were you, I'd just stick a look-up table between the control pot/ADC input and the frequency and do the "pre warping" there. I know there are more serious-digital-filtering-guru ways to do it, but I'm not those people In terms of "computational efficiency", doing the sums beforehand and then just looking the answer up in a table when you need it can't be beaten! (This is what I learned doing "hard sums" on a PIC - anything beyond a multiply, pretty much!)

HTH,
Tom

[Transmogrifox]

Thanks Tom.  I did end up approximating it with a 1/x function.  On a >1 GHz processor the little bit of twiddle-fudging is insignificant:
gw = 4.6-18.4/(4.0 + gp);
This roughly approximates the "tweak" on the coefficients over the range of interest and saves me or the CPU a lot of math.  Either I have to work it out to simplify it, or the CPU would have to brute-force through the full coefficients computation on every sample.

The CPU stats don't visually move by enabling or disabling this computation.  One might consider something else if implementing it on a different (lesser spare CPU time) platform.  For a Beaglebone black this is just batting eye lashes.

I just got the Fons Adriaensen Zita Rev1 reverb working.  I'm really liking this reverb.

[Firesledge]

You could simplify it again using a low-order polynomial:

gw = gp * (1.15 + gp *  -0.235             ) order 2, on the 0–1 range
gw = gp * (1.15 + gp * (-0.26 + gp * 0.034)) order 3, on the 0–2.5 range and probably slightly more.

[Transmogrifox]

You could simplify it again using a low-order polynomial:

gw = gp * (1.15 + gp *  -0.235             ) order 2, on the 0–1 range
gw = gp * (1.15 + gp * (-0.26 + gp * 0.034)) order 3, on the 0–2.5 range and probably slightly more.

Thanks for working that out.  Looking at the plots the order 2 approximation looks plenty good enough considering what my ears will hear.

That will be much faster than a 1/x operation for something that is a rough approximation to begin with.