For those of you interested in the Hagiwo $8 Sample Drum playback unit I have been testing it and making some mods of course.
I wanted to make a programmable kit and of course I needed to select the sample, change the tuning and switch on/off the low pass filter. With very few pins left to play with, although I could lose the encoder and tuning analogue inputs, I didn’t want huge amounts of wires and shift registers needed to select lines etc.
I though that all of this can be done over MIDI with CC messages and a program change. So I loked at the schematics and code and moved the trigger input to another pin which freed up the RX pin for MIDI.
I added a MIDI input and some simple code to setup the interface and read the incoming bytes in the loop, I’m using a program change to select the sample number 0-47, a CC 09 to set the tuning with 128 steps and another CC 10 to turn off and on the low pass filter. I could have done the sample with a CC as well, but its done now.
I will put the code up on my github page shortly.
My plan is to build 16 drums on channels 1-16 and send pgm changes and CC messages to edit each drum module and store configurations. I will use 16 VCA’s for volume and accent as well on the final output stages.
I’ve already started bread boarding the controller for the Hagiwo drum modules, promising so far, I can control four parameters of each drum, sample number, tuning, volume and filter setting for each if the 16 drums, plus a master volume.
No it’s a single drum playback, pretty much like the old 8 bit drum machines like the Linn and Oberheim etc, you can build one card per drum sound. Good thing is though you get upto 48 drums per card with tuning etc. So this programmer can control that. I intend to build up 16 modules of drums with like 48 bass drums, 48 snares etc. It is also triggerable over MIDI, although I’ve not implemented it yet it’s trivial to do so. So it’s possible to build it as a drum module to be played from a sequencer.
I’m currently playing with separate channel polyphony on the rp2040 and I’m fairly sure you can squeeze a drum machine with 8 or possibly 12 or 16 individual channels (with limitations) per drum IF you stick to 8 or 9bit drum samples. You would be better with a full sized rp2040 board like the official one though. Please keep in mind I’ve yet to achieve anything close to this.
I say this because there are 8 PWM slices with 2 outputs per slice and 12 DMA channels that can directly feed the PWM channels with sample data.
Word of warning, anything that looks like it’s doing 16bit PWM at audio rates likely bitcrushing your signal ( looking at you PWNAudio) with the exception of one example I have seen that does Sigma Delta Modulation, but that’s cpu intensive…
I’ve managed to get 6 simultaneous 16-bit mono samples (.wav files) playing through an external I2S DAC on the WeAct Studio RP2040 board with 16MB of flash memory.
The limiting factor seems to be that both the sample data and the program are read from the same flash memory.
It was just a proof of concept prototype (and a way to learn CircuitPython).
There isn’t much documentation at all, but I uploaded the whole CircuitPython project to https://pasde2.com/PWT/
Thanks for that, I’m having some major issues with programming the esp32-c3 boards, I can program one without any problems, but the otherd refuse to accept this program, although no errors on upload. They will accept blink etc and work quite happily. So until I can get the issue resolved I’m look at alternatives. Just a shame I’ve spent several days developing the programmer just to be thwarted by this issue.
I was wondering if flash memory contention might become an issue. I guess for short samples (eg. Linn Drum type samples) you might be able to load each sample into separate SRAM banks, but there is precious little information on how to achieve this?
I finally got to the bottom of the code failing to load after being pointed at a WIKI page, the esp32C3 is quite sensitive to whats attached to D6, D8 and D9 when in boot mode. I had a trigger on D8 which I moved this did not help, however, moving the Encoder from D9 to D1 fixed the issue and now I can load the code perfectly.
Well maybe I spoke too soon as I can flash 2 modules out of 6 now. If I take out the encoder from the loop, flash the chip and test over midi it’s fine, then if I add the encoder code back into the loop and program again it’s fine over midi and encoder. I think because D9 was programmed on these devices already then a refkash without the encoder fixes it and now it’s on a new pin it’s ok.
I will try to flash a virgin board to prove that theory.
To be honest I don’t need the encoder or tuning pot as I do everything over MIDI, but it was bugging me why it doesn’t work off the bat.
Was the encoder pulling, I think it’s D6, high?
On the subject of rotary encoders, do you use any debounce caps? I’ve a raspberry pi device that seemed to benefit from the addition of a few 10s of nanofarads.
The encoder used D9 and D10, now it uses D10 and D1, to be honest I forgot the caps, but that was not the issue, and really I can do away with the encoder and pot entirely now its hooked up to the controller. Teensy designs don’t need the caps on the encoders.
I managed to flash all the esp devices after the code changes. Now my problem is making up my own sounds successfully
How did you upload the code to the seeeduino xiao? Every time I do, I get the error, “A fatal error occurred: Failed to connect to ESP32-S3: No serial data received.
For troubleshooting steps visit: Troubleshooting - ESP32 - — esptool.py latest documentation
Failed uploading: uploading error: exit status 2”.
I heard it might be because I need a specific usb-c cable, is that true?
