Introducing Owlsy


I’ve spent last few months porting OpenWare to Daisy Patch and by now it’s in mostly usable state. As in - I can build and load existing OWL patches on it and device doesn’t burst into flames when I run them. So I guess it would be safe to announce its existence, in case if there are more people willing to test this firmware.

For now it looks like Windows 10 USB drivers are giving an error when trying to use it. I’ll be making an updated FW release when this would be resolved in upstream OpenWare code.

I’ve compiled some basic info about Owlsy usage/installation in FAQ format here.


Sweet! Sounds very good, hope to find some time to try it soon!

Sure, give it a go and let me know if there would be any issues in process. Typically you would need to flash bootloader binary, then send it the sysex with firmware, reboot after 10 seconds or so and see running firmware.

I was thinking about making an introductory video, but for now I’d rather get some feedback from more competent users.

1 Like

I guess I should also let @sletz know that with this firmware port Faust patches are fully usable with all features added for OWL itself (parameter binding, MIDI controls, dynamic memory allocation to SDRAM, etc). In fact I didn’t need to change anything in OWL arch files to get them working. Quad channel audio works too.

I love this idea and I’ve been trying to follow the steps you outlined but I have absolutely no coding experience, so I haven’t gotten a chance to try this, maybe in the future, there could be a way noobs like me could install this. I love the creativity in this project though, I admire you for it.

Yes, there’s no requirement to write any code in order to install this firmware. You would just install bootloader the same as any compiled Daisy patch, then load firmware image as MIDI sysex files when bootloader is running. Your patches would be loaded in the same format, but when firmware is running.

There are prebuilt images for bootloader and firwmare. For your patches you would use existing FirmwareSender tool to convert binary to sysex after building them.

1 Like

It works, thanks!

Here is a steps to run at least Faust code on macOS, I’m using Visual Studio Code, but it can be done with other IDE or in plain shell:

  1. Install Homebrew if it’s not installed yet.

  2. Install required packages:
    brew install faust make gcc-arm-embedded dfu-util
    brew install --cask sysex-librarian

  3. Upload firmware using dfu-util:
    dfu-util -a 0 -s 0x08000000:leave -D MidiBootDaisy.21.0.bin -d 0483:df11

  4. Use Sysex Librarian to upload DaisyPatch.21.0.syx.

  5. Clone few repositories into one directory:
    git clone --recursive # not a requirement, but you probably want to check it
    git clone --recursive
    git clone --recursive
    git clone --recursive

  6. Checkout right branches in following repo directories:
    cd OpenWare && git checkout daisy && cd ..
    cd OpenWareLab && git checkout daisy && cd ..
    cd OwlProgram && git checkout daisy && cd ..

  7. Build FirmwareSender with Xcode:
    cd FirmwareSender/Builds/MacOSX && open FirmwareSender.xcodeproj

  8. After successful build you can find build directory, you need to copy FirmwareSender binary to cloned repo OwlProgram/Tools directory.

  9. Also you need to edit in a root of OwlProgram repo, and remove $(TOOLROOT) from those variables:

  10. And after that you can go to OpenWareLab/Faust and compile/upload patches to Daisy Patch using script:
    PLATFORM=Daisy ./

I can miss something, so if you have a troubles running it on macOS just leave a message.

Thanks for taking time to add the extra info! Some comments:

  1. OpenWare is only needed to build firmware, since you’re installing binary it’s not really useful (unless you’re planning to do some firmware hacking!)

  2. OpenWareLab is only useful because you’ve used FAUST samples for testing, this is not mandatory too.

  3. It’s probably better to specify TOOLROOT="" as env variable instead of editing Makefile. If you really want to hardcode it, you can set TOOLROOT ?= “” in, it’s still better than changing 12 variables that use it!

  4. Looks like this fork is not going to be merged upstream, so I’ll at least change default PLATFORM value to be set to Daisy by default as part of the next update.

Other than that, there would be another release later this week.

Owlsy v21.1.0 is available. Bootloader update is not required.

Second Owlsy release has the following changes:

  • Enabled USB audio channels - device is usable as quad channel USB audio interface capturing its inputs
  • Raised MCU clock from 400 MHz to 480 MHz
  • Reclocked SAI to run codec at exactly 48000 Hz
  • Various updates to resource menu for upcoming flash resources support

Here is an updated guide for Mac:

Mac guide


A major update v22.2.0 was made a few days ago. Its main goal was binary compatibility with patches compiled from upstream OwlProgram repository and Rebeltech web patcher.

You can use official firmware update tool to upload new firmware, then erase patch storage using the “System” menu in Owlsy UI.

  • Memory layout changed to be compatible with OWL - this breaks compatibility with old patch binaries, storage must be erased after updating via “System” > “Erase patches” menu
  • Added backwards compatible mode for running stereo patches (detected automatically). This allows running patches from official Rebeltech library.
  • Additional fast RAM sections used as dynamic memory, typically giving noticeable performance improvements
  • Added resource storage access from upstream
  • Added support for bootloader updates via MIDI
  • FAUST patches will be built with faster memory buffer processing code, requires recent compiler version
  • Experimental SOUL patches support in OwlProgram
  • New “System” menu for some firmware functions previously available from MIDI only

Hey hey :slight_smile:

So when I first discovered this post I was totally amazed by it and confused aswell, because I never heart of OWL. I digged a bit, but became a dad around that time. I let the daisy patch and music at all sit down for a while haha
Then Befaco released the Lich and there was it again. This magical cody something named OWL. I digged deeper this time and thought. Fucking hell thete a lot of apps for this system, I wanna try it out. I almost bought the Lich till I remembered you’re post today (got the make noise echophon instead - finally after so many years). Sorry off topic.

So I wanna thank you, that you programmed this, it looks awesome and even if I had a lot of fear installing this owlsy, because I have no clue about sysex programling or any program language who is not visual like max. So I fucking made it. Took me only 10 to 15 minutes with you’re little install instruction and some research in the net.

It worked, almost… but I have no clue whats wrong. Like on the picture you see, the rebel technology page recognized my daisy owl. I went to that filthy kick example, because it seems to be written especially for daisy owl. And pushed that store button. I tried it with app slot 0 and 1. I unplugged the daisy seed, put it into the patch, started my modular and the owlsy interface shows up. The Encoder works. I can travel through the menu and click zo go to the sub menus, but there is no apps/patches on it. After I click store there is a really shot loading icon but no other message or something.
I tried it with other examples as well, like a reverb. The loading icon seemed to be longer, but same result.

What could be wrong? Do I need the daisy lib installed on my pc (which I have, but maybe I did a mistake here, because I’m a coding noob)? But I guess not because when I installed owlsy, the daisy patch talks now owl and not daisy lib anymore?!

Or maybe I don’t understand the rebel technology page, maybe there is an extra step I need to do?

So so sorry for my long and part silly post, but I was so hyped to try this and it seemed to work and then not, I needed to reflect that here.

So I am grateful for any advice and solutions. I’m excited to use this platform!

Kind regards Franky

Hey Franky,

Thanks for the kind words. Well, most of your gratitude for Owl should go for Martin from Rebeltech, really.

Regarding the patch you’ve tested, this was done as a test for using DaisySP library. Support for this is not merged to upstream OwlWare repository yet, so building it in their web patcher won’t work until that happens. There’s a comment in patch description regarding this.

Every other patch in Rebeltech library is expected to work with the firmware version you’re using (at least in theory). So maybe you should just try a different patch.


Thanks that worked! A lot of new stuff now to test with owlsy :wink:

1 Like

Found here from the Daisy as Audio USB device thread, spent some time loading Owlsy onto Daisy Patch and it works!

