OWLsy - a port of OpenWare to Daisy platform

This is a crude representation of what my current setup looks like:

                 ______       _____                               
                |      |     |1X5  | /                            
______          | DIN1 |>>>>>|THRU |< Synths/FX                
      |  USB    |      |     |_____| \                            
Laptop|>>>>>>>>>| MIDI |                                          
______|         |  KB  |      _____                               
                |      |     |1X5  | /                            
                | DIN2 |>>>>>|THRU |< Bluemchen here somewhere    
                |______|     |_____| \                            
                                                                  

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.

Cheers

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?

Cheers

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…

Cheers

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.

Cheers

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.

Hi, this project seems very interesting ! But I’m not sure I understood correctly. Is the tool available for a simple daisy seed or not?
Thanks a lot !

Running on modules without any peripherals is not something that is particularly interesting in my opinion. But there’s nothing stopping you from doing this if you want to be able to only control it by MIDI, using POD firmware makes most sense in this case. It would make more sense to use the actual POD as it gives you headphones preamp and ability to switch patches stored on devices.

Hello, thank you for your response.
Maybe my question was not very clear but I have a lot of peripherals on my daisy seed, potentiometers, switches etc. (if that’s what you call peripherals), I mainly wanted to know if this tool would work on a simple daisy seed, and you seem to say yes with the Pod firmware so I’ll give it a try sometime I think :slight_smile:

Thanks!

Hello again,

finally I have finished building a Bluemchen and I like to varify the procedure to install everything (OWLsy).

I´m just trying to install

  1. MidiBoot-Bluemchen-v0.3.bin (bootloader usually only once need at first installment?)
  2. Bluemchen.syx (latest firmware to run Owlsy)
  3. Owlgazer_Shimmer_Reverb.syx (app as an example; I just copy any app .syx to the SD-card at top folder right?)

I run the latest Google Chrome and tried to connect the Daisy Seed via Daisy Web Programmer
It seems to be connected (not 100% sure), but the program button is still grey and can´t be pushed.
Any tips, what I´m doing wrong? Thank you for any input!

Daisy Web Programmer is only usable to flash bootloader. At least I think it used to work for me in the past. You can also use Rebeltech DFU utility instead, but you must use its advanced mode to flash it at correct address, it won’t work otherwise.

Firmware is flashed from the Rebeltech firmware update tool

And for patches you should use patch library

There are alternatives to this that don’t require using browser too, of course.

1 Like

Thank you @antisvin,
some progress here. Found out, that I just needed to reinstall/update the driver with zadig. After this the Daisy web programmer worked again. I installed MidiBoot-Bluemchen-v0.3.bin and Bluemchen.syx. System is running on my module. But I´m a bit curious how to use the https://www.rebeltech.org/patch-library/patches/latest.
Do I need an account maybe?
On the device header I see Midi IN/OUT: OWL BOOT, which give me the impression, that Bluemchen is connected, right?
If I go to the “popular” header to choose a patch to load onto the Daisy Seed, I can click “load” or “store”. Nor of those options seem to load the patch onto the Daisy Seed.
Do I need to power to module with Eurorack?
Maybe I need to format the SD-card before or “activate” the SD-card in the Bluemchen menue, which seems not to work?
Grateful for any hints!

According to USB device name you’re in bootloader mode, this is typically because you haven’t rebooted after flashing firmware yet or haven’t flashed it successfully at all.

Here is a screenshot of the display. Doesn´t that mean that bluemchen.sys has sucessfully been flashed?

Hi guys!
I’ve finished building a Patch.init() and I’m trying to do some cool stuff with it. I came across OWLsy and I’m a huge fan! It means I can port my Faust code to run on the Daisy quite seamlessly! However, there is one thing that is slightly annoying, whenever I power cycle my rack, it loses the knob state and resets to the default values. I assume this is due to the soft takeover since it also happens when switching between patches. Is there an easy way to disable this soft takeover for the frontpanel controls? (I don’t mind doing some coding and/or building from source) Thanks in advance!

Cheers,

Niek

Yeah, soft takeover functionality is intended to make parameters bound to ADC inputs to be overridable by MIDI. It sounds like it starts in a locked state when it’s not supposed to. So it should be solved not by disabling, but by fixing its current behavior.

Let me know if you manage to build firmware on your own, in such case I can let you know what to try modifying Patch.init UI controller source. I’ll probably get to fixing this myself in a few days along with other devices that have the same problem.

Hmm okay, I’m at the point where I think I’m ready to run the make command. However, it instantly throws a syntax error. Do you have any idea? I understood the instructions as that I first have to generate the code using CubeMX and the .ioc file and then run GNU Make (after having set the TOOLROOT), I also tried without CubeMX (by reverting the changes) but no effect. I checked out the branch ‘daisy’ btw.

MINGW64 /c/GitHub/OpenWare_Owlsy/OpenWare_Owlsy/PatchInit (daisy)
$ make
mkdir ./Build
/usr/bin/sh: -c: line 1: syntax error near unexpected token `('
/usr/bin/sh: -c: line 1: `/c/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin/arm-none-eabi-gcc -c -O2 -nostdlib -nostartfiles -fno-builtin -ffreestanding -fdata-sections -ffunction-sections -fno-builtin -ffreestanding -DDAISY -DPATCH_INIT -DPATCH_SM -mtune=cortex-m7 -DOWL_ARCH_H7 -DGIT_REVISION='"daisy 019353d6 Release"' -O2 -std=gnu99 -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-sp-d16 -mthumb -fsingle-precision-constant -I./../Libraries/Drivers/CMSIS/Include -I./../Libraries/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I./../Libraries/Drivers/STM32H7xx_HAL_Driver/Inc  -I./../Source -I./../LibSource -I./Inc -I./../Libraries/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I./../Libraries/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I./../Libraries/Drivers/STM32_USB_OTG_Driver/inc -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/include -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM7/r0p1 -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS -I./../Libraries/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS_V2 -I./../Libraries/Middlewares/Third_Party/FatFs/src -I./../Libraries/Drivers/CMSIS/DSP/Include -DSTM32H750xx -DARM_MATH_CM7 -D__FPU_PRESENT=1 -MMD -MP -MF"Build/freertos.d" -Wa,-a,-ad,-alms=./Build/freertos.lst Src/freertos.c -o Build/freertos.o'
make: *** [../Hardware/common.mk:57: Build/freertos.o] Error 2