#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 !!!

#67

woop! downloaded… got some crazy pitchbending layered delays out of it and tremelos,
will get to learning it properly this weekend…
amazing work

#68

wait

I just came here to ask if I was missing the hex file…seeing that it works for you (and recalling the discussions about bees ops)

do i just use the bees to run this app?

#69

yeah…all in bees,
i just cleared my current scene. then loaded the module.
then quickly connected some encoders to scrub pitches and echo time… fun fun

#70

it’s why i sadly can’t get on with using the @Test2 programme, i have too many staple systems set up in Bees with lines that I don’t want to have to keep re-flashing the unit with a new hex file. just want to jump between scenes in seconds

2 Likes
#71

excellent
thanks duncan

let’s see what we manage to concoct with this

2 Likes
#72

Can’t wait to try this out tonight ! So awesome sharing this !

#73

just been using the echo and now i want to listen to every song thru this delay
so many sweet spots

havent even decided on control schemes or touched the matrix / cv / resonator
yet

this is a huge accomplishment!
incredibly useful already

#74

OK so thanks everyone for contributing to the discussion here. Going to move on to some other projects now for a bit - expanding the communication aleph->host is an important feature for me so that wll get some attention in the coming weeks.

First, though, a quick stop to break out grains’ pitch & envelope trackers into a simple analysis-only module for SPI testbench as discussed earlier in this thread…

1 Like
#75

Deeply excited about trying this… as soon as my aleph returns from the shop :cold_sweat:

1 Like
#76

Great stuff! still exploring the module and very excited by the possibilities!

#77

… meanwhile I finally got time to start skimming my copy of the book microsound by curtis rhodes. This really hits home what a terrible name is ‘grains’ for this strange little contraption. That working title was based on a loose desire to somehow generalise an early pitchshift prototype with a larger number of scrub-head-pairs (somewhat cloud-like) and some other interpolated delay hacks.

Now I start to learn a little about ‘real’ granular synthesis it seems to me that the name ‘grains’ deserves a total reboot at some point in the future when block processing is available, aiming again for something simultaneously simple & powerful.

There might be a more minor update sometime in the not-too-distant future to take advantage of some new bees features I was hacking on this last week or so with @zebra’s help.

Still quite a bit of programming before I complete my own dream rig and get to actually trying to make music on it. Until then if anyone finds a place for this module in their own music making I would be totally stoked to see/hear the results!

2 Likes
#78

i’m finishing a track at the moment that i’ve been using it on. will post shortly :slight_smile:

3 Likes
#79

I finally got a chance to try this out and it sounds great! (still having sound quality problems with lines), but I managed to crash my aleph twice just tweaking scrub/delay parameters heh

#80

aieee! ok so that actually makes sense because directly tweaking delay times does engage a ‘mode’ inside the code to slew the delay time towards the specified value for, like 30ms or something. It has to switch of after so that buffer playback (governed by the speed param) can run as usual. All the other slews always on. Can you reproduce the crash tweaking any other groups of params not including delay?

There’s some talk of a type of ‘cpu counter’ for aleph - if we can nail down that feature I may be able to make a bunch of small optimisations to claw back enough cpu cycles to cope with the cpu burst required to handle, e.g. simultaneous tweaks to both grain delay times…