Patch showcase - Stereo oscillator based on 3D curves

I finally finished my first patch for Lich, which is a stereo oscillator that oscillates over a 3D curve, projects it 2D, and uses the X-Y coordinates as left and right outputs. The curve rotates in 3D space, which animates the stereo field in a really nice way. I call it a Knoscillator because the curves are based on parametric equations for so-called Knots. I’ve got a demo on youtube that runs through all the parameters, that will probably make more sense than these words.

You can install it from the patch library here: https://www.rebeltech.org/patch-library/patch/_Lich_Knoscillator

Would love to hear what folks think!

1 Like

@Befaco get you PR & marketing teams ready, we’ve got a new patch of the day here

What I think is that the patch is awesome, but I expected no less when I’ve found out that a patch that requires float matrices is being written. But I have some suggestion/ideas.

So this is somewhat similar to a patch that I’ve made recently , except that I was generating a 2D polygon that can be rotated in 3D as one of the effects. Something similar with rose curves is in progress too.

I’ve created a class for quadrature oscillator https://github.com/antisvin/MyPatches/blob/master/C%2B%2B/QuadratureOscillator.hpp and subclassed it to implement rendering different 2D oscillators (rose, polygon, probably will add some other cycloids). This allows reusing code for making versions of the patch that run on devices that require different control mappings or to experiment with adding other effects without copy-pasting.

I think we should petition @mars for adding official 2D/3D oscillators to OWL library (how does he expect people to make those quaternion dubstep wobbles otherwise?).

It would probably make sense to have a separate transformer class (implementing MultiSignalProcessor intrerface. Again, this is a totally generic operation that probably belongs to the library.

There’s one more thing! OWL parameters are already controllable by MIDI/CC, you don’t need to handle it in your patch. This is mappings lists supported: OpenWare/OpenWareMidiControl.h at master · pingdynasty/OpenWare · GitHub

So it makes sense to change your controller to use correct values rather than remap them in every patch.

Ah, yes, I noticed your Polygonal VCO in the patch library last night and played around with it a bit, it’s cool! If I understand you comment about 2D/3D oscillators and then a separate transformer class, you mean that in my case I’d have a 3D oscillator that generates the 3D points and then a separate transformer class would convert those to 2D? Or would the transformer handle the rotation, kinda like how a stereo signal could be run through a spatializer or something like that?

I agree it’d be a good exercise to break up my patch into more standalone blocks like that, although I will probably work on something new before coming back to it.

Also, thanks for the info about the MIDI handling, my decision to handle them explicitly was based on seeing that in the Harmonic Lich code, but I guess in that case the overtones array isn’t registered directly as parameters.

Brilliant! I’m really loving the sounds coming out of this, and it looks fantastic too.

Regarding the OWL parameters / MIDI CCs: handling them explicitly in Harmonic Lich was a workaround because of a firmware flaw, which meant that CC messages from the USB Host interface were not processed in the same way as the ones from USB Device. Long story short, the next firmware release fixes this but because it’s not final yet it makes sense to keep the workaround, for now.

I think I’m gonna go squiggle some knots now, yay!

1 Like

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

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.

Patch of the day indeed!!! :smiley:

1 Like

Y’all are too kind, thank you!

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!

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?

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.

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

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

@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?

@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.

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.

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.

@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.