@bklindgren said:

for some reason my pd runs it ok

You are probably running on Windows? It's filesystems are case insensitive, where other OSes are sensitive to different cases.

@oid said:

Isn't this the standard pd work flow?

It is not for me

What is the idea behind the two [*~ 1] objects in the patch? You realize that these do not do anything?

Have you gone over the Designing Sound patches yet? -> http://aspress.co.uk/sd/

This is a really cool inspiration of small, but very usable DSP patches.

There is a very old bug report about this: https://github.com/plugdata-team/plugdata/issues/1195
Maybe follow up there (and mention your OS and plugdata version, which you omitted here).

In the plugin version this is not really expected to work since a plugin host will very likely filter these kind of messages.
Especially with VST3 where the spec is very restrictive on what MIDI can do.

@bocanegra said:

is it possible to do one sample feedback delays?

Btw the answer to this is that the HV_SIMD_NONE flag does single sample processing that allows for such feedback and filter design.

This does compromise any performance increases for targets that enable SSE/NEON/AVX.

The AVX implementation is still buggy and missing some stuff, anyway. However the ~4x performance increase on NEON is valuable enough to keep this in mind.

Very cool! there's some very intriguing algorithms at play here

I've been creating some tutorial videos to help people get started converting their pd patches using plugdata.

Getting Started:

How to target Daisy:

Pitch/CV and tempo sync in a custom synth voice:

I'm still planning different topics like DAW plugins and externals.
Any other ideas for what I can cover?

The easiest is probably to use https://github.com/x42/jack_midi_clock to create MIDI realtime messages based on the jack transport.

@donnerbono I tried this first one using heavylib abstractions and your expr~ line.

Pretty clean and easy to patch. And you should be able to build it for OWL and Daisy and such.