Strange issue with programming OWL Modular

OWL OWL Modular
#1

I got one of these devices used last summer. The built-in patches seem to work OK. It is trying to program the unit that is acting strange.

I’m on Windows 11/Google Chrome.
It has the v12 firmware installed.

I can browse the programs and choose between them using OWL Patch Library – Rebel Technology. If I browse the patches, I can “load” them (sometimes) and “Store” them (rarely).
Browser likes to lock up, the red light blinking on the unit. Have to power cycle it.
Tried downloading sysex and send using MIDI-OX, “runs out of buffers” about halfway through.

For example if I try to store something to slot 38, I get “Invalid program slot”.
If I try to store something to slot 1, I get an overwrite warning but it stores to slot 38.
Deleting a program slot does not appear to do anything.
I’ve managed to get programs 37 and 39 into an “untitled-something” state.
I also attempted to use the web-dfu but it does not recognize my board. Have not tried the Windows utility yet.

I know this is not the worlds most current or popular module, just wondering if anyone recognizes these symptoms. For what I paid for it, it’s OK just to have the built in programs, it’s just a bit frustrating I can’t get any of this other stuff working reliably.

Thanks, DL

#2

Using Zadig I was able to upgrade the firmware on the unit to 21.2.1. Loading patches is more successful now. I get the impression that these patches are not vetted. Some of them just don’t work.

DL

#3

Hi Larry,

There will inevitably be patches that don’t work on old hardware, because it has less SDRAM among other things. I.e. OWL1 has 1MB, OWL2/3 has 8MB and Xibeca has 32MB. In addition to that OWL3 and Xibeca have MCUs that are about 3.5x times more performant. So some newer patches will end up not working on them just for these reasons. There could be some software compatibility issues in patch binaries too, even though this is avoided whenever possible.

Patches are not “vetted”, since the library is open for everyone. This has its ups and down. I personally wouldn’t want to have anything preventing users from submitting their code, but rather have some way to leave feedback from patch users, classify patches by supported platforms and maybe making multiple binary builds for different versions of OWL platform.

2 Likes
#4

Hi @antisvin thanks for your response. I get it. I spent more time than I imagined on the Owl Modular this weekend. I was able to make patches in Pure Data and Faust. I noticed that some of the available patches sound terrible. I think this is down to the RAM as it is either a delay or reverb patch. The echoes sound noisy/distorted/gated and it does not appear to depend on the input level.

Oddly, when I made a simple delay in Pd it was also quite noisy. A more elaborate modulated delay written in Faust sounds much better. I’m OK sticking with Faust but I wonder why this is?

I have published my Oil Can Delay in FAUST. It is just a starting point but I think it sounds pretty good. The “emulate” feature in Chrome just clicks.

DL

#5

Analog inputs contain some amount of noise from ADC. You have to apply smoothing on them in certain cases. If you use them for things like delay line length, applying hysteresis to avoid changes due to noise is even better. There are several topics here discussing this issue, you’ll probably find them with forum search if necessary.

1 Like
#6

Yeah thanks, interesting thought. I do use si.smoo() on almost all Faust signals without thinking about it. I’m not sure how much further I’m going to go with this Owl modular, although who knows. I’m just running out of rack space as usual. Looking at Daisy Patch, which although it doesn’t directly offer Faust support, is actually relatively current and supports 4 audio channels.

#7

You can run OWL on Daisy Patch too, but you’ll be missing DC coupled audio inputs/outputs.

1 Like
#8

Interesting. Yeah I don’t know that I’m really looking to get rid of the OWL so much as I want to play with something a little more powerful. I guess I’m not in a hurry. There’s also the “patch.init()” but AFAIK it only does one thing at a time and you have to reprogram it to do something else (which involves pushing buttons on the back of the module). I can see myself getting tired of that pretty fast.

By the way I went back to one of my PD patches that I said was really noisy, and I put “line~” objects in all the control signals and now it sounds pretty good! I just have to learn a bit more about how PD works to become fluent in it.