If you have the newer Daisy Seed revision with WM8731 codec instead of AK4556, it’s not supported yet. Actually I have a few of them coming my way, if they arrive safely I’ll likely make a release that adds support for them in a few weeks.
Thank you @antisvin for the quick reply, the workaround patch works for me as you described! This is a big help to my work- and thank you for creating OWLsy - it is a huge contribution to the universe of Daisy
maybe not so serious - I am just exploring different workflows for FAUST to Daisy. But also excited about the OWL community meeting the Daisy community as well…
I had a chance to try OWLsy on my Bluemchen this weekend. I got MidiBoot on there and could send the firmware sysex, and even load some patches from the rebeltech site, all whilst plugged into USB. Good stuff!
Now it’s in my rack I’m trying to control a few things via MIDI and I have a couple of questions:
If my reading of Bluemchen/Inc/hardware.h, Bluemchen/Inc/BluemchenParameterController.hpp and Source/ProgramManager.cpp is correct, it looks like MIDI can’t set first four parameters. Is my understanding correct?
If I wanted to add a menu item to set the MIDI channel, would Bluemchen/Inc/BluemchenParameterController.hpp be the place to do it?
Thanks for looking into this. I think you’re describing it correctly and it looks like it should be blocking only 2 parameters from MIDI update rather than all 4. I mean that they come from 4 ADC inputs that get summed into 2 parameters as far as I remember.
The good news is that I have a solution ported from more recent OWL that lets you implement parameter takeover. The way it works is that updating a parameter by MIDI prevents it from being updated from ADC inputs unless you move the parameter close enough to the value set by MIDI to unlock it. It’s already used for Pod UI that also relies on this for its parameter multiplexing, so I don’t see why it shouldn’t be added to other projects. I can start from the Bluemchen project and let you know when it’s ready before the FW is released if you’d like to test earlier.
Regarding MIDI channel selection, you’re correct about UI file where menus are defined. Or you could use the official tool to change it. Under “Settings / Set configuration” enter values “MI” and your channel number. I think in 0…15 range, but might be 1…16. With -1 it would set it to the default omni mode. Then press “Send” and also “Store” if you want to change it permanently. If that won’t work, you could build a custom firmware with something like #define MIDI_INPUT_CHANNEL N" in Bluemchen/Inc/hardware.h` file to override the default value.
Glad to hear you’ve already got something up your sleve. Would be happy to try something when it’s available.
Thanks for the tip. I’ll try this next time I pull it out of the case. I had already experimented a bit with sending sysex, but my controller doesn’t support it, and I was having troubles getting it to pass through from the PC - I’ll keep looking at that, but I thought a stand-alone way to do it in the device would be handy. I might see if I can code something up.
Most MIDI controller won’t support sysex, because it’s just a data serialization format. So there would have to be some non-trivial way to configure it to specify what should it actually send.
In case of OWL, it’s intended to be used with a web or desktop software. And it makes no sense to me when you say that it’s not working on your PC, because firmware and patches are also sent in this format.
The laptop isn’t always turned on when I’m noodling around, and this particular laptop is old and crappy, I hardly connect it to the wifi unless needed. When I want to program firmware I take bluemchen out of the case, then out of the garage and go upstairs to the real PC to plug it in. I was hoping to be able to use amidi to send sysex for settings or patches via USB, through the KB to the bluemchen via the TRS midi on the front panel, but that’s not working yet - I need to spend some more time to convince myself that sysex is actually making it through the KB. Maybe a corner use case, but it’s what’s motivating me to look into having it settable on the device itself. I think the set once, store and forget might be the easiest way forward for the moment though.
Ah, I see, you were talking about using it with different hosts. Well in your case it sounds like you should have no problems if you connect to the laptop directly, there would be a USB device visible with amidi -l and you can use it to send sysex for firmware and other stuff.
For patches you will need to use FirmwareSender from Rebeltech github.
I don’t have have exact data for sending and storing MIDI channel number, but it’s possible to figure it out. There’s also a sort desktop and web UI for OWL in Rust that I was working on a bit, it can manage settings among other things but is far from being complete.
Hey @jaradical, I have a working implementation for what we’ve discussed in the feature/takeover branch. Let me know if you want to test this and have problems building firmware.
Hey, thanks!
I gave it a go today, although I’m not sure I’ve got the right build. It says v25.2, does that sound right?
I switched to the feature/takeover branch, went into the Bluemchen directory and pretty much followed the update.sh script. I’m still using MidiBoot-Bluemchen-v0.3.bin - do I need to update that too?
I tried the FilthyKick patch - and while I can control Frequency/Filth with the encoder and MIDI, I can’t seem to get the pots on the bluemchen to do anything. Is there some step I missed or some setting I need to change?
Hmm, do pots still work before you change them with MIDI? Maybe it’s just doing what it’s intended to, because parameters stay in the locked state (ignoring values from ADC) until you move the pot close enough to the value set by MIDI CC. This avoids the sudden jump in value if you move the knob after setting it by MIDI.
I’m afraid not - the pots don’t seem to be able to change the parameters, whether I’ve sent MIDI or not.
I’ve also noticed that I can only change the first two params with the encoder - C, D etc don’t seem to respond to the encoder, or any MIDI notes either.
I’ll try and look a little closer later - unfortunately the long weekend is drawing to a close…
Yeah, the encoder issue was a regression that I’ve just fixed. However the knob are certainly processed correctly, could it be something that happens with a particular patch? I’ve made a build for testing in case if your compiler is acting funny.
Btw, I had a problem with knobs not working on Bluemchen recently, it ended up a problem related to soldering.
I was getting “ERROR Invalid bootloader” for a little while then - but removing the sdcard and going through the process again seemed to work.
So yes, now it looks like the encoder is working for all params, but I’m still not getting any joy with the knobs.
I’m confident the knobs work fine, I’m using them in my other patches without any problems.
EDIT: MIDI looks like it’s working fine too, at least via USB.
This error indicates that you were trying to flash something that is not a bootloader when firmware was running. Most likely you didn’t switch to bootloader mode and were trying to flash firmware. I suspect that SD card removal might be just a coincidence, the actual problem was that the sysex command to trigger bootloader mode didn’t arrive or its data was corrupt.
What are you using it for?