VIDEO TUTOS > Build your Sonic Algorythms with Pd in your LICH

OWL Lich
,
#1

Hi everyone!
For those who are interested in building sonic algorythms with Pd language in the awesome LICH* Module, here there are 3 video tutorials :

  1. The Default layout patch in order to program our algorythms
    Pd TUTORIAL FOR LICH // PART1 LICH TEMPLATE - YouTube

  2. A tiny example as a Sonic Algorythm : ‘Hello Kick’
    Pd TUTORIAL FOR LICH // PART2 Pd EXAMPLE : HELLO KICK - YouTube

  3. Compilation and Firmware Uploading process in rebeltech.org
    Pd TUTORIAL FOR LICH // PART3 COMPILING@RebelTech.org - YouTube

Code & + info >

N·Joy!
X

2 Likes
What does [s valueknobA] (or B, C, D) do? {solved}
Cant compile Pd patch
#2

Excellent, thank you Xavi!

1 Like
#3

Thanks Martin! …Hope will be useful for the community )

#4

Nice, I’m currently maintaining a bit more future proof version of the heavy/hvcc compiler and will try your patches out on my Lich :slight_smile:

1 Like
#5

@dreamer,
I wonder if you’d be interested in hacking HVCC backend on OWL to add support for some features that are not exposed to PD patches yet. Things like reading from flash, parsing WAVs, FFT, display rendering. I’m not using PD and don’t understand all the Heavy/IR internals well, but can give some pointers to C++ API that should be used. So feel free to ping me if the novelty of running patches on your Lich wears off and you’ll feel like it needs some enhancements :wink:

#6

I find it unlikely for that to happen in the short term.

However I’ve been looking at the OWL toolchain and I want to integrate OWL as a generator, because it doesn’t make sense for me that you guys are doing that separately.

I’m also not 100% sold on the separate @owl parameters, why is it done like this exactly?
For DPF I’ve instead extended the @hv_param to allow for specifying parameter types (this way I now have booleans and triggers, and hopefully more, in the DPF builds) and the patches can stay waaaay more general and be used in other generators as well.

Heavy is used for so many different targets and I’d prefer if things don’t diverge or lock into a specific framework :slight_smile:
(btw we support Daisy now as well :wink: )

One of the big wishes is to support [expr] objects, which could also bring in a ton of possible optimizations of the internal objects.
Personally I really want [midirealtimein] so we can do things with midi-clock synchronization and such.

Sometime this year I hope to chat with a number of “stakeholders” so we can draw up a kind of roadmap for the project.
Have invited some more people into the repository and hopefully we can all be good stewards for it!

#7

I can’t really answer that as I wasn’t involved into PD backend development. But I would guess that HVCC on OWL is mostly intended to be a replacement for desktop PD for people porting patches. Thus compatibility with other Heavy targets might not had been a concern initially. It sounds like a good idea to target Heavy specifically now that HVCC is not abandoned, but we’d have to keep compatibility with the old patches in some way. So we could deprecate the old syntax but still supported it or keep a version of legacy Heavy on python2 in production and add a new from your fork.

You should probably announce that on Electro-Smith forum. Their official pd2dsy utility is based on Martin’s fork for OWL, I wonder if they’ll want to switch to your version instead. Btw, it’s a bit ridiculous that there’s 3 ways to run PD patches on Daisy Patch now (if you count an option to run OWL port that I’ve made).

#8

Oh I’m in contact with them already → port to hvcc · Issue #12 · electro-smith/pd2dsy · GitHub