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

@oid Cool, I'll see if I can work that in and see if that helps with the latch.

Theoretically greater/smaller should indeed work better, so will try soon!

@bocanegra said:

Besides float, bool and trig, are there any other assignable types for DPF parameters? (is a drop down list selection possible?)

I have implemented enumerated parameters via the metadata json in the latest release (v0.9.0)
Here is an example plugin that uses it: https://github.com/Wasted-Audio/wstd-dlay/blob/main/wstd_dlay.json#L16

This results in a 0 to n-1 integer being output by the selector, but on the plugin/host side you can get a dropdown with the configured strings instead.

@ytt Midi is available in the integration with plugdata.

Try the latest nightly builds to test the upcoming 0.8.0 release!

@oid Nice, this inspired me to try and scale this up to many additional "layers" of parameters (8 right now).

The latching feature is really something I wanted to implement soon as well, so this came in quite handy.

I'm also using Daisy btw. testing on the Field. What I'm currently doing is scaling the 0-1 float to 512 integers instead. Larger might be possible, but I found that it's harder to hit the latching value as precision of the received value goes down and you may over-shoot.

Other than that this setup works reasonably well. I've tweaked it a little bit so that each latching parameter can be represented with a single abstraction taking an id to initialize.

@ddw_music Yup, exactly!

So they still use Macs, but pirate all the software for it? Kind of odd.

But yeah the "max4live except everywhere" is the narrative that I've been telling people as well.
The advantage over RNBO is that we don't need to use some online compiler either. The toolchain we use with Plugdata is all integrated!

So you can build a VST or program a microcontroller straight from the DAW

Oh I'm sorry. I am referring to https://github.com/Wasted-Audio/hvcc which we have integrated in PlugData:

https://plugdata.org/images/hvcc.png

From there you can then output a plugin binary of your patch (VST2/VST3/LV2/CLAP).

@ddw_music Have you tried the DPF plugin export using Heavy inside of PlugData yet?

I've implemented DAW synchronization using midi messages start/continue/stop/reset and 24 ppqn clockticks (that should get scheduled quite precisely).

However in current development is a simple [r _hv_dpf_bpm] receiver for the current BPM value, that I am now using for synchronized delay effects.

Any ideas to improve DAW integration here are appreciated

You should probably take a look at https://github.com/timothyschoen/PlugData/
which is a distro of Pd that can run as a plugin inside the DAW (and comes with a unique editor/interface).

@bocanegra said:

Since the [block~] and [switch~] objects are unsupported, how can i know what block size the vst will use? Will it just default to whatever the daw running it is using?

Yes, the process() function is handled by the DPF wrapper and eventually the host-thread that the plugin is running in.

(is it possible to do one sample feedback delays?)

I don't know, this may depend on the host. Afaik the heavy engine can run at single sample blocks, but in general I don't believe DAWs run their plugins like this.

Besides float, bool and trig, are there any other assignable types for DPF parameters? (is a drop down list selection possible?)

Specifically the case of drop-down lists is something that I want as well! I tried playing with this using an "enumerator" type (there is a branch that does this), but it's a bit of a dirty fix for it. Ideally we come up with a specific method for these kind off messages. It certainly is possible to add this both to the heavy messaging system and to the DPF wrapper.

I can't seem to make lv2 ports work. I am copying the created <pluginname>.lv2 folder to my local .lv2 folder but the plugins dont register...?

You may need to run make twice in order for the ttl to be properly generated. I think atm you also still have to copy over the ttl into the lv2 directory. Small "quality of life"-improvements to be made there.

Other than that, great work! I love it!

Thnx for testing! Latest releases have a bunch of midi improvements and Electro-Smith is working on a more proper integration with their platform that will be coming soon!

In the mean time please direct all issues and questions regarding the project over to Github or the Discord and IRC chats please, I don't frequent these forums very much and it's better to centralize some of the communication around the project.

Would love to hear more feedback on functionality and tests of the various generator targets!
Am now looking at VCV Rack exporting and some people are working on additional embedded targets based on ESP32 hardware.

Lots of things to come!

What is not supported or updated? libpd is actively developed and seems to have parity with pd-vanilla 0.51 which most certainly includes [expr] objects already.

You shouln't need to download a dll to make this work. Have you tried by simply using an [expr] object in your patch running on libpd?