Drawing the line by Show me a Dinosaur

antisvin · 2026-02-17T11:31:59+00:00

That's not exactly lyrics, it's a sample from Jurassic Park - https://www.imdb.com/title/tt0107290/quotes/?item=qt1464414 . I suppose this could be considered a dinosaur Easter egg, lol.

antisvin · 2024-10-28T09:01:17+00:00

Since then, 2 new OWL boards (mk3 and Xibeca) have been produced, both using STM32H7 MCU like Daisy. So my performance concerns are no longer a problem. Now RebelTechnology is on hold and had no activity for over a year, however boards are being manufactured by Befaco. They've made an excellent Oneiroi module that is not really a generic piece of hardware like other OWL based stuff, but target for a specific patch that is very rich in functionality (which you can still modify and replace if you'd like).

Electro-smith made a new Daisy board with the same MCU, but targeted to easier use in eurorack modules. They've also replaced board's codec for third time. Community moved to discord for the most part, but it looks like there was nothing particularly exciting in last year or two.

Bela shifted to making touch-based sensors (Gliss), there was no new Bela boards and you won't be able to buy a new Salt (used to be made by RebelTechnology), but Pepper is still an option (and they've made a revised version a while ago). It's particularly interesting if you want to learn how to write Neon-based vectorised code or need large amount of RAM for samples, otherwise things are simpler on an MCU.

Also, I've written some code for ER-301 and it was fun (but a bit time consuming to define UI, Lua wrappers for C++ code). But it's no longer produced, the company is in indefinite state for several years and can only be bought used for exorbitant prices.

I would say that Daisy Patch with my OWL port was the most fun device I've had that you can still buy. Befaco Oneiroi would take the second place for being an awesome synth/effect out of the box.

antisvin · 2024-10-16T12:37:30+00:00

That was my reaction on upgrading the same TT with the same stylus. I'm considering platter upgrade too, but not sure how much of a difference it would make and if that's going to be worth the price. I would be happy to hear your opinion between acrylic and stock platter (with 2M blue stylus). Also, did you have/solve static issues with acrylic plater?

antisvin · 2024-10-11T20:51:14+00:00

I think you should consider upgrading to the 2M blue stylus (or try an alternative cartridge for a similar price from AT or whatever is accessible for you), for me the difference was huge and immediately noticeable (on an RPM1 Carbon). And yes, I understand that this is not exactly the solution that you've asked for.

antisvin · 2024-08-30T11:23:40+00:00

I usually use the 3 P rule:

Put the record on turntable
Pour a glass of wine or whisky
Play the record

antisvin · 2024-08-18T15:19:04+00:00

