I’ve coded up a granulator, currently running on the Daisy Pod:
Here’s a demo (please excuse the background noise picked up by my phone):
I still need to add MIDI support, and I’m planning on porting it to the kxmx_bluemchen so there’s a screen for browsing folders of samples. As it stands it will just read the first 16 wav files it comes across in the root directory of the sd-card.
Recording from the inputs is also missing at the moment, but I figured I’d get this up on github now that I think all the other functionality is there.
I’ve got a bluemchen, but I haven’t powered it up yet. I’m not surprised it makes sound, but I guess the controls don’t make much sense.
I suppose It shouldn’t take too much reorganization to separate those out.
And I don’t think we’d need too many drastic changes to make it build for several daisy platforms, probably just some defines in the Makefile and some ifdefs sprinkled through the code. Do you have any thoughts on the subject?
In any case when you get something working I’d gladly accept a pull request.
I just pushed some rudimentary MIDI support for anyone who’s interested. It’s liable to change once I bang on it a bit to see what does and doesn’t work, but it should be enough to get most parameters under MIDI control.
If tomsdir is the only sub directory of /grnltr it should start up with the contents of that straight away. It should always start playing the first contents it finds in the first sub directory it opens under /grnltr/. The actual sample rate is 48kHz, so your 44.1kHz file should probably play a little pitched up, but should still play. Is it possible to share the wav file with me? I don’t actually do any sanity checking on the wav file at the moment - so maybe there is an issue there?
I have a build with logging, but only for the pod as I haven’t taken the time to make it fit on the Bluemchen, if you wanted to try that?
Agreed, 44.1 should just play a bit faster - but I tried again with 48k file, same result.
Here’s the output of the ‘file’ command (Mac OS):
% file toms.wav
toms.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz
Maybe I just haven’t figured out how to work the controls? I’ll tinker some more…
OK - my example file matches that and plays just fine. For what it’s worth I’m using a fat32 formatted 32G sdcard.
What version seed do you have in your bluemchen? I don’t think it should matter as I’ve tested with both the AKM and ISSI codec versions and they both worked.
I just pushed a version with a few more indications of what’s going on at startup if you feel adventurous enough to pull it and build it yourself? One thing to note if you do try and do this is that I’m using the fix/uart-rx-dma-mode libDaisy branch. Otherwise I can put a .bin somewhere you can get. Let me know.
I must be doing something wrong. Should it start making noise on powerup, or does it need settings, or MIDI input, or audio input? I’ve verified the .wav file plays on my Mac.
I’d been using your pre-built .bin file; this time I cloned the source, built using:
flashed using STLINK:
make BUILD_TARGET=bluemchen program
All went as expected, but still no noise.
Verified my Bluemchen and Daisy by building/flashing another program, worked fine.
EDIT: I just re-read your last message, noticing the “fix/uart-rx-dma-mode libDaisy branch”… I’ll try that.
EDIT (again): tried uart-rx-dma-mode branch. Same result.
EDIT (again again): I’ve got noises coming out now, after fiddling with the encoder and knobs. Might have been user unfamiliarity all along… or not. I still can’t get anything recognizable, and I can easily crash it to the point of needing reboot. I’ll keep an eye on this project, it might be too soon for me.
Yeah - it should start looping the first wav file it finds in the first directory it encounters under /grnltr.
Do you see anything on the screen during startup?
How big is your WAV file? Total wave file size in a bank should be < 64M - it silently bails out if that’s not the case, and if your first sample is bigger than 64M it’s not going to read anything.
I’ve just pushed another commit which should do some better error checking for that kind of thing.
EDIT: Something else to try might be pumping some audio through it in live rec mode: on the BLUE menu page long press to get into param select mode and then click on “live rec”. Probably best to use
looping or sustained kind of audio.
I think the problem might have been the file, I had converted it to mono using a free web-based converter. I didn’t want to install all the crap sox needs. So, I added a stereo .wav to the SD, and that works, though 1/2 speed, as expected.
It’s now behaving sensibly.
Thanks for your help and patience.
I’m working on a Python helper app for making banks with stuff like BPM detection and start /stop editing that will also ensure that the files are in the right format. Unfortunately it needs a whole bunch more crap than just sox, but its no where near ready for prime time.
In any case thanks for being a guinea pig, and do let me know if you hit any other hiccups or have any feature requests.
C’mon people! I know there are other Bluemchen users! Try this thing, it’s great!
Installed v0.97. I tried using ‘git clone --recurse-submodules’, but the bluemchen build failed (didn’t note the errors), so I created a symlink to another working kxmx_bluemchen directory… build and program then worked.
Comment/question: is it really necessary to do all those parameter settings 1000 times per second? Trick question, doesn’t seem necessary to me. I tried moving them all to the 30 times/second spot, works fine. Just looked wrong to me setting rarely changing values in the AudioCallback. Of course, there could be some other consideration I’m missing.