Short version:
We will soon launch a new Eurorack module called Genius, based on updated OWL3 hardware. OWL3 is apprx 4 times faster than OWL2, meaning moar patch!
Long version:
coming soon…
2 Likes
Very exciting to have this finally announced!
While waiting for the long version, I feel like making a comparison for 3 generation of OWLs just to put things into perspective for anyone interested. This covers mostly microcontroller differences. I think this info can be found out from just browsing project sources in github by anyone understanding what to look for, so hopefully I’m not leaking anything secret here!
So OWL1 (pedal/modular) and OWL2 platforms (everything after that) had a fairly similar MCU from STM32F4 series clocked at 168 Mhz. OWL2 used a different part number that had extra 64kb of internal SRAM. This allows using patches up to 144kb in size while OWL1 was limited to 80kb. Or you could keep some data in there instead of using slower external SDRAM. Either way, most non-trivial patches would have to use some amount of SDRAM.
The biggest changes between those 2 platform was a new audio codec with much better audio quality and larger memory chip (8Mb SDRAM vs 1Mb of expensive SRAM) allowing using it for longer buffers in loopers/samplers without sacrificing audio quality.
Now OWL3 is at the door and keeps the same audio codec and SDRAM chip, but MCU is a huge step forward. It’s an STM32H7 chip clocked at 480Mhz, meaning that you get about x3 speedup from increased clock alone. This is not quite an accurate estimate on its own, because MCU has some improvements that gives it extra performance clock by clock.
In addition to that, MCU core has fast internal cache for its command and data pipelines (16kb for each) that reduces overhead for running code, SDRAM access and so on. This makes things noticeably faster when SDRAM chip is heavily used for things like multiple delay lines. Very short patches also get a huge boost if their code procedures fit entirely in cache.
Amount of internal SRAM is also increased to around 1Mb (was 128k on OWL1 and 192kb on OWL2, 48kb are always used by firmware). This means that many patches that had to use SDRAM previously can fit in faster SRAM now.
The largest contiguous SRAM section is 512kb and we can support building patches that are placed into that memory region. This allows making patches of up to that size if necessary. There hasn’t been much issues with patches not fitting in memory in the past, but now we have an option of using some large code library as part of the patch, maybe even some small programming language interpreter can run as part of the patch!
Last big change is that floating point unit on this MCU supports double precision operations in hardware. While using DP incurs extra CPU usage, it can be beneficial for certain DSP algorithms as it gives you way lower computational errors. So it’s another choice for users that have use cases for something like this. It looks like patches in SOUL happen to use more frequently, but FAUST or C++ should be able to utilize it too.
My experience is to expect code to run x3.5 faster, but frequently patches get x5 or higher performance boost when they run into sweet spots discussed above (i.e. if we can replace SDRAM access with SRAM, run small patches, have lots of sequential access to SDRAM that gets improved by cache). So I would agree that x4 times faster patches is a realistic expectation if you have to give a single number, even though it would vary from patch to patch.
If all of the above is too long and confusing, I’d suggest looking at the difference between Mutable Instruments Clouds and Beads that had the same CPU upgrade (STM32F4 → H7). This allowed significant improvements to algorithm, processing more data in better quality and so on.
For the history buffs: OWL1 had an STM32F407 and 1Mb of (expensive) SRAM, because the STM32F42x with SDRAM support had not yet come out.
Very cool, haven’t realized that it was SRAM and that the memory controller change happened. I thought it was just a legacy part that went out of production.
I was looking for an SPI based SRAM chip for modding some hardware recently, but they seem to be available in 128kb size max that is already on device unless you go for less common technology like FRAM/MRAM. No wonder that it became a problem!
Will there be a OWL3 version of the witch as well?
There are some other good news for owners of OWL2 hardware and I’m sure that you’ll like the answer. Except that it wasn’t announced publicly yet, so I’ll let Martin leak his own secrets when the time is right!
I see this has separate MIDI out ports. So am I right to assume I can run midi controller in via USB or MIDI in port, do some midi-math in there, perhaps make some sequences and run 16 channel midi out to my synth via MIDI out jack and have one channel to set set lights on my controller via USB?
I am specifically considering this to build my own sequencer in Pure Data using midi controller for controlling the module, is this possible on OWL and this? I have done it before on Bela, without the separate midi out.
Well yes you can probably do that, if I understand you correctly. One of the 16 channels would be controlling the lights?
At the moment, MIDI messages sent from a Pure data patch will go to all MIDI outputs on the Genius: the two USB’s and the TRS jack.
The plan is to use the port identifier (see this discussion) to distinguish between the different hardware interfaces. That will allow us to use 16 channels per port with three different ports on the Genius, but that is not implemented yet. Instead there’s 16 MIDI channels to share between all connections.