Patch showcase - Stereo oscillator based on 3D curves

OWL Lich
,
#7

ooh with tasty Perlin noise, too!
:+1:

#8

I think that something like this would work: generate 3D points (from a 3D VCO or a 2D VCO with Z axis set to 0), apply transformation, play XY data as a stereo oscillator (ignoring Z axis). The transformer class would handle only second stage in this case. Of course it’s possible to process transformer’s output in different ways (just play 1D or do some extra processing in quadrature before playing stereo output).

And BTW, I obviously don’t say that you have to work on those addition to OWL library - it’s just that I was thinking about doing exactly the same thing recently based on that polygon VCO patch. We had a video session where that patch was used to control a laser, so I’ve figured out that a more functional generic processor for multi-dimensional output would be quite useful.

#9

Patch of the day indeed!!! :smiley:

1 Like
#10

Y’all are too kind, thank you!

#11

I don’t know if its a problem with my device / browser, or the patch library, but the patch won’t load or store onto my device. What I get instead is a Error 0x60 No program to run error and the chrome console also says:

sending patch from url //www.rebeltech.org/api/builds/605fe94a885ae94ff012f3a6?format=sysx&download=1


GET https://www.rebeltech.org/api/builds/605fe94a885ae94ff012f3a6?format=sysx&download=1 404 (Not Found)

any help is appreciated!

#12

Yeah, the patch binary is gone - I would guess that it could happen if author tries to rebuild it and it fails. You can still build it locally from sources until there’s a replacement. Or create a copy in your account and build it without publishing.

@mars, can we have a safer rebuild procedure that would preserve the old patch sysex?

#13

Oh, strange, I’ve just recompiled it through the patch page and it compiled without error, I’m pretty sure that was the case the time before, but maybe it will install now if you try it.

#14

This patch sometimes crashes my Lich (running v21.2.2) with Error 0x60 Err 04

#15

Thanks for the heads up. I haven’t actually run it since upgrading my Lich to that firmware, but I’ll try to take a look this week.

1 Like
#16

@dreamer Where do you actually see the error readout? I have been compiling and loading on my Lich entirely from the patch library website and haven’t seen any debug output from the Lich there.

@mars how would I figure out what that error code means?

#17

@dreamer would also be helpful to know if this is a crash that happens after the patch has been running for a while, or if it happens right away. if it happens when changing certain parameters or seems random. I don’t think I have enough info to figure it out just yet.

#18

I will add that there’s support for using valgrind when building patches locally with “make grind” command in OwlProgram. It’s generally useful, however it didn’t detect any issues for this patch.

There’s also a possibility that there was some issue in OwlProgram itself that has been fixed since then, but patch in library was built with older version. I.e. we were making a few updates to zero-fill allocated memory.

#19

I saw this in the website while connected to the Lich. However I’ve been playing with your patch for hours some time after and it seemed to work fine again. (been having fun with this one!)

It seems that if we have both usb-host and usb-client connections at the same time things get unstable. Sometimes the usb-host will drop after a while, but if the usb-client isn’t connected (to the computer) it seems much more reliable.

#20

@antisvin good to know about the valgrind support. I was also wondering last night about what kind of profiling options there are, whether it’s possible to profile a patch while it runs on the Lich, or if we have to build native to do that.

@dreamer glad it’s working well for you now. I had the same thing happen with usb-host last night after working on a patch for a long time.

#21

I don’t think there’s a way to profile/debug patches on device directly. OWL is running on baremetal hardware with an RTOS, patches themselves have separate stack and are loaded to memory at runtime. So patch code is not visible with a debug build of firmare. It’s impressive that Martin made it work in first place, but unfortunately patch contents is a black box for normal tools that are used to debugging firmware.

If you want to profile performance specifically, it might be possible to read MCU cycles counter from memory directly. This is the register that is used by firmware for measuring CPU load, so you could try reading a 32bit unsigned int from 0xE0001004 before/after function call (haven’t tried it myself). Also, https://godbolt.org has support for gcc-arm, I’ve used that for checking how different end up compiled a few times.

Also, I was told this may be useful with native builds - gdbplotlib · PyPI (haven’t tried it myself too!)

1 Like
#22

Awesome, thanks for all that info and resources.

#23

There are methods in Patch you can call to get the number of cycles, or time, since the start of the block.

https://www.rebeltech.org/docs/classPatch.html

So you could do e.g.

float t1 = getElapsedBlockTime();
dosomething();
float t2 = getElapsedBlockTime();
debugMessage("time", t2 - t1);
#24

I’ve updated this patch so it now smoothly blends between the overtones introduced by P and Q integer values and I added parameters to set the FM Ratio (was 2x the oscillator frequency, can now run from 1x to 4x) and zoom the camera in and out (defaulted to zoomed all the way in).

I’ve also added a Genius version that maps the parameters slightly differently and allows independent control over the X, Y, and Z rotation rates (they are tied to P, Q, and S in the Lich version). The Genius version also displays the knot on the screen so you don’t need a scope to see it. :slight_smile: I’ll probably do a video with the Genius soon.

#25

Knoscillator G! That’s my favorite gangsta rapper!

I think it would be usable on more than Genius if you move Tune to first parameter. Parameter E is the expression pedal input on OWL modular/pedal and is present on some devices (i.e. Witch). When it isn’t available, losing direct control for Morph seems like the better option. And patches with UI will run on devices without display without issues as you probably know. That said, it begs for either editing with encoder or using an external MIDI controller.

Have you considered using right audio channel for external FM signal instead of internal modulator’s envelope? It seems like a bit more interesting way to use it.

Also, how does PM work/look on this oscillator? In case of quadrature stuff that I’ve experimented with it preserves VCO’s visual shape unlike FM. Might be an interesting direction to check if you haven’t tried this yet.

#26

Yeah, my intention for the Genius version is that it is specifically for the Genius, the Lich version is probably more appropriate for older devices, particularly the Witch.

I did consider that and you might be right that using an audio input for external FM would be a more interesting way to use that. It is the way it is because I wanted to have CV control over the amount of the internal modulator because that modulator is sync’d to the frequency of the oscillator, which provided an interesting way to “brighten” the sound. If I moved it to a MIDI parameter on Lich it’d be much more difficult to get dynamic changes to it and creating a similar effect with external FM would be much more complicated. I suppose I could move that to parameter B on the Lich and move Morph to a MIDI parameter, I’m on the fence about losing direct control for Morph. The change in sound is definitely less dramatic than controlling the amount of the internal modulator.

The internal modulator is doing PM, not FM, even though the parameter is called FM. And yes it’s like that because it doesn’t disrupt the fundamental pitch as much, it just makes the sound “juicier”. See: