Major updates: beta firmware

OWL
#1

After months of hard work we’ve cracked a major nut: dynamic patch loading is working!
This means that you can load and run OWL patches from memory, over MIDI sysex. No flashing or firmware update required!

Actually we’ve got much more than that, but more about that in a moment.

To try it out (beta, remember!), do this:

  • clone the OwlProgram repository [1]
  • install OwlProgram prerequisites (read the README!)
  • spark up the old (most recent) OwlNest and download the OwlWare-vector-03 firmware
  • update your OWL with the new firmware
  • download and install (or build from source) OwlControl v0.1 [2]

OwlControl takes the place of OwlNest for this firmware. Changing patches is now done by MIDI Program Change messages, and there are no more red/green slots to worry about. You don’t need OwlControl to load and run dynamic patches, but it’s useful to see what’s happening on the device.

The OwlProgram readme has instructions for compiling, loading and running patches dynamically. OwlControl can stay open and connected to the pedal throughout, and there’s no reset required. Magic!

Oh and did I mention you can run C++, FAUST and PD/Heavy patches?

If you install emscripten [3] locally, you can even compile your patches to Javascript and run them in the browser. Now that’s crazy awesome!

If you don’t fancy life on the bleeding edge then you’ll just have to be a little bit patient instead. We will be updating the website with an online compiler, so you can take advantage of all this without having to install anything locally.

[1] GitHub - pingdynasty/OwlProgram: Dynamically loaded OWL program
[2] Releases · pingdynasty/OwlControl · GitHub
[3] http://kripken.github.io/emscripten-site/

#2

Firmware updated to OwlWare-vector-04-pedal.bin, available for download from the OwlNest.

#3

Version now up to OwlWare-vector06-pedal.bin.

This pre-release supports firmware updates over MIDI Sysex, which means it might be the last ever firmware update you have to do over DFU. More on that later.

Note: don’t download the modular version unless you have a pre-production OWL Modular!

#4

This a great news :slight_smile:

I’m trying to compile a Faust patch but it’s complaining about the STM32F4 headers (which I have but it doesn’t seem to be looking for them in Libraries). This is on OS/X Yosemite

Building patch DoubleTapeEcho
Tools/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-g++ -c -fno-rtti -fno-exceptions -std=c++11 -O2 -DARM_CORTEX -DEXTERNAL_SRAM -nostdlib -nostartfiles -fno-builtin -ffreestanding -mtune=cortex-m4 -fpic -fpie -fdata-sections -ffunction-sections -mno-unaligned-access -fno-omit-frame-pointer -flto -I./LibSource -I./PatchSource -I./TestPatches -I./Build -IOwlPatches -I./Build/HeavySource -D__unix__ -DHV_SIMD_NONE -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -I./Libraries -I -ILibraries/CMSIS/Include/ -I/inc -I./Source -I/Include -ILibraries/CMSIS/Include/ -I/Core/inc -I/Class/cdc/inc -I/inc -DUSE_STDPERIPH_DRIVER -DARM_MATH_CM4 -DSTM32F4XX -D__FPU_PRESENT -D__FPU_USED=1 -fno-builtin -std=c99 -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -I./Libraries -I -ILibraries/CMSIS/Include/ -I/inc -I./Source -I/Include -ILibraries/CMSIS/Include/ -I/Core/inc -I/Class/cdc/inc -I/inc -DUSE_STDPERIPH_DRIVER -DARM_MATH_CM4 -DSTM32F4XX -D__FPU_PRESENT -D__FPU_USED=1 ./Source/PatchProgram.cpp -o Build/PatchProgram.o
cc1plus: warning: command line option ‘-std=c99’ is valid for C/ObjC but not for C++
In file included from ./Build/DoubleTapeEchoPatch.hpp:56:0,
from ./Build/patch.h:1,
from ./Source/PatchProgram.cpp:12:
./Source/owlcontrol.h:6:23: fatal error: stm32f4xx.h: No such file or directory
#include “stm32f4xx.h”

