Possibility of porting Tom Erbe's Pd convolution patch to Lich?

OWL Lich
,
#1

Hi everyone,

I have a Lich on its way to me right now, and one of the things I was hoping to be able to do with it was get this Pure data convolver running in my rack. I’m an absolute beginner with Pd though, and now that I’ve read a bit more about it and the Lich’s hardware, I’m thinking this patch would likely be too resource hungry for it to run properly.

The patch in question is here on Tom Erbe’s WordPress blog: partitioned convolution in vanilla pure data (.47 and up) | Tom Erbe

Can any of you Pd wizards tell if that would be possible to run on Lich? And, if not, can anyone point me towards any working patches or projects to create one, whether made with Pd or other languages? I’ve found a few mentions of attempts on the forum here, but it doesn’t look like there have been any updates for a few years.

I’m mostly interested in being able to run very short impulses of instrument bodies to use in physical modelling, so even just a few milliseconds of processing time would be sufficient here.

Thanks for any help or info!

1 Like
#2

Not a PD Wizard here (maybe a bit of C++/FAUST Lich if not Genius), but I recall that the [clone] object is not supported. OWL and any microcontroller can’t run vanilla PD, but rather uses mostly compatible compiler called HEAVY that doesn’t need an OS to run. Generally, convolution requires effective FFT code and it can be expected only with C++ on OWL.

Also, convolution is generally not something that you would use for physmodelling with microcontrollers, it’s too expensive to compute. The easiest way to get started with it on OWL would be to learn FAUST that has a huge physicall modelling library.

#3

Hi there smbols! As antisvin said, Lich/OWL doesn’t support all of PD objects. From the patch you show I can see clone and vline are not.This was a great disappointment for me once I started creating with it. If I knew this before hand, I don’t know if I would buy it because I’m bassically a PD/Supercollider person. Now I’m starting to love it for what it is and not for what I would expect it to be and accepting it with it’s limitations. If I’m not mistaken now you can’t also calibrate the inputs, but I think that’s a last firmware thing… look for it in the forum…
Here you can find a list of suported PD objects: List of supported Pure Data objects. | OpenWareLab

Anyway, congrats for the acquisition it is still a very useful and fun module!

#4

Thank you both for the information!

@atk90x, do you happen to know of any resources that could help me find work arounds for objects that aren’t supported in hvcc? For example, a lot of the tutorials I’ve been going through use expr objects to perform relatively simple arithmetic, or define variables using value, and I’m having trouble finding ways to perform those functions in other ways.

#5

Sadly I’m in the same place as you and I don’t have so much expertise to be able to find a workaround on my own… So if you find anything, let me know please! Expr is very missed indeed…

#6

I’ll be sure to share anything.

So far I’m finding pd extremely frustrating and I wish I would have done more research before jumping into this. I did not realize hvcc is so limited, nor how integral some of the unsupported operators are in achieving very basic things. And the C++/Faust side of things is just so far removed from anything I’m familiar with that I don’t even want to attempt them.

I suppose at the end of the day, there are enough interesting patches in the OWL library that I’ll still end up enjoying the Lich even if I can’t manage to build the things I imagined when I ordered it.

#7

While C++ is a challenging language to learn and likely not worth the effort if you only want to make a few OWL patches, FAUST is a different story. It doesn’t force you to deal with low level programming, but rather describe dataflow in your DSP code. Effectively this is the same thing that you do with PD, but you would be using text instead of a visual UI. I would suggest spending some time with this free course to see if it ends up understandable enough for you. Also, its DSP library is huge, so you won’t have to write a new algorithm from scratch very often.

2 Likes
#8

It is possible to “unravel” expr expressions to more basic pd structures, but it can be quite a pain yes. We have been discussing how to port expr and expr~ to hvcc and someone has been working on it the past months: https://github.com/Wasted-Audio/hvcc/issues/21#issuecomment-1259097774

Our docs maintain both a list of supported and unsupported objects (unsupported is likely outdated). We’re also looking at adding a “heavy mode” to PlugData so you can more easily write hvcc-compatible patches. Supported vanilla objects | hvcc (and there is a link to the unsupported ones)

By the way, using heavylib you can circumvent some missing objects like vline, with similar alternatives: https://github.com/Wasted-Audio/heavylib

We hope that expr/expr~ will help to make some more complex expressions easier to code, although with the microcontroller targets we’ll always have some “physical” limitations to how big and complex patches can get.

1 Like
#9

@antisvin Okay, I wasn’t aware that FAUST worked that way. I’ll check out that free course and see if I get along with it at all.

@dreamer Thanks for those resources! Do the objects in the heavy library work like abstractions? And regarding abstractions, will they work on Lich so long as the abstraction file is also saved to the board, along with whatever patch references it? Or do I need to copy the elements of the abstraction into the main patch?

I’ve made a bit of progress over the weekend and finally built my first functioning component in pd. It’s just a version of the tanh~ object built with individual math blocks, but I’m hoping to put it to use in a dual delay patch I want to eventually build. Thanks again for all the help, folks.

#10

Yes, heavylib is a set of heavy compatible abstractions. In Pd you can simply add it to your path so the objects are available.

There is nothing “saved to the board”, everything is transpiled into c/c++ and then compiled into a binary that runs on the board.

With hvcc this is done using the -p flag to add objects to the search path.

ps; heavylib already contains such a tanh~ implementation (or should I say “approximation”) :wink: