OpenWareLab

Documentation for the OWL family of devices.

View the Project on GitHub antisvin/OpenWareLab

Owlsy FAQ

Is it a bird, is it a flower?

Owlsy is a port of OWL/OpenWare firmware to Daisy hardware

Which devices are supported?

Currently it runs on Electro-Smith Daisy Patch, Daisy Pod and KXMX Bluemchen with old Seed 1.0 or 1.1 revision (since v25.0). Patch.Init() is also supported starting with firmware release v24.2.

Is it an official firmware supported by Electro-Smith or Rebel Technology?

It is not, so don’t expect any sort of guarantees or support from those companies.

Which peripherals from Daisy Patch are supported?

Everything works!

How are flash storages used?

Internal flash is only used for bootloader. Firmware and patches are stored on external QSPI flash chip.

What’s the maximum patch size?

By default up to 80 Kb is available for patch. This includes patch code and stack. This is sufficient in most cases, but it’s possible build patches that would get allocated in another memory region that can utilize up to 510 Kb. To do that you must set PLATFORM=OWL3 as environment variable when building patches. This requires building your patch offline, but official Rebeltech web patcher would support this option in the near future.

What about SD card?

Upstream OWL firmware doesn’t support it, but conveniently its resources API is abstract enough to use SD card instead of flash as a fallback option. This means that patches would be compatible with upstream firmware.

Currently resources can be accessed only from C++ or from FAUST using its soundfiles API.

SD card must be formatted in FAT32 (exFAT is not supported) and contain OWL/storage/ directory that would be used for loading files. So loading a resource named foo.wav would read the file from OWL/storage/foo.wav unless resource with foo.wav name is found on flash.

Restart is required if you don’t insert card when device boots or remove it later. In addition to that, it’s not recommended to keep a card that uses resources in the first patch slot as that seems to cause occasional firmware hangs if SD card is not inserted.

How is memory used?

How can I run it?

  1. Install MidiBoot port like a regular Daisy patch (using DFU or programmer)

  2. Enter bootloader mode. If you have no valid firmware on QSPI chip, this would happen automatically. Otherwise, send the following SySex data to “OWL-Daisy” USB device: f07d527ef7 . As an alternative you can press and hold encoder when device boots to force device stay in bootloader.

  3. Flash firmware. This requires sending firmware SySex image to bootloader.

  4. Wait for device LED to stop flashing (firmware loading should take 5-10 seconds) and reboot. This can be done by pressing the reset button or by sending the following SySex command: f07d527df7

Where can I get binaries?

https://github.com/antisvin/OpenWare/releases

MidiBootDaisy*.bin is the bootloader file.

DaisyPatch*.syx, Bluemchen*.syx and PatchInit*.syx are firmware binaries converted to SySex format.

How can I build firmware from source?

You will need to use the following branches from Github:

Firmware building info on Mac is described in Electro-Smith wiki

How do I build patches?

The easiest way is to use the RebelTechnology web patcher

Offline building is possible with OwlProgram repository. STM32H7 and multi-channel audio is supported in upstream reposittory now, so original instructions fully apply. To enable quad channel audio on Daisy Patch you should set PATCHIN=4 PATCHOUT=4 when building patches.

Where can I see some patch examples?

Start with tutorials and library documentation. As for code, largest collections are:

How are patches controlled?

OWL firmware supports using up to 40 parameters. On Daisy Patch, the following mappings are used:

You can also address gate inputs as buttons A/B, gate output as button C.

On Bluemchen parameters A/B are obtained by summing a knob and its respective CV input.

This is full list of parameter names.

Patch.Init() support the following controls:

How does Owlsy UI work?

With display

Devices with display have a builtin UI that cover most firmware functionality.

Long encoder press brings out active parameter selection. When you’re in this menu, you can turn encoder to change active encoder. Releasing it returns you to main menu.

Active parameter value can be changed by turning encoder when you’re in main menu.

Short encoder press brings out settings menu. It contains multiple pages that can be scrolled by encoder. Long press or scrolling it to the end exits this menu. Current UI pages:

Without display

When no display is present, most features require access by MIDI.

Patch.init() has a configuration menu that is enabled with a long button press. When entering this menu, you will see the LED strobing for a short amount of time. There are 2 functions you can access this way:

On Daisy Pod

Pod is a bit special in the sense that there’s only 2 knobs which makes it too limited for adequate control of all 40 parameters. Luckily there are 2 RGB LEDs which allows making a UI for multiplexing them.

The default state is giving you access to the first 2 parameters (A & B). Turning the encoder clockwise sets next pair to be active, counter clockwise returns to the previous pair. When parameters are switched, they get locked and no longer controlled by knobs. When you return to the locked parameters, they become unlocked once you set knob position close enough to previous value.

Upon parameter change you can determine currently active value by LED colour and the amount of strobing LEDs. There are 8 LED colours in Pod UI used in the following order (following rainbow spectrum):

  1. Red
  2. Orange
  3. Yellow
  4. Green
  5. Cyan
  6. Blue
  7. Violet
  8. White

First 16 parameters (8 pairs) are indicated by both LEDs strobing, for the next 16 only first LED strobes and for the remaining 8 only second LED does.

The encoder click activates patch selection mode that stays active until you click again. In this mode the selected patch slot number is encoded in octal numeric system using the colour sequence mentioned above. So RED + RED means number 0, RED + ORANGE is 1… ORANGE + RED is 8, ORANGE + ORANGE is 9, etc.

Note that patch slot 0 is used for dynamically loaded patch and may not be available, then patch numbers 1 to 60 are used by patches in the flash storage on device.

If patch or parameter offset modes are not active, green LEDs are used to display button 1/2 state. Error status is displayed by both LEDs flashing red in turns. Rainbow gradient is used to display progress indicator when loading patches or flash resources.

When you’re in the bootloader mode, blue LED 1 is used to show bootloader activity. LED 2 will be set to red to indicate error state.

I have more questions!

This port should be discussed on Daisy forum.

Questions about writing patches (unrelated to Daisy) can be asked on RebelTech forum.

Changelog

V21.0

Initial release

V21.1

V22.0

V23.0

V24.0

V24.1

V24.2

V25.0

V25.1

Bootloader changelog

V0.1

V0.2

V0.3

V0.4