Yes I got that afterwards: Grain 2 was using the effect bus as a source, which explains the effect I got. It becomes a bit crazy when it is sent again into the effect bus. Feeeeedback, some sort of ascending or descending short delay. I’ll keep writing about what I find in here. It almost all makes sense to me now, after a whole day of tryouts. I am about to try and create a scene for it, possibly with a Grid. Or maybe I should wait for an even more stable version?
Ha - ok so i couldn’t even see any way that hardware-accelerated 24.8 multiplies could help with 24.8 addressed delay line. But grains grew out of me exploring DSP as a total beginner so yeah - probably still missing a lot of tricks!
The patch matrix concept is still confusing because UI is bad (needs some work on the bees side). Patch matrix indices will, in future, display the name of where the ‘virtual cable’ connects to rather than a number 1-12 or whatever it is now.
Be warned I may break scene compatibility in next release - dunno how easy it would be to then migrate complex scenes to the new version.
Patch matrix enables patching stuff back into grains inputs, e.g:
- ringmod by patching the LFO to the AM grain input
- karplus-strong by setting up a regular feedback delay & patching noise-source to grain audio input. When you turn off scrubbing, the scrublength becomes a fine-adjust for delay time
- FM tracking-synth by patching the pitch-detect oscillator of one grain to the FM grain input with envelope enabled (or try AM grain input with envelope disabled)
- Tracking synth by patching the pitch-detect oscillator of one grain to mixer input 3 or 4 with envelope enabled
It’s all somewhat baroque… Would make a lot of sense if I release a demo scene showing how to statically patch all the canonical settings. These use-cases were the single design consideration that drove development, so one way to understand the program better is to be familiar with those. Having said that the reason I wanted to make this module was to explore all the in-between possibilities…
I could reproduce all of these, indeed, except for the Karplus-Strong one: I guess I have another way than yours to create a feedback delay. Anyway this thing can really do a lot! I’ll follow your advice and will wait a bit before making bigger scenes… and by the way the Patch matrix numbers are ok - one just needs to get used to it, and after a day really it’s fine.
to reproduce the karplus strong you may have to route the noise source out through one of mixer channels 3 & 4, then use the effect bus to mix the feedback with input from the noise source. Or sample acoustic noise source from a mic, load that into the other ‘grain’ (gosh the naming is terrible - sorry!) & mix that in via the effect send on grain output.
Other tips - try flipping the phase with this high feedback configuration - think that’s the difference between an organ pipe & a string (or something). Also try tweaking high pass filter on grain input in that configuration & obviously scrubbing/pitch detection should be off, scrubTime becomes fine delay tune.
You need to add patch tips to the readme!
I just made a 128 Grid behave as a complete Matrix patch, meaning it is routing the 15 available sources to the 8 elements that can take them. The last column is used for 8 button features (such as WriteEnable_g1). It is a very simple patch, with 9 operators. Here is the schematics, for those who want to work faster with Grains!
Only thing is, it would be lovely to be able to have objects such as Zones for the Grid, which would allow one to have only one matrix point lit per Row, for instance. I have been thinking about it for a long time actually, and as I am not really able to pull it myself I have create a new thread for those interested: Aleph - new ZONE operator?
Anyway this should help. The numbers below the Operators are for my patch (GRID is number 12, here). The numbers addressed by the two ROUTE8 objects are inputs from Grains (74 is then 074 WriteEnable_g2 here).
For those who will look into this, I strongly recommend you take notes while playing with this simple patch, and also to take some time - at least a few hours! This is extremely cool, the ability to switch buffers into one another, to add FM or AM synthesis on the fly based on your own voice or on an LFO, etc. Can’t describe how many cool uses there can be here! The tough part then is to get to switch functions with the knobs, but that can easily be fixed, using presets…
gotta figure out a way to get one LED per row - I have a feeling this may already possible without adding new bees operators. Gonna have a think how to do that. Since ‘patch matrix’ does not permit mixing several outputs to one input the grid UI should reflect that - also I still want to see the name of each patch matrix output as a reminder. All well and good memorising the numbers eventually but don’t ask me which number is LFO I’d have to go back on the code & check (or hope & pray the README is correct)…
I would like to experiment with “grains”, however, I was having trouble loading it onto Aleph.
When you say “copy these files to your SD card”, which ones exactly?
Thanks all- much to learn here
Closest thing to a release-candidate is:
http://rickvenn.com/grains-0.0.3.zip
If I recall correctly, the folder structure of the zip file should mirror that of an SD card set up for aleph.
Sounds as if some people have experienced some bugs with certain param combinations with the module so be slightly wary! Meanwhile I immediately dove into into aleph BEES side of things attempting to add the features I want there, so haven’t had much chance to destruction test grains through intensive real-world use.
Once I’m done with latest round of BEES changes I have an idea for possible optimisation of grains, which may permit a couple more features within the cpu limit…
Also I want a four-track tape recorder module & a ‘beep-box’ module that turns aleph into a basic groove-box.
Still a MASSIVE amount of unrealised potential with this hardware & any programmers (or would-be programmers) out there keen to try out embedded programming now is the time to get on board - even one more active developer in our tiny community would be a huge boost!
This 4 track idea is really exciting stuff ! Wishing I knew how to program so I could help. Maybe it is time to learn !
i had been neglecting this module, thanks for the great idea!
this afternoon i built the simple scene you made and will test later tonight
(anybody with a grid + aleph can try this gmx.scn )
reporting back just to say that the patch works (this module is so bonkers)
I need to spend time with it so that I understand what is happening but the control over routing fx is immediate and I’ve already harnessed some pretty crazy warps out of the patch matrix working blind
Yep - I got most of it now, but it took me quite some time
Then I like that with such a small patch you can do so much already. I am planning to expand it a lot though (could make many patches there in fact), but am waiting for a go from rick_monster, as each new version will break scene compatibility… I will do some in all cases, but just as tests - already great though!
what params do you usually map to the encoders?
I’m gonna be scheming things with this tonight and am open to suggestion . first priorities are sampling, karplus, and delay games (if I can figure them out)
ummm yeah my efforts to revamp bees got really frustrating hitting multiple brick walls. Made progress adding new operators that allow better programmability for grid-oriented patches. Anyone that wants to can compile bees from my grid-refactor branch to have a play around with some new ops for going deeper with grid. But not going to release a binary of that - it’s too tedious & error-prone trying to do complex grid experiments when you can only delete the top operator off the stack.
I decided to take a break from bees & try to look into running picolisp on the aleph - it’s an interactive programming language that should be very fast & minimal. Still have some remaining bugs/niggles with my aleph port of this programming language but had to take a break again after bank holiday push.
Intensely frustrating I can’t work on this full-time for a month or 2 in forseeable future - kind of hoping the unofficial second run of aleph dev boards will actually go ahead so I set up a pcb-only aleph with jtag debugger attached & the faster avr32 flash cycle - scared to damage my main aleph de-assembling & soldering on jtag header…
Back on grains as well… so no modification before some time, right? I’ll work on a scene then, that could help for future development. I have recorded great stuff today, really fine module you made here - although some of it is still a bit obscure, actually!
well feel free to field any specific questions on the obscure parts of the module - I have a very clear picture how it works/what it does but I found it very hard to explain and/or draw a diagram of the internal structure.
In particular the way turning scrubbing on/off changes the functionality of several other params is a bit nuts! But helps to create quite a few sonic possibilities and I think this ‘feature’ is actually explained ok in the readme…
Don’t hold your breath for updates to this module. I am fascinated and frustrated by the control side of things and feel I need some progress there before coming back to module dev. Haven’t made much progress in recent weeks I think some work on @zebra’s pforth app might be the way forward.
I also recently have been screwing around with icestick fpga, which runs a forth softcore! Could be an interesting direction. Think my next step with aleph should be try to shove my picolisp thing into old aleph repo - the encoder events seem broken in new framework, which sucks. If insane bugs with picolisp persist I will try to get pforth app working.
It’s very possible I can’t make much more progress on bees or picolisp without a jtag debugger - hoping @mattbrockuk’s aleph boards will actually happen so I can have a second aleph for screwing around with more low-level experiments like wiping out bootloader and trying to run hempl lisp machine rather than avr32lib…
Hello hello,
Just found out after recording a whole track with Grains that there was something strange in the high range. I recorded in 24 bit 96 kHz and analyzed the result, and here’s what I got:
First with spectrum analysis, you can see all the way through my recording (which is more than 20 minutes long) a peak around 16 kHz, with a symmetry there (meaning what is above and below 16 kHz looks exactly alike all the way).
And then on a sonagram, the symmetry is just even clearer and it happens precisely at 16 kHz, where there is a hole all the way: a perfect notch.
Can you reproduce this, and if so any idea about what this could come from? I mean, it could come from some of my equipment around the Aleph (mainly my OTO Biscuit, I’d say) but as I can’t try it now I thought I should check with you first. If it is not coming from Grains, then well I’ll apologize and remove the post!
Ha certainly haven’t been over the sound from my aleph with a fine-tooth comb. My unit is noticeably electrically noisy, especially with many lights on grid, noticeable both through cans and out the main outs. Kind of assumed that was a pcb layout issue not manufacturing defect in my particular device.
So ignoring that for a sec, there are some weird hacks used to squeeze the naiive processing for grains onto blackfin at single-sample latency - wouldn’t be at all surprised if my hack DSP introduces this kind of craziness -80dB down (0dB == full-scale i assume?). Did you check sonogram from any other sound generated by the aleph? Also quick enough for me to hook up aleph to jaaa audio analyser see if I also see that weird hollowed-out sideband artefact at 16k coming off my aleph…