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?
This year I've been trying to pick up the project to get it to python3 (and package at pypi.org), some new generators (for vst2/lv2 audio plugins), updated documentation, and some bugfixes submitted by the community.
Currently I've added Distrho Plugin Format (DPF) and Daisy generators, and am looking for better OWL integration (although that will need some transition period on patch compatibility, since they use a separate parameter messaging at the moment).
Check it out here: https://github.com/Wasted-Audio/hvcc
Hopefully we can improve pd-vanilla compatibility and behaviour (we really want [expr] objects that could help a ton with optimizations).
Ok, on the mailing-list this external was mentioned:
I figured out how to build it using flext:
It automatically connects to the leap software and I can get it to spit out data.
Now I'm slowly trying to understand how it works and how the data can be used efficiently. A help-file like mentioned of the 'aka.leapmotion' would be great to have eventually. Maybe with some standard send-objects that can be hooked in to later.
If anyone can try this and play with it maybe we can make a nice help-file with some examples
they claim that a linux sdk will be made available soon.
It's out now and quite stable. They do regular updates and the basic demos are quite usable (can use the Leap in Google Earth now for instance).
there is a max external:
if everyone is happy with the general display, it should be easy to port it to pd
Neat. Would be great to have in Pd!