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