#47

Can we assume stuff like pitch detection can be turned on/off easily? Everything has the possibilities to be manipulated by bees right?
And let’s be honest, the Lines documentation was never exactly ‘extensive’ :slight_smile: just a list of parameter descriptions with hardly any guidance about how to use them and no tutorials.

1 Like
#48

well I hope the new version lives up to expectations! Think the scrubtap locking is solved - I realised you need to lock onto some multiple of the period of half the detected pitch, because there are two read heads in rotating-head pitchshifter. Needs a listen with fresh ears after sleep I could be fooling myself.

There’s another subtle bug with the sampler functionality - when you flip from stalled one-shot to looped playback it comes in without crossfading so there’s a pop. Don’t want to release without a workaround for that…

1 Like
#49

@rick_monster that’s because cv inputs are connected to the avr32, not the blackfin (ADC operator in bees)

#50

Also, don’t connect cv out to audio in!!! :boom:

2 Likes
#51

a cautious ‘yes’ - everything has the possibility to be manipulated by bees but I have only been tweaking params ‘by hand’ for my testing - the list of module params has been totally unstable so far. Didn’t want to put in any time building bees networks that will be incompatible with tomorrows module build.

I disabled much of the parameter slewing in the belief that slews were eating too many cpu cycles. Kind of wondering now which/how many crucial slews I could put back in for controls that can be usefully driven dynamically. Come to think of it there’s still a crucial param missing: bees->patch_matrix. Currently there would be no way to echo CV in -> CV out.

All that said, this thing is inherently less tweakable than e.g lines. Think of it less like modelling clay and more like a spring-loaded-swiss-army-knife-gadget. Started drawing 2 schematics last night - toplevel & internal to each ‘grain’ (grain is now a complete misnomer). Scans of those will go out with the binary release, along with textual parameter descriptions.

2 Likes
#52

thanks for the heads up! kind of thought this was a bit like patching my oakley modules where you can pretty much randomly just plug everything into everything without damage (as long as the speakers aren’t cranked of course). Will have to be careful with the aleph audio ins when I finally get the modular back I guess…

Aleph: reading DSP params in BEES
#53

By the way something that has been troubling me and I got a bit lost sifting through source code/docs for a clue - is there any mechanism to shovel data back from module into bees? As far as I could tell the communication between bees network & bfin module is one-way-only…

for example I might want a bees operator that:

  • waits for a trigger input
  • polls the module for some interesting value (e.g current detected pitch)
  • passes on that value to the next operator in the network

or have a module trigger the network on rising/falling edge of an audio gate signal.

Aleph: reading DSP params in BEES
#54

yes. avr32 can get parameter values from the blackfin as well as set them.

protocol:
[ https://github.com/tehn/aleph/blob/dev/common/protocol.h#L20 ]

blackfin SPI state machine:
[ https://github.com/tehn/aleph/blob/dev/bfin_lib/src/spi.c#L115 ]

avr32 library function:
[ https://github.com/tehn/aleph/blob/dev/avr32_lib/src/bfin.c#L350 ]

currently, BEES uses this to populate the initial values of DSP parameters after loading a module.
(here: [ https://github.com/tehn/aleph/blob/dev/apps/bees/src/net.c#L980 ] )

but the idea was to use it for analysis parameters as well; they can be polled any time.

i guess we should make a bees operator to do this explicitly.

#55

Since you point out CV ADCs are hooked up to the avr32, the obvious hack is physically patch one of the CV outs back to CV in - that also lets me use BEES to test whether my patch_matrix->CV_out code is hooked up right.

Once module release is out I’ll be keen to work on BEES op for communicating with a connected laptop via osc (lets me trigger sampler or resonators with my existing boomerang-compatible lisp/linux midi looper). Even better - make any BEES param respond to osc from a host laptop/embedded linux device.

If people like the ad-hoc ‘patch matrix’ paradigm in the new module it would be good to formalise that code and integrate with BEES. BEES module for polling analysis params could index the patch matrix. The bfin module should be able to assign namestring for each patch-matrix-index without building that knowledge into bees.

1 Like
Aleph: serial bus control
Aleph: reading DSP params in BEES
#56

< replies moved to linked topics, above >

#57

YES!!! THIS !!! A DREAM!!!

#58

i put a pretty good amount of work into making sure that polling DSP parameters from bees is already easy to do, as described above. the only reason there is not a polling operator already, is that none of the current modules do anything interesting with their param values in realtime. something simple like tracking amplitude and zero crossings, we could implement right now; seems like rick has already done so; maybe he’d be interested in breaking out that functionality to a separate module.

more complicated/useful analysis, like good pitch/timbre detection, needs more groundwork, which is happening in the background (1st step - block processing, nearly done; 2nd step - FFT, i have some bfin-ready code, but needs the block interface; 3rd step - centroid/flatness extraction, i’ve done it before and it just needs a port.) more updates on that next week after the NAMM crunch.

just… bear in mind that BEES can only poll so fast. it is slow compared to the audio rate. for example, if you literallly implement the gate-triggering scheme described above, you will be effectively downsampling your audio gate input from 48khz to 1khz, and might miss a lot of stuff.

1 Like
#59

yup as soon as grains module docs & binary release are done I can very quickly break amplitude/pitch detection dsp blocks from grains into a trivial analysis-only module for SPI testbench…

3 Likes
#60

cramming in all the features I want is starting to feel impossible without blowing the cpu budget under certain conditions. just rewrote the the patch matrix a bit better and think I made some gains but hammering the sampler functionality really hard still seems to overload the bfin. I need to test with second grain disabled and verify the program logic is definitely correct, and that this is a case of running out of cpu time. Maybe need to refactor so I don’t use fract32 arithmetic where 16 bit would do…

Documentation is done but this module still needs more testing and some optimisations to be release-ready.

1 Like
#61

Maybe it just doesn’t need soooo many features ? :slight_smile: especially if they are difficult to manipulate via bees? Is the processing for bees and the modules shared…e.g. If you’re running out of cpu does that mean there’s none left for control… or are they independent?

1 Like
#62

cpu seems to be spiking when scrubbing (pitchshift) over an echo crossfade (sampler loopback). Seems to be a very close call. The way I’m doing slews, control calculations are always or never performed. This should in theory make timings more predictable (though it is wasteful - IIRC lines mixer slews switch on and off when there is/isn’t work to do)…

One optimisation I am going to try is use linear interpolation for second read when crossfading and cubic for the first read. My gut feeling is that will mitigate the cpu spikes, whilst retaining 99% the sonic benefits of cubic interpolation…

#63

got a couple of possibilities to try out quickly when I’m back at the device this evening. linear-only crossfades & linear+cubic crossfades. If linear-only actually sounds ok then I will run with that for first ‘proper’ release. otherwise hmpphh I dunno - don’t really want to think about a major refactor right now but that may be the only way.

kind of leaning towards thinking there would be precisely zero audible difference if the audio path through each grain became 16 bit. Even cubic interpolation must be a distortion bottleneck by a couple of orders of magnitude…

1 Like
#64

Release time!

http://rickvenn.com/grains-0.0.3.zip

5 Likes
#65

although i don’t understand it, i like a lot the schematics
congrats for your (hard) work. thank you for sharing it

1 Like
#66

release coinciding with a day off work + impending snow storm = perfect timing

will test for sure
thanks @rick_monster !!!