Any ideas?

Chrissie

#5

There shouldn’t be a dependency on stm32f4 libs any more, so that must be a stray #include. Can you try removing the include, or (better!) pulling the latest from github?

#6

One of the changes in the beta firmware is that we have limited the number of ‘factory’ patches to a selection of 32:

FreeVerb Plate Reverb Jot Reverb Moog Drive Four Band EQ Parametric EQ Bandisto Overdrive StereoWah Pitch Shifter DualTremolo Phaser SmoothDelay Lowpass Delay Stereo Delay Psyche Filter Guitarix/Phaser Guitarix/Overdrive Guitarix/OscTube Guitarix/Distortion1 Guitarix/BigMuffFuzz Guitarix/Compressor Guitarix/Dunwah Guitarix/Moog Filter Guitarix/FlangerGX Guitarix/Tone OL/Dual Pitch Shifter OL/Weird Phaser OL/DroneBox OL/Thru Zero Flanger RS/Digital Mayhem RS/Reverse Reverb

If you think that there are other patches that should be on the list, let us know!

#7

There seem to be quite a lot of stray includes in the faust2owl generated code, though the stm32f4 came via owlcontrol.h :wink:

I removed loads of the ones that looked superfluous, leaving just StompBox.h and still ended up in a maze of missing methods and things so I think I’ll leave it for the moment. It compiles OK for the old firmware so maybe I’ll just go back. Maybe faust2owl needs updating.

Thanks,
Chrissie

#8

Yes, there’s been an update to Faust recently. We’ve submitted a new owl architecture file which should be in the next release.
Meanwhile grab this gist: OWL architecture file for FAUST · GitHub
Copy it to your faust installation directory, e.g. /usr/local/lib/faust/owl.cpp - then it should all magically work.

#9

yay! that now compiles thanks.

It seems to load onto the Owl when I do a ‘make run’ or a ‘make store’ but I can’t see it in OwlControl - and it has the messages “Failed to program flash sector” and “Missing or invalid program 0x60” on the screen.

#10

Can you PM me your patch, Chrissie?

#11

I can’t find out how to PM on this board so I’ll post it here. It’s pretty simple really!

import (“math.lib”);
import (“maxmsp.lib”);
import (“effect.lib”);

N = int(2^19);
ddelay(n,d,x) = x@(int(d)&(n-1));
duration = hslider(“1st tap mS[OWL:PARAMETER_A]”, 333, 0, 5000, 10)(SR/1000.0):int;
duration2 = hslider(“2nd tap mS[OWL:PARAMETER_B]”, 0, 0, 1000, 10)(SR/1000.0):int;
feedback = hslider(“feedback[OWL:PARAMETER_C]”, 30, 0, 150, 0.5)/100;
lpfreq = hslider(“LPF freq[OWL:PARAMETER_D ]”, 3000, 20, 5000, 10);

speaker = speakerbp(130,lpfreq);
echo = +~(sdelay(N, 1024, duration):speaker)*feedback;
echo2 = +~(sdelay(N, 1024, duration2):speaker)*feedback;
doubletapecho= echo: echo2;

process = (doubletapecho, doubletapecho);

#12

Cool patch.

N is too big, change it to N = int(2^14);
I’ll see if we can catch the failed malloc a bit more graciously, at the moment it leads to a null pointer error somewhere - hence the error message.

It then goes up to 106% CPU for me, with the associated nasty sounding drop-outs. Looks like speakerbp is really expensive! I tried it with resonlp instead and it sits nicely at < 50%

import (&quot;math.lib&quot;);
import (&quot;effect.lib&quot;);

