Hello,
I’ve been greatly enjoying working with the WAV Trigger and the Tsunami on a couple projects, and have a few related questions. Thank you and sorry in advance, as question #2 is a pie-in-the-sky dream right now, and I’m wondering how feasible it is.
- I recently decided to expand functionality of the Wav Trigger/Tsunami projects by pairing them with more powerful Arduino-compatible MCUs (to add functionality not directly related to the WTrig, such as better timing, faster matrix scanning, driving more peripherals, etc). I figured since I have many Sparkfun and other boards that are more powerful than what I’m using in these projects (Mega 2560), that I’d start with those, but am having trouble getting the Wav Trigger Arduino Serial Library working with the first board I’ve tried*. The issue with this board (which is a SAMD51, Cortex M4) is the lack of SERCOM definitions and functionality parity with the analogous (by physical layout) official Arduino board, the Mega 2560 (which of course works flawlessly with the WTrig and Tsunami libs in my experience). I know support can’t be provided for this third-party product, but are there any similar SAMD51 (or similarly-fast) Sparkfun boards I can buy which definitely work with the Wav Trigger and Tsunami out of the box, as effortlessly as an Uno/Mega etc does? Specifically, boards that have more than one hardware Serial IO (need Serial for debugging, Serial1 for the WTrig/Tsunami, Serial2 for MIDI IO).
Am also curious about the Teensy and Teensy-compatible boards, as I have some experience using those and the PJRC audio library.
That brings me to the second inquiry…
- I haven’t yet implemented this code, but wish to ask for advice or pointers in the right direction. I’ve made a couple typical sampler-sequencer devices, one powered by a WTrig + Arduino Mega, the other powered by a Tsunami + Arduino Mega. Both have MIDI IO on an additional SERCOM.
The idea is for the Arduino to be able to live-edit wav files, while the WAV Trigger/Tsunami board is still reading from the SD card and continuing to run. I have just enough experience debugging race conditions in various contexts to think this is already a bad idea, and that I should avoid the attempt, but this would certainly be ultra cool if possible. To (hopefully) avoid R/W collisions or corruption of the SD card data stream to the Wtrig, the Arduino would first query the WTrig to see which track is playing at that moment, or ideally, a global function which holds the track number for all tracks currently assigned to sequence steps.
The track data would then either be streamed in chunks to the Arduino form the WTrig SD card, or, if the track isn’t in use at all by the WTrig, the Arduino could perhaps attempt to copy the entire file over for editing in one go. The reverse would occur when the wav file is edited and pushed back to the WTrig SD card; first querying the WTrig to attempt to determine safe intervals during which to overwrite the wav file back to the WTrig SD card.
There’s multiple issues I know I’ll encounter from this approach, such as the WTrig firmware not seeing the updated wav data, even if the wav file is edited and sent back to the WTrig successfully - as well as many more issues that may result in additional hair loss. Would the WTrig necessarily have issues with write operations occurring on its’ SD card, since the WTrig is (I think) using the SD card as read-only? Alternatively, if this is as impossible as I’m thinking it is, is I2S feasible instead?
- My last question is specific to the Robertsonics project Carina, which looks wonderful: https://robertsonics.com/carina/. Is this available anywhere?
*This is a non-Sparkfun product, my bad; however here’s the related forum thread for context if needed: https://forums.adafruit.com/viewtopic.php?f=63&t=153243.
Thank you for any help!
R