Hey,
There has been a change to the midi handling with a recent push to libdaisy, so to get mine to compile I just copied the midi implementation from the DaisyPod into kxmx-bluemchen.
Other than that, copying kxmx_bluemchen.cpp + h to libdaisy/src/ and updating the Makefile in libdaisy allowed me to use the daisyExamples helper to create/build and deploy to the daisy.
hmm… I’ve been using gcc-arm-none-eabi-9-2020-q2-update
I’ll try updating my toolchain later and check if there are any inconsistencies.
Yeah, libDaisy is a moving target right now, but that is a good thing. It’s shaping up nicely.
Hey again,
I did a fresh start:
gcc-arm-none-eabi-9-2020-q2-update
git clone --recursive recursinging/kxmx_bluemchen
build the libs (copied the ci dir from DaisyExamples and edited the ./ci/build_libs.sh)
make
make program-dfu
→ it works!
hth other people struggeling
Cheers,
Bernd
So I compiled with the newest toolchain and had no issues. It’s pretty likely that your libDaisy submodule was pointing at an earlier ref. Submodules are always a little challenging in a context like this. Glad to hear you got it working!
I have finally assembled the kit, and almost everything is working fine.
The only issue is SD card interface - when I put a card into it, the test firmware starts with random noise on screen, and it does not update when I move the knobs.
When I start without a card - all is fine (pots, CV, audio in/out are ok - well, the CV inputs and pots displayed are not fully stable, they fluctuate ±1, but I assume it’s expected).
I have checked visually solderings and I don’t see any issues.
Anyone experienced similar problems?
I just tested one of my modules with a 32gb Sandisk Ultra formatted as fat32. It worked fine for me, but I did notice the OLED flashes random noise briefly at startup. This is because mounting and testing the SD card takes a couple of hundred milliseconds, and the OLED does not get updated until after the TestSdCard() method has returned.
Indeed, if your OLED is staying in this state, it seems the program is hanging somewhere in that function. I’d guess at f_mount(&SDFatFS, SDPath, 1); but you’d have to step in with a debugger to be sure.
It’s probably not a hardware/soldering mistake if there are no visible solder bridges. I’d guess there is something about the microSD card you’re using that the FatFs library does not agree with. Try reformatting your microSD card, or different ones if you have them available.
Yes that’s expected, and they fluctuate more if there is a microSD card inserted (I think I know why but I haven’t yet verified it). Just keep in mind the numbers shown on the test program represent milli-volts.
Yeah, it was the card.
Works fine with another one.
Repartitioning and reformatting the first one does not help. Filesystem-wise both look the same, so maybe something with the card…?
I’ll debug in some spare time, for curiosity.
BTW what’s next with the project? 
I wouldn’t mind a “Pro” version, 8-12hp, more pots and CV inputs.
Quite possible 
The kxmx_bluemchen uses an OLED module via I2C. The link you posted is for connecting an OLED module via SPI. In both cases, the pin connections are correct.
Maybe someone has commented on this before. While looking at the analog I/O it struck me that you could have saved 4 opamps. In stead of a buffer and a divide by 10 reduction stage on each of the input sides and an amplifier (10x) followed by an inverter on each of the output sides I guess it would be possible to only use an inverting buffer with a gain of 1/10 on the input side and an inverting amplifier (10x) at the output. This would imply that the signal that needs to be processed is inverted, but that can easily be compensated for in software. I’ve seen this configuration in the electrosmith schematics as well. What would be a reason to choose splitting up the inverting and amplifying stages of the circuit up? Am I missing something?
Electrosmith staff explained to me that they wanted to preserve the phase between the digital and the analog signals to not confuse newcomers.
Hi everyone,
For us up here in the north half, the summer is starting to wind down. That means it’s time to get up off the beach blanket, and back into the office/studio/whatever. Anticipating this, I put in a few orders to China requesting some more PCBs and parts a few weeks ago before the family vacation, and sure enough, I came home to this:
Pretty, ain’t it?
If you’re interested in a kxmx_bluemchen, or a kxmx_nehcmeulb in 3u or 1u, DIY kit or module, just fill out my little registration form, and I’ll be in touch.
Cheers!
Since I can’t edit my old posts in this thread, here’s a new one…
So I recently discovered that the underscore in my website domain “kxmx_bluemchen.recursing.com” is accepted by some browsers (like the ones I use), but not by others. I’ve therefore migrated the website to “kxmx-bluemchen.recursinging.com” - sans underscore.
I’ve set up a redirect on the old domain, but for obvious reasons, it won’t work for those who had problems in the first place.
BTW I’ve still got parts for a few more DIY kits if anyone is interested.
Cheers
Just got my kits today!
I’ve seen some bluemchen related tweaks on the ~oopsy GitHub. What’s the status with that? Do we export as Pod or Patch and leave any missing I/O references out of the code or is it still in progress?
/slacker avoiding C++ as much as possible
So, huge thanks to @grrrwaaa for bringing the kxmx_bluemchen into Oopsy yesterday.
Just pull the latest update from the github repo, and you’ll have access to the kxmx_bluemchen just like the other hardware.
Obviously, the smaller OLED makes everything a bit more cramped than with the Patch, but it is definitely usable:
I’m looking forward to seeing what sorts of awesomeness get created with this tool!
Thanks once again to @grrrwaaa 
This is fantastically awesome.
And its in the new Oopsy beta, including Nehcmeulb support too 
Amazing project! Thanks for sharing this!
I’ve been modifying it to accommodate a total of 4 knobs with 4 CVs and 2 gate inputs 
First question: is there a particular reason for using TL084s over 74s?
Second question: I wanted to add an external codec, so I was wondering what’s the best replacement for the AK4556? I see on libDaisy that drivers for both WM8731 and PCM3060 have been written. WM8731 being limited to 48khz atm and not certain what limitations the comments mean to for the PCM3060 in terms of audio.
I’m not a very experienced dev or electronician but i find the daisy seed extremely valuable for learning about MCU programming (this actually led me to start taking online C++ classes at almost 40 haha)
What are Electrosmith’s plans for the daisy without the AK4556?
Sorry if I’m getting a little bit OT here… I know there is a specific thread about codec replacement but I thought this thread would also be a good place to ask because this project might expand and this question might be of interest.