N = int(2^14);
ddelay(n,d,x) = x@(int(d)&amp;(n-1));
duration = hslider(&quot;1st tap mS[OWL:PARAMETER_A]&quot;, 333, 0, 5000, 10)*(SR/1000.0):int;
duration2 = hslider(&quot;2nd tap mS[OWL:PARAMETER_B]&quot;, 0, 0, 1000, 10)*(SR/1000.0):int;
feedback = hslider(&quot;feedback[OWL:PARAMETER_C]&quot;, 30, 0, 150, 0.5)/100;
lpfreq = hslider(&quot;LPF freq[OWL:PARAMETER_D]&quot;, 3000, 20, 5000, 10);
Q = 0.707; // Butterworth
gain = 1.0;
filter = resonlp(lpfreq,Q,gain);
echo = +~(sdelay(N, 1024, duration):filter)*feedback;
echo2 = +~(sdelay(N, 1024, duration2):filter)*feedback;
doubletapecho= echo: echo2;
process = (doubletapecho, doubletapecho);
#13

Ah but bandpass (resonbp) is much more better still!
Great patch. Now who’s going to do a ping pong delay?

#14

Okay, so we’re up to vector08, which is the release candidate for the new version.

New in this version is a patch change feature: if you hold down the pushbutton for 3 seconds, you can change patch with the first two knobs. First knob selects one of 5 banks, second knob selects one of eight patches in that bank. If you have OwlControl running, it will show you the patch names as you scroll through them.

There is also a new version v0.2 of OwlControl. You can now upload sysex patches with OwlControl, and also update the firmware over MIDI (no more DFU drivers needed!). If you already have vector06 installed you can try this out. You will need to enter the correct checksum from the release page to flash a firmware with OwlControl.

#15

Some more major updates!

You can now compile your own C++ patches with our online compiler, and load them with the latest firmware and OwlControl.

To do so, first put your patch code in a GitHub repository. The go to PATCHES/My Patches on our website (you have to be logged in to see My Patches) and Add a new patch.
Enter your patch details and add a link to your github file. After saving, you will see a Compile button next to the patch details (channels, CPU et c). Press compile and wait for it to finish. If it fails, click Stderr to see what the errors were. If not, wait for the page to reload and there will have appeared a Download link. Yay!

Download the patch syx file to your OwlControl folder and go to OwlControl / Tools / Load patch from file. Provided your OWL is connected and all has gone well you can now click Run and your patch will come to life.

(Actually you can send the sysex file with any decent DAW or e.g. Sysex Librarian. To start it, send a MIDI Program Change 0)

At the moment this only works with C++ patches, support for FAUST and PD is coming… soon…

#16

Thank you so much for the help. I’m playing with different FX in the delay feedback loop … once I properly know what I’m doing I’ll probably have a look at a ping-pong :slight_smile:

#17

I try the OwlProgram but I have problem compiling and making work FirmwareSender under Windows.

After some modification in FirmwareReceiver.cpp I succeed to compile with VS 2013 but it is not working properly (heap error).

Does anybody has a FirmwareSender that is working under Windows?

#18

Did you use the VisualStudio project file in Builds?
You could also try generating build files for your platform from the jucer file, for which you will need the Introjucer
http://www.juce.com/learn/introjucer

#19

Yes I try with the VisualStudio project file (2010). They are several problem to compile FirmwareSender.cpp. For example #include <unistd.h> does not exist and I replace it by
#include <io.h>
#include <signal.h>

Then initialization like bool running = false; are not supported under 2010:

So I make a target for VS 2013 which give a little better result except for these two arrays:
unsigned char buffer[binblock];
unsigned char sysex[blockSize];

which cannot be initialized this way as VS 2013 request a constant expression, so I change the two like to make dynamics array but the binary crash at run time (segmentation fault):

unsigned char * buffer = new unsigned char[binblock * sizeof(unsigned char)];
unsigned char * sysex = new unsigned char[blockSize * sizeof(unsigned char)];

I will try to compile the original source under cygwin

#20

Right, variable length arrays aren’t supported by MSVC compiler, even though it’s C99 standard…
Probably better to use alloca, e.g.
unsigned char * buffer = (unsigned char*)alloca(binblock);
I think Giulio compiled a Windows binary, will see if he’ll push the changes.
Will also make a release with binaries for linux/mac/windows, but that might take a little longer.