Saving and Exposing persistant automation parameters in PD patches

[gllmAR]

From my understanding, currently, in PlugData versions 0.91 and 0.92, automation parameters are stored within the session of the host DAW.

This works well for situations where a user creates a patch for a specific session and sets up automation parameters. As long as the user remains within that session, the exposed parameters are retained and can be shared across different patches opened by the same PlugData instance. Copy-pasting the effect to another track also preserves the instance automation parameters.

However, when starting a new session, creating a new instance of PlugData, and loading a patch, the user has to manually recreate the automation parameters to expose them to the DAW for automation. This limitation complicates the process of sharing patches that behave like standard plugins.

Could there be a way to expose parameters directly inside the patch itself, so they persist across sessions without manual recreation?

It would be ideal if this method of exposing parameters is also compatible with the HEAVY compiler, where the @hv_param string of a [receive] object is parsed and converted into a plugin parameter during compilation.

for example

r threshold @hv_param 0 100 60

This would become the threshold parameter in the compiled object.

reference https://github.com/Wasted-Audio/hvcc/blob/develop/docs/02.getting_started.md

This improvement would greatly streamline the process of sharing patches, especially in a class environment.

[dromer]

send and receive objects only catch the first label assigned to them. So these automation parameters work fine together with the @hv_param receivers.

You just need to use the name threshold and it will connect to this receiver.

What would be cool is if you could load up such a patch in compiled mode and then it would create these automation controls for you by looking at all the @hv_param objects.

For this to work generally with all kinds of patches we really need a kind of project/session storage that can associate with a certain patch and will remember these program-side controls. This is not trivial at all and I think it's a feature that is probably best worked out after the v1.0 release.

[timothyschoen]

Could there be a way to expose parameters directly inside the patch itself, so they persist across sessions without manual recreation?

You can send a "create" message to the [param] object to activate the parameter. So you can just do this to always create the parameter on patch load:

[jamshark70]

However, when starting a new session, creating a new instance of PlugData, and loading a patch, the user has to manually recreate the automation parameters to expose them to the DAW for automation. This limitation complicates the process of sharing patches that behave like standard plugins.

There's also hamburger menu --> Workspace --> export (to save a patch + params) and import (to load). Doesn't answer the hvcc question but the save/load feature you're looking for has already been implemented.

[dromer]

You can send a "create" message to the [param] object to activate the parameter. So you can just do this to always create the parameter on patch load:

Neither [initmess] or [param] are compatible with compiled mode, though ;)

[gllmAR]

Thanks for these responses,

It seems like the following could solve my workflow (Thanks @timothyschoen for the tip)

@dromer

What would be cool is if you could load up such a patch in compiled mode and then it would create these automation controls for you by looking at all the @hv_param objects.

I completely agree. A unified way to declare parameters, including their range and initial value, that can be picked up by the DAW (for using PlugData inside a DAW) that is compatible with Heavy would be ideal.

Neither [initmess] or [param] are compatible with compiled mode, though ;)

Indeed, [param] is not compatible (yet) with compiled mode.

Perhaps revising the [params] abstraction to replace incompatible objects ([loadmess], [list prepend], [router], and [gate]) could make it usable in both workflows: prototyping effects in PlugData within a DAW and using a compiled patch post Heavy compilation.

@jamshark70, thanks for pointing out the existence of the Workspace (workspace.pdproj). However, this seems to fall outside the scope of declaring parameters inside a patch while maintaining compatibility with vanilla Pure Data workflow.