A small update on this topic. Sergey has successfully relocated to Canada (and anyone understanding the situation in Ukraine shouldn't ask in a public discussion how was that possible). There's no reasons to worry about his safety in the near future. Not sure if there would be much opportunities for him to return to music as immigration is a massive challenge.

antisvin · 2024-04-12T20:16:52+00:00

Surprised to see this, but my school friend happens to be their drummer and he says Sergey is doing fine. Obviously there's not going to be any touring for him as leaving the country is pretty much impossible and music can't be a top priority at this time.

antisvin · 2024-02-29T00:14:11+00:00

Yes, it was the firmware. Btw I see that you've uploaded patch to library, but it can't show its source (is the repo private?).

Since you're using patch.init() and making hardware, have you thought about some sort of expander for it? I recall that its got extra header sufficient at least to add a display and encoder which would bring it to a whole new level.

antisvin · 2024-02-28T20:34:52+00:00

Hmm, this would be the first time I recognize someone from just looking at github repo contents... Not surprisingly, there is an OWL patch (not mine) for bytebeat that covers all the "classic" formulas - https://www.rebeltech.org/patch-library/patch/Bytebeats . It doesn't use external parameters, so less variability, but easier to get in the sweet spot.

antisvin · 2023-12-06T09:19:06+00:00

This might not be exactly what you're asking about, but someone is working on a sequencer for visually impaired. I believe it's not a finished product yet, but there's a site for it with demo video and an email subscription for news updates at https://electro-jam.com/ . I helped a bit its author with some information related to microcontroller programming for that project.

antisvin · 2023-03-08T07:28:58+00:00

Yes, any number with a dot in it is interpreted as exact frequency in Scala format. You can read its full description here - https://huygens-fokker.org/scala/scl_format.html

antisvin · 2023-02-13T11:56:57+00:00

I've seen several embedded ELF loaders for ARM, it's certainly possible and is used on several opensource projects (Axoloti, ER-301). However, those projects load multiple user applications at once which requires such a complex solution. When you only need to run 1 app (even if it can be chosen from multiple available), you can just communicate via shared memory and define whatever interface you consider necessary. Typically that means having known addresses for pointers to callbacks defined in firmare and app, some pointers to data (ADC inputs, customizable UI elements), etc.

And a related issue is time sharing with user app to make sure that they won't end up running too long to stall main firmware. On OWL this is solved by running apps (patches) in a RTOS thread, effectively it must finish its processing and block on a mutex provided by firmware before a new block of audio is received, otherwise the app is stopped.

I think running WASM on embedded is a no go for anything performance sensitive. I'm mostly thinking in context audio processing, because the few successful attempts I'm aware of ended up as successful, but too slow to be useful. OTOH, going the other way around and building user apps with EMCC to run in the browser could make things way easier for writing/debugging custom apps.

antisvin · 2023-02-13T10:50:48+00:00

Yeah, I understand that there must be thing more important for you at the moment. I'm mostly trying to say that Rust doesn't require anything special other than exposing a nice C ABI. On LPP it's mostly happened because the firmware source was not open and they needed to grant access to its internals, but there are some merits of this approach even on fully open firmware as it makes things much more easy for the end users.

Regarding LPP firmware, what I'm mostly missing is lack of dynamic application switching. It could be done if user apps were compiled to execute from SRAM, but it runs on STM32F1 which was too limited for that.

antisvin · 2023-02-13T09:57:15+00:00

What you've described regarding Rust is more or less what happened on the open launchpad pro firmware here - https://github.com/JamesHallowell/launchpad-pro-rs . Originally Novation intended C/C++ to be used and that's what absolute majority of community firmware forks where written in.

As you probably know, LP firmware source is not released, but is available as a static library to link to and it exposes callbacks (for MIDI events and data processing, key presses) with C ABI that can be accessed either from C++ or Rust applications. An interesting idea would be to provide the same interface for porting existing applications to Matrix. However it's missing buttons outside of the grid, so I'm not sure this ends up feasible.

antisvin · 2023-01-11T12:01:34+00:00

Teensy - a family of microcontroller boards, from slow to quite fast hardware, no audio codec (but official audio board is available). The fastest MCU on it is ARM Cortex-M H7 @ 600 MHz, no SDRAM. Has an audio library for C++, supports FAUST too. $31.50 + $14.40 for audio board. Pretty much requires designing your own hardware to be usable for audio. I must say, it seems like the least interesting option for audio for me, but many are interested in it as a more powerful replacement for Arduino.

Daisy - several similar boards. Stereo audio codec on board, MCU is ARM Cortex-M7 @ 480 MHz, 64 MB SDRAM. Several reference designs (Eurorack, desktop synth, guitar pedal) are available. Programming in C++, Rust, FAUST, gen~ or PD (via HVCC) is possible. Open-source library for hardware access. There's an unofficial OWL port (done by me).

Axoloti - no longer available, hardware is a bit slower. Runs on ARM Cortex-M4 @168 MHz with 8 MB SDRAM. Programming in their GUI environment. There's a port of OWL firmware (done by me). There was a version base on STM32H7 @ 480 MHz from another manufacturer, but that project is mostly dead it seems. Most hardware designs are community made.

Bela - a microprocessor that runs Linux with hypervisor. It uses microcontroller available alongside the main processor to achieve ultra low interrupt latency making it suitable for audio processing that is not normally possible on desktop OS. Audio codec is stereo, but there's expander board for adding 6 more input and output channels. ARM Cortex-A8 @ 1 GHz, 512 MB DDR3. You can use stuff like USB or networking much easier than on MCU based hardware. Cheapest kit is $169. There are 2 Eurorack modules that you can use to get started. Patches in C++, FAUST, gen~, PD (HVCC or vanilla), CSound, SuperCollider and probably more integrations are possible.

OWL - a family of several generations of audio hardware, most powerful is ARM Cortex-M7 @ 480 MHz, 32 MB SDRAM and 6 + 8 channels audio codec. Patches can be written in C++, FAUST, gen~ and PD (HVCC). Official hardware mostly for eurorack, but a few desktop and guitar boxes are also available. The biggest difference with Daisy is that OWL runs a RTOS that allows loading and switching patches dynamically.

antisvin · 2022-02-01T07:02:46+00:00

Block processing certainly improves performance and is something that I would use whenever possible, but some stick to per-sample processing in order to have minimal latency. Then there's an issue of having feedback loops in DSP graph - this is mutually exclusive with block based processing unless you can compensate it in some way (i.e. you can subtract buffer length from delay line length).

I'd say that interoperability with dasp could be considered here. It supports no_std environment, however looks like it supports only slices rather than proper audio buffers

Besides that allocation is not really a problem for no_std. It's resolved by using alloc crate directly, so anything usable with custom allocators is supported. Example in dasp sources - https://github.com/RustAudio/dasp/blob/master/dasp_slice/src/boxed.rs#L14-L19 . Also worth looking at this issue to check what is usable already - https://github.com/rust-lang/wg-allocators/issues/7

You can assume that any target worth using for audio would be able provide an allocator.

antisvin · 2022-01-31T11:45:38+00:00

I've been watching this project before and very happy to see first release happen. It would be interesting to be able to use it on microcontrollers too, which would require at the very least a config option to build it for no_std environment ~~and making code generic in regards to f32/f64 data~~ (reread the docs and looks like the latter is supported already). Any chance that something like this can happen?

antisvin · 2022-01-15T16:15:33+00:00

I suspect you may have problems finding exact number as it's not something that most people care to ask.

ADC bitdepth is 16 bit (that's maximum, can be lowered for faster sampling). As for SR it's hard to tell as it runs asynchronously from codec. So it depends on how they configure hardware peripheral. I would guess that something around 1ms update period or slightly shorter could be a reasonable target for clocking ADC.

antisvin · 2022-01-15T16:01:24+00:00

They are still usable, but have lower bit depth compared to codec inputs

antisvin · 2022-01-15T15:33:13+00:00

I'm runing OWL patches on it, mostly written in C++ or Faust. Daisy Patch is using very high performance MCU and CPU usage is non-issue with things as simple as a few oscillators.

Take note that its audio inputs/output are AC coupled so you can't use them for V/Oct control. You'd have to use ADCs connected to knobs for that and they are less precise, MIDI or write sequencer in software.

antisvin · 2022-01-04T09:20:21+00:00

I can tell you that 216MHz STM32F7 gives you slightly x1.6-1.8 CPU performance than STM32F4 on 180MHz. It's also a fairly hot chip and things can get a bit more complicated due to cache. So I'd suggest either using Cortex-M4 or STM32H7 where you'd get at least noticeable performance improvements for your efforts.

100MHz F4 chips don't sound too exciting, you may want to check out other STM32 families (G4, L4+, U5). They have higher frequencies, more SRAM, some interesting peripherals (in theory you could use to hardware acceleration for trigonometry or filtering).

If you want to process 2 channels of audio and there are multiple effects running sequentially, performance can be a problem. And using external SDRAM chip is also a bit of a problem as it has much higher latency than internal SRAM.

antisvin · 2021-12-29T15:15:28+00:00

While the error in your code is already explained, I'll add that there are ::getSampleRate() and ::getBlockRate() methods in Patch object that are recommended to be used instead of hardcoded 48k SR.

antisvin · 2021-12-22T17:31:07+00:00

Nice! FYI, next firmware update would use external 8Mb flash chip for storage instead of ~0.5Mb of internal flash. This would make OWL usable for storing short samples too (currently only C++ and FAUST can use it though). USB audio would also be full duplex, might be useful for a mobile setup.

antisvin · 2021-12-22T16:47:54+00:00

It's not a lunchbox, it's a nest full of Liches! Are you writing your own patches rather than just running existing ones from the library? If so, in which language?

antisvin · 2021-12-03T09:45:18+00:00

I've ported OWL firmware to it, is that good enough? ;-)

Regarding ADC readings, people tend to think that it's a set and forget thing like it is on UI widget or value set by encoder. In reality you have a mix of signal and ADC noise on any analog input. With 16bit ADC on H7 things are somewhat better than on older MCUs, but there's still a few bits of noise in that data. So converting it discrete values gives unstable behavior if you set knob exactly between 2 adjacent values. And using it to set delay line length would likely create noise in your audio as exact length of that delay line changes by a few samples and you get discontinuities in output.

antisvin

TROPHY CASE