Is anyone working on software compatibility from funbox software to bkshepherd hardware? There’s got to be a few of us who think these planets are the most beautiful sounding guitar effects ever made but only have bkshepherd hardware to work with.
From what I saw in the bkshepherd software, it looks to be designed to easily incorporate new effect modules
Just curious, I’m still learning C++ to hopefully do it myself, but its been a slow process (who would have guessed?)
@keyth72 Alright, sounds like a probable root cause. I’ll try the filter in a bit.
Regarding improvements, most of the issues where of my own making.
I’m gonna do more testing in a bit, something might crop up.
The build system could probably use some convenience scripts, though that’s something I can try to help with myself.
I did see one breaking bug with the second switch on one of the planets. Unfortunately I’m not entirely sure which.
It was the first one I flashed and for a good while I thought it was a hardware issue. In the end I found that the second switch was supposed to load a preset and I guess it was loading garbage, causing the pedal to lock up. After first long pressing it, it started working.
This is all guessing but I only got one DaisySeed and had previously loaded the bkshepherd software. Maybe it stored something there that wasn’t erased?
If the preset routines doesn’t have it already maybe they should store a magic string to allow them to recognize their own preset before loading.
@GreenOrange yes it should be possible to adapt the planet modules in some form to run on the kshep pedal, I’m interested in doing this also. The have a few of the oled screen pedals in the works and if I can have a single pedal with abunch of selectable effects that’s a lot more convenient for my pedalboard! I’ve moved a few of the core effects over, like the cloudseed reverb from Neptune and Jupiter, and NAM from Mercury, and a smaller version of the spectral delay from Saturn. I’d really like to put this latest granular effect there too.
@jrob yes it will crash the program if there’s data stored on there it doesn’t expect, I need to write better error handling to avoid that, The workaround as you figured out is to save a preset to overwrite the previous data before trying to load the preset,
I put the pedal together last night and I’m about to load it on and see if it functions. Used a hothouse so I dunno if it will be compatible but I’m assuming it will as long as I use a daisy seed.
@jojoranch let me know how it goes! The knobs should work, but depending on how the hothouse is wired they may be mixed up. Hard to say on the switches, again it depends how they are wired to the daisy seed, the effect should run but the toggles will most likely be mixed up or not functional.
Stupid question, apologies in advance. If I build and run the Mars firmware on a Funbox, what else do I need in the signal path to achieve the beautiful sound in the demo video? Asking because you mention that the Mercury is Amp-only so needs IR+Cab. However, the Mars firmware includes Amp+IR/Cab.
@kidproquo no that’s a good question, although the Mars video just uses the pedal, I don’t think I used anything extra, so that should be the sound you get. On the Mercury demo I added a IR plugin (I use the free Pulse plugin) with Bogren Digital IRs. And I added a reverb plugin, I think I used CloudSeed on the Medium space preset. I’m using a Focusrite Scarlett 2i2 interface, I think they have some ok preamps in there so that might color the sound a little.
Thanks for the clarification. I am trying to troubleshoot my build.
I am working on a new pedal, loosely based on the Hothouse but with an ESP32 for wifi based communication and an sdcard to save recordings. Also doing a companion app that lets you configure and control the pedal, including changing the active effect. I have the Neptune reverb running on it and am trying to get Mars going. The Daisy crashes if I have IR enabled, at this line:
impulse_out = mIR.Process(balanced_out * dryMix + delay_out * wetMix) * 0.2;
What could be the reason? Any ideas? I am guessing it’s running out of memory.
If I run without IR,
impulse_out = balanced_out * dryMix + delay_out * wetMix;
it works, obviously without the nice sound but with the delay and amp effects working.
Ok, some more findings. I cloned the Funbox repo. Fetched the Git submodules. Updated daisy_petal.cpp and daisy_petal.h from the mod folder. Changed the switch, knob and LED pins to match the hardware. Removed the dip switch references, defaulting to Amp and IR enabled:
// Process Neural Net Model //
if (true) { // Enable/Disable neural model
ampOut = model.forward (input_arr) + input_arr[0];
ampOut *= nnLevelAdjust;
} else {
ampOut = input_arr[0];
}
if (true) // If IR is enabled by dip switch
{
impulse_out = mIR.Process(balanced_out * dryMix + delay_out * wetMix) * 0.2;
} else {
impulse_out = balanced_out * dryMix + delay_out * wetMix;
}
Built and loaded the code. I get very glitchy audio when bypass is false, nothing like the video. And the Daisy stops responding to the footswitch - bypass remains false. If I disable IR:
if (false) // If IR is enabled by dip switch
{
impulse_out = mIR.Process(balanced_out * dryMix + delay_out * wetMix) * 0.2;
} else {
impulse_out = balanced_out * dryMix + delay_out * wetMix;
}
It works, albeit without the IR. Bypass footswitch works.
Anyone seen similar issues?
Regards,
-Kid
@kidproquo yes that sounds like the behavior I get if the pedal is trying to do more processing than it can handle, like it can’t fill the buffer in time and has to send out garbage audio. Just so I understand, you’re using a custom pedal, not the Funbox? Is there any extra processing going on? On most of my Funbox modules I’m pushing the daisy seed to just about its limit, so optimization might need to happen to add more things.
One thing I noticed, in the Mars FunBox module I’m using Os optimization, which isn’t the fastest. Try using -Ofast optimization flag in the makefile.
Bingo. Thanks for this hint. Using -O3 or -Ofast makes it work. Os/O0/O1/O2 show the same issue. This with standard Mars firmware with only the switch/pot/LED pin defs updated in daisy_petal.cpp - I am doing a custom pedal, inspired by the Funbox and the Hothouse:
Next step - get Mars working on my custom firmware, the only additional processing the second I2S feed of the output stereo audio to the ESP32 for it to be saved to the SD Card.
Hi, this concept looks familiar 
I would suggest using BLE for the App control. MIT AI2 App development is super easy to use and has the BLE component built-in.
If you plan to stream in bluetooth from the ESP keep in mind you have to use an ESP with classic BL (not S2,S3,C3 etc.)
I think it would be better to connect the SD directly to the Daisy. Check if 1bit SD is fast enough for recording.
Good Luck!
I have been following your JamMate pedal. Looks very cool and yes very similar to my pedal.
Thanks for the recommendations. I am very comfortable with mobile app dev (native and cross-platform) so I am going with Flutter.
The main USP of the pedal is the ability to record to an SD card and then download it to the app.
Recording can be triggered from the app or by pushing on FSW2. 1-bit SDMMC works fine for recording 2-channel 48kHz 16-bit samples, in fact even SPI-based SDIO works as well. My main challenge was the download speed from the SD card to the app via WiFi, the PCM WAV files can get large very quickly. I have managed to improve that from unbearably slow to bearably slow (PSRAM buffer and menuconfig tweaks to the TCP buffers). I need to try the same with BLE to see if that gives a speed boost. I am using the XIAO ESP32-S3 module for the flexibility to use an external antenna. I don’t have a requirement for A2DP streaming, so I am ok with the S3.
I have some queries on JamMate. How are you communicating between the Daisy and the ESP32? I didn’t see any signals between the two in the schematic. I see you are using separate LDOs for the Daisy, ESP32 and the buffers. Is that for noise isolation?
Cool UI. Could not find the time to get into flutter, but I wish I did… ESP and Daisy talk via UART. Just sending 17 bytes from the app to the esp to the Daisy for each effect or config change,and the detected frequency from the Daisy to the esp in tuner mode for displaying the tuning error.
LDOs maybe an overkill as both Daisy and ESP have LDO but I guess you can never get too much isolation. Especially when the BL or high processing kicks in. I did get a noticeable hum when reading the IR and drum samples from the SD on boot. Maybe reading to the ESP is quieter but I don’t have any IOs left…
I think for me, other than the BLE and stream-in features, the ESP takes a lot of load off the Daisy by handling switches, display, encoders, comm and GUI. Implementing all those parts of code in the ESP is what enabled stacking all the effects in a single Daisy. And I mean also in terms of program size, not just processing power. It started as a fun project but after implementing the up-sampling in the distortion effect and a multi-tap delay, it sounds so good, I hardly use any other effect today 
Letting the Seed to focus on the effects makes a lot of sense. Are you able to have separate effects on each channel? Say Distortion on L and Reverb on R?
Working mono right now. Focused on single guitar effect. The PCB is built for stereo in/out. I don’t think there would be a problem. Maybe not 512 points IR sim for both channels, but simple effects are possible I believe. I can today run a freeverb model with upsampled distortion, multi tap delay, IR sim with TMB filter, 6 band EQ, and probably another modulation effect with the looper and a drum machine without anything catching fire… This Daisy is pretty powerful.
