Alright, good to know. General instability is just the worst… Will see if I can figure it out.. if I get there!
@iceowl hey just to let you now, I was getting the led not working issue. I used the precompiled binary from GitHub for the latest version, and flashed from both the new web loader and locally. Other functions seemed normal, footswitches did not activate the LEDs. I also tried the previous pre compiled version with the same result. Compiling locally on my windows machine fixed the issue and LEDs worked normally.
Not sure what’s going on there!
1 Like
Edit: Success! see next post
Perhaps it is a compiler/optimization issue
Locally, I am using
❯ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
For CI (at the time of the last precompiled binary) we used:
gcc-arm-none-eabi-14.2.1-linux-x64
@keyth72 can you confirm the version you used in windows?
There are some interesting notes here which further makes me think the version I was using for CI was not super great for us: Releases · electro-smith/DaisyToolchain · GitHub
I will test changing GCC version in CI and using the web flasher Adjust GCC version for CI by xconverge · Pull Request #67 · bkshepherd/DaisySeedProjects · GitHub
This also could be something related to -Ofast instead of an optimization flag that is a bit more conservative. Version 1.3.2 doesn’t use -Ofast so I will test that as well. I will test the precompiled .bin shortly to hopefully be able to reproduce it
1 Like
Yep that was it, I confirmed the previous .bin files exhibited this issue. I will do a new release right now with the older compiler!
1 Like
I updated the README, added a check to the makefile, updated CI for the precompiled .bin files
I don’t want someone else to run into similar issues, so figured this was an OK level of restrictive/helpful
1 Like
Hey hey!
I bought a 125b from @kshep last year and am finally getting around to working on a custom module: A synth with an arpeggiator.
I’m trying to debug getting the tap tempo LED working. What’s the recommended way of logging values to print to the serial port? I know there’s the Daisy PrintLine() function and it looks like there’s a logger module too, but I’m not immediately seeing any examples of logging statements in the other effects modules, so just looking for some quick guidance on the intended pattern.
Thanks!
Printing log statements:
- enable debug logging by uncommenting this line DaisySeedProjects/Software/GuitarPedal/guitar_pedal.cpp at main · bkshepherd/DaisySeedProjects · GitHub
- If you want to print floats you can temporarily add this to the makefile:
LDFLAGS += -u _printf_floatLost half day on figuring out how to debug/ print floats :/ - Add your print statements
- Run and connect with serial monitor, I use this Serial Monitor - Visual Studio Marketplace
Additionally, you could also put the tap tempo on the UI if you have a screen
The code used to print the CPU should be a good example of that and you could just pop it into your effects DrawUI (or even the base_effect_module itself)
This also shows how you can format floats for printing WITHOUT needing the above flags/configuration
Edit: Also because I had posted 3 times in a row before I was unable to post a 4th time a few days ago when something came up I wanted to post here, so in a way you freed me, thank you 
1 Like
Thanks for the input! I’ve got the debugging printlines working.
Also, thanks for mentioning printing to the screen and referencing that code. I do have a screen on mine, but have not delved into writing anything outside of what is just naturally happening with parameters and such as part of the framework.
Speaking of, has anyone recorded a screencast of wlaking through the code and the general patterns for developing a new module? I’m figuring it out, but it definitely would be nice to have that as a resource.
With what I’m working on I also have a use case where it would be ideal to have the tempo set on the pedal from midi clock.
I stumbled upon the following thread and did a quick and dirty proof of concept implementation in guitar_pedal.cpp to just update the global tempo and it seems to be working (i.e. having debug statements print the global bpm seem to be matching the bpm that is sent via midi). Simple MIDI Clock Example for pod
I imagine it would take some additional thought and work for a robust implementation with UI tie-ins and such for tempo set by MIDI clock, but does anyone see any glaring reasons why an approach similar to the above is infeasible?
My suggestion is to start small and add to it and ask any questions you want! If you want to start a long async discussion as a single github issue feel free as well, here is fine too!
What existing effect is most similar to what you are trying to do?
The simplest effect I would reference for the boiler plate would be compressor_module.cpp
- Create new effect with boiler plate copy/paste and adjust the name and add it to makefile and LoadedEffects.h and make sure you can build/flash this and it shows up when you switch to it (either with menu or hold the alternate footswitch and rotate the encoder to switch effects)
- ProcessMono() adjusted to take input and assign it to the output
- Parameter/knobs setup
- ParameterChanged configured to adjust member variables
- Override tap tempo logic by referencing the metronome, tremolo, or delay which are already working “fine”. Some of this logic is in the base_effect_module too
guitar_pedal.cpp has some of the meat for how it all comes together, but you probably don’t need to make any changes here to get an effect implemented. This would probably require some tweaks to make adjustments with how MIDI is processed to then set tempo (instead of relying on footswitch logic which is also done in this file)
Besides that, I have found chatgpt is stellar for being able to paste in the whole effect module code and ask specific questions to really hone in on some stuff and what you are trying to do, especially if you are a bit unfamiliar with some of the DSP you are trying to do.
I think I would start with the non-tempo oriented stuff and then once you are happy with it come back and we figure out the tempo stuff and how to fit it in
@xconverge That is helpful! I think it would be useful to add something along these lines to a README. And yes, chatgpt and the other modules have been very helpful since I’m coming from practically 0 in terms of dsp programming knowledge.
As I got into the MIDI clock tempo setting, that starts to get into the wider architecture of how the pedal runs and I feel like I would need to delve in and understand more of that in order to submit a PR.
There are still features to add and bugs to be worked out, but I wanted to share a quick demo of the MidiKeysArp module and it responding to midi clock:
MidiKeysArp WIP Demo - Bkshepherd Daisy Seed Pedal
1 Like
Most people don’t like to read IMO 
Thanks for the demo video, cool stuff!
I don’t have a midi setup, so further midi questions probably would have to be fielded by @keyth72 or @kshep
1 Like
@xconverge Cheers!
This is cool! I was planning to experiment with a MIDI synced tremolo effect so I’ll check this out.
It looks like you were doing MIDI over TRS? I think I might try to get it working over USB to save the hassle of having one more cable connection during debugging.
I added a few of the variants from these Friedman BE-100 NAM Profile · TONE3000 to the NAM module last weekend and it was successful in handling my GAS (I was considering making yet another dirt pedal)
So this pedal continues to pay back dividends to me…at the cost of SW time which I have enjoyed thoroughly
2 Likes
Does any one have a JSON file to use with PatchData? I’ve successfully worked out how to use the foot switches to toggle the LED’s but I’m stuck on how to engage the relays. I’ve tried to use the patch example JSON but no luck.
Cheers