After making sure Owlsy firmware is loaded on Patch device, I really enjoyed trying patches from the library on Rebel Technology website (With the latest Owlsy firmware, the patches on the website can be stored onto the device via browser directly, although some patches will fail storing to device, causing the Owlsy hangs requiring a hard reset, might be due to patch code size I guess). I hand-picked 40 cool patches and stuffed them onto my Daily Patch :slight_smile: Also I have tried building existing patch source code manually and using your fork of OwlProgram and running on my device successfully. Thanks for your outstanding work porting the OWL platform to Daisy!

Before I start building my own patches on Owlsy, I have some questions to ask regarding status for USB audio support:

  1. It seems the only capture device (audio input) is exposed (which is working), and the playback device (audio output) is commented in the code. Before I try building firmware with the comment removed, I want to ask if there is currently any issues in exposing USB audio playback device?
  2. It seems only 48k sampling rate is supported? Do you think it is possible to make it support 96k/24bit?
  3. I would be happy to help porting Owlsy to other Daisy devices (I got the garden set), and it seems I can start by forking your OpenWare repo and cloning DaisyPatch directory to make support for other devices?

Thanks again and Cheers!


Always nice to hear a success story! It would be interesting to know which patches failed if you can find some examples.

  1. The USB audio output should probably be left untouched for now. I’ve asked Martin from Rebeltech and it has a few problems:
  • Windows doesn’t work with it correctly for whatever reason
  • different type of USB audio (async device) is required to handle synchronization correctly

So basically, it’s disabled because Martin doesn’t thinks that it would work, but it would be improved and enabled later. I didn’t bother checking it on Daisy yet.

  1. Higher SR is possible, I think I could try to get this working. It does use 24 bit depth already, btw. But of course running at double SR would cut processing power into half effectively, because you’ll process the same amount of samples twice as frequently.

  2. You can’t help me, you can only do the port yourself :wink: I don’t have other Daisy based hardware and don’t plan to get it. It took ridiculous amount of time to get this working (porting from F4 to H7 MCU, resolving tonne of issues with QSPI, etc). So right now I’m mostly interested in incremental updates to OWL itself and porting them to this fork.

I would say supporting other hardware should not be too hard, because you’ll be able to use most of the codebase from port to Patch. I would suggest the following order: Pod > Petal > Field. Pod is simple and has only peripherals supported by Patch. It would be a nice starting point, plus there should be lots of users here that have it as it’s pretty cheap. Petal is still not too complicated, just has more knobs/buttons and would require a little bit of custom UI for encoder LEDs. Field would be most challenging, as it requires porting from libDaisy or writing from scratch some code for MUXed ADC and somehow exposing the keyboard to user patches. Maybe it could be generating MIDI events?

Either way, good luck with this. I will try to help if you’re actually going to continue with this.

1 Like

After some tweaks, I’ve made a build running at 96kHz SR. However, this makes USB audio non-functional. It might be exceeding bandwidth.

I’m not sure if it’s worth spending time on this.


Thanks @antisvin !

Sounds like I can go ahead trying to port Owlsy onto Pod first as you suggested :slight_smile:
Thanks for the information regarding USB audio playback and sampling rate support. I agree with current known issues it is not ready yet to expose playback channels to public, but I might still take some time trying as my own project currently plans to make Daisy work with linux as the only audio interface, to see if that works.
Regarding sampling rate support, in theory the bandwidth of USB 2.0 should be more than enough? but maybe I can also take some time trying here after successfully porting to Pod and see if it works with just stereo channels.

I will definitely keep you posted (with PRs hopefully) after I make some progress in porting.

Thanks again!

USB 2.0 is a set of standards that includes different modes. 480 Mbit/s is for High-Speed mode. This MCU supports only Full-Speed mode (12 Mbit/s) on its internal USB device peripheral. In other words, USB2.0 is backwards compatible with USB 1.1 and in this case we’re operating on 1.1 speed.

USB 2.0 HS is supported only on host peripheral if you use external PHY. So far nobody made an official Daisy based board that supports this.

@antisvin Thanks for the information!
I spenting some time googling and found some documents with the same information with as you described. Good to know about this limitation. I should probably go back to the USB Audio discussion thread and report what I found. Thanks again!