#21

decided to try and hand-fettle the (surprisingly readable) faust-generated C for that pitch tracker into something that will run with bfin fract arithmetic - thanks again for the link…

#22

got a working zero-crossing pitch detector hacked together in C now (weird octave skips and all) - it’s working as a jack client using floating point arithmetic. So next step - I’m going to design a pretty trivial layer that enables to simulate the fractional arithmetic primitives (mult_fr1x32x32 et. al) using floats.

That way from now on I can prototype & debug dsp blocks using jack/linux and then run the exact same code on aleph - wonder if @zebra has something like this already? Getting this algorithm going with linux/jack tools on hand was soooo much less painful than working directly on the aleph - going to invest a bit of time in tooling here…

3 Likes
#23

yes i made a little portaudio wrapper for aleph dsp stuff, long ago, it’s in the github:

#24

Had a look at dsp/null today and tried smashing it a bit to compile - couldn’t make it go unfortunately.

Meanwhile I already got the fract32 pitch detection up and running on jack/linux with some crude hand-rolled simulated bfin fract arithmetic. Just in process of factoring the new dsp block out of the simulator, then moment of truth - try out some simulator-developed code on the aleph itself…

#25

Somehow that actually worked! Got some slightly rattly/glitchy pitch detection on the aleph now - something tells me there should be some kind of digital schmidt trigger to get this to work better on a guitar signal, also maybe IIR filters are not optimal. But hey - will be really interesting to see what happens when I plug this pitch detection into grains module.

Only trouble is I may need to refactor scrubtap to look more like the puredata rotating head pitchshifter example - but simulating on linux first feels more like I stand a fighting chance now…

2 Likes
#26

I discover developing on linux with an hand-rolled simulator can also give a false sense of security - everything seems to work splendidly now in the simulation environment. Nailed down a bunch of fiddly mistakes in my C code I could never have found working directly on the aleph…

My resident gremlins were clearly so awed by the new tooling innovations they have run to hide deep inside the guts of the blackfin itself. (possibly some ancient evil lurks within the infamous ‘40 bit accumulator’!?)

#27

i was going to mention something about this… it’s pretty crucial that your fixed-point math layer is actually doing fixed point math. doing float math and casting the result will not cut it, especially if you are using recursive processes and/or dealing with very small values.

the 40-bit accumulator is a related issue… basically if you multiply 2 fract32 quantities, you want to shift each one down to 20b and cast to a 64 datatype, then multiply, then shift the resulting 40b value back to 32b… if you want to get an accurate picture of the blackfin rounding error.

when possible, it’s much faster and more predictable to use 16b operands anyways.

#28

Ha - I woke up in the middle of the night and scrawled something like this out:
fract32 better_mult_sim (fract32 x, fract32 y) {
return ( (long)(x>>12) * (long) (y>>12) ) >> 7;
}
So if your guess is as good as mine then I will try it! What would be really handy would be to figure out how to run some simulator debug comparing bfin math primitives to the mockup byte-for-byte.

Ashamed to say have been flying blind hacking on the bfin and don’t currently know any way to do ‘hello world’ from the bfin, through the avr32 and out through the serial usb device. If I can figure that out then I can get a much better understanding of the fractional math primitives…

Currently using fract32 mult_fr, add_fr & sub_fr for everything, believing I had built up a totally coherent mental model what those guys are doing (and wasn’t running out of cycles). Turns out there are some gaps in my understanding…

Also I read somewhere online that even integer / and % are very expensive on the bfin - does that information sound correct to you? Was previously assuming that the compiler is smart enough to know that, e.g:
x / 256 == x >> 8

#29

i don’t understand any of what you guys are talking about… but i’m very excited to test this out when it’s out there with multiple voices :slight_smile:

2 Likes
#30

Not sure now about the possibility to run 4 ‘grains’ but been working with two for a couple of weeks now…

It is now a lot more polished & musical-sounding than the piece of junk I posted in December. My original goal with this project has now been reached. That is to say I have an aleph module which is capable of simultaneously producing delay, chorus, flange, pitch/volume tremolo, ringmod, just-useable granular pitchshift, functions as a sampler and even passes as a crude resonator (kind of a poor man’s karplus strong I guess). Haven’t even had time yet to see what kind of crazy creations can be strung together when you bring bees into the equation…

High time I made another release, though first I want to try an experiment with cubic bspline interpolation on the delays - could be a big win in terms of overall sound quality…

1 Like
#31

funny, i was just thinking i needed some more cubic bspline interpolation in my life :wink:

very excited to try this, 2 grains is enough for me, I’ve managed to wring a hell of a lot out of Lines 2 delay buffers.

with the resonator how tuneable is it? I like using Lines as a resonator but the rough granularity of the del time setting from bees is a bit limiting

1 Like
#32

I’m excited about the new version but I didnt give any feedback on what you posted before

Sorry about the lack of enthusiasm on my end

#33

Well I appreciate the original version was a bit ratty - was important to me to get something out at that point. Didn’t want to start flooding @zebra with pull requests for potentially dodgy code - posting updates here is helping me impose a bit of structure on such an open-ended project, whilst getting some external input on some of the tricky topics in embedded dsp…

Just smashing a bit more inside linux simulator on the adaptive filter for pitch detection circuit - think I have finally figured out where numerical error was creeping in and blowing things up…

1 Like
#34

so currently I am using a fine time constant of 1/256 ms. That feels like the right scale for working with grain lengths (max = 128ms). Seems to be adequate for tuning resonators. The backend can support resolution down to 1/256 sample so ultra-fine control would be trivial to hack in there if required…

I guess that translates to roughly 1/20 semitone at 1KHz…

#35

I’d love to hear any audio from your tests!

#36

OK - nailing down integer arithmetic cubic interpolation was a total snap using the pdf @test2 refers to in his code, and my linux-simulated bfin primitives! Literally 10 minutes of caffeine-fuelled keyboard mashing and it was done. Just needs a little tweak now to get rid of some divide signs…

1 Like
#37

Before releasing audio I should warn you the scientific method demands that I to play the benny hill theme at 450bpm through the aleph for 3 solid hours after every code change whilst manipulating those beautiful tactile encoders with my toes through each of the 2^347929 possible permutations of bees parameters.

Makes for pretty tough listening…

3 Likes
#38

Getting excited now - just managed to free up enough cycles for 2 cubic-interpolated grains by leveraging the blackfin’s built-in circular buffer accelerator This has the effect of making everything sound less lo-fi/grainy, which I am VERY happy about!

Going to keep adding bells and whistles until I run out of cpu cycles, then finally make a release. The following things could really take this module to the next level of generality and usefulness:

  • Transient/noise-burst generator for electronically triggering karplus strong
  • grain envelope trackers
  • offsettable pitch tracking oscillators using the already-calculated grain pitch & envelopes
  • input selector for mixer channels 3&4 (currently hardwired to ADC 3&4)
  • Route CV inputs to the mixing matrix.
  • input-switchable envelope detectors for the CV outs
  • adjustable lowpass IIR filter on grain output
3 Likes
#39

Wow… wow! Really exciting! Physical modelling synthesis + envelopes and pitch tracker! Just what I was dreaming about.

1 Like
#40

so many great ideas!