To Pd dev -
I've uploaded another version, 0.2, to the same old msp.ucsd.edu/tools/purevst .
(I tried to set up a github project but couldn't figure out how to get permission to push my local repo to it. Giving up on that for now.)
The main thing that now needs thinking through is what to do for a standard VST3 interface - there shuold be some way for the patch to put controls on the VST3 surface, perhaps using Steinberg's own GUI-building nonsense in some way so that things look like a normal VST if you don't get around to opening the Pd GUI.
cheers Miller
The main thing that now needs thinking through is what to do for a standard VST3 interface - there shuold be some way for the patch to put controls on the VST3 surface, perhaps using Steinberg's own GUI-building nonsense in some way so that things look like a normal VST if you don't get around to opening the Pd GUI.
I think you can just add a certain number of generic parameters that are bound to a predefined symbol, e.g. pd-vst-param <number> <value>. The question just how many :)
Note that the parameter configuration must be fixed! Specifically, parameters can only be added (or removed) in future plugin versions. See https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentati....
You can, however, change the parameter *names* at runtime, see https://steinbergmedia.github.io/vst3_dev_portal/pages/Technical+Documentati....
You could simply make the parameter names editable in the VST GUI and save them as part of the plugin state. In addition, you could add a Pd message that allows users to rename parameters on the patch level, e.g. pd-set-vst-param-name <number> <name>.
(You can add an option to hide unused parameters in the VST GUI, but they will still show up in the list of automatable parameters and in the generic plugin UI.)
There are quite a few VSTis with hundreds of parameters, so I think you can just add something like 256 parameters and hope that people won't need more :)
If you have more questions about the VST3 SDK itself, you can also contact me off-list.
Christof
cheers Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/RBMZTPH5OWX...
OK... PureVST 0.3 is out... Mostly I got the VST GUI working a bit better and added some important details to the README.
One thing I forgot to stick in the README - if you send Pd a message to load a new VST GUI description file it doesn't take effect until you close and reopen the VST GUI panel.
cheers Miller
On 4/7/25 12:08 AM, Christof Ressi wrote:
The main thing that now needs thinking through is what to do for a standard VST3 interface - there shuold be some way for the patch to put controls on the VST3 surface, perhaps using Steinberg's own GUI-building nonsense in some way so that things look like a normal VST if you don't get around to opening the Pd GUI.
I think you can just add a certain number of generic parameters that are bound to a predefined symbol, e.g. pd-vst-param <number> <value>. The question just how many :)
Note that the parameter configuration must be fixed! Specifically, parameters can only be added (or removed) in future plugin versions. See https://urldefense.com/v3/__https://steinbergmedia.github.io/vst3_dev_portal... .
You can, however, change the parameter *names* at runtime, see https://urldefense.com/v3/__https://steinbergmedia.github.io/vst3_dev_portal... .
You could simply make the parameter names editable in the VST GUI and save them as part of the plugin state. In addition, you could add a Pd message that allows users to rename parameters on the patch level, e.g. pd-set-vst-param-name <number> <name>.
(You can add an option to hide unused parameters in the VST GUI, but they will still show up in the list of automatable parameters and in the generic plugin UI.)
There are quite a few VSTis with hundreds of parameters, so I think you can just add something like 256 parameters and hope that people won't need more :)
If you have more questions about the VST3 SDK itself, you can also contact me off-list.
Christof
cheers Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
Regarding "signing the goddamn thing yourself," I made a makefile for doing this since I can never remember the rather convoluted process:
https://github.com/zkmkarlsruhe/mac-dist-helper
There is also an example pd C external to confirm it does work:
https://github.com/zkmkarlsruhe/mac-dist-helper-examples/tree/main/hellopd
If people built it for themselves to run on their won system, it's sufficient to use the adhoc "-" code signing entity. In any case, the process needed to setup a code signing cert on a dev machine is also in the readme (again, I didn't;t want to have to figure it out each time):
https://github.com/zkmkarlsruhe/mac-dist-helper?tab=readme-ov-file#apple-dev...
On Apr 6, 2025, at 3:35 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
To Pd dev -
I've uploaded another version, 0.2, to the same old msp.ucsd.edu/tools/purevst .
(I tried to set up a github project but couldn't figure out how to get permission to push my local repo to it. Giving up on that for now.)
The main thing that now needs thinking through is what to do for a standard VST3 interface - there shuold be some way for the patch to put controls on the VST3 surface, perhaps using Steinberg's own GUI-building nonsense in some way so that things look like a normal VST if you don't get around to opening the Pd GUI.
cheers Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/RBMZTPH5OWX...
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Nice, tried it in Reaper now and it worked! This is exactly what I was dreaming of, but I see we can't yet just edit and create patches (at least not yet). Still doesn't work in MAX though 😅
You ought to be able to create&edit patches... ust open the Pd GUI, make a patch and save it - or open an existing one and edit it while it runs inside the DAW. If that doesn't workfor you something needs fixing :)
cheers Miller
On 4/7/25 6:39 PM, Alexandre Torres Porres wrote:
Nice, tried it in Reaper now and it worked! This is exactly what I was dreaming of, but I see we can't yet just edit and create patches (at least not yet). Still doesn't work in MAX though 😅
Em seg., 7 de abr. de 2025 às 15:49, Miller Puckette mpuckette@ucsd.edu escreveu:
You ought to be able to create&edit patches... ust open the Pd GUI, make a patch and save it - or open an existing one and edit it while it runs inside the DAW.
Great, that is what I'd hope and expect
If that doesn't workfor you something needs fixing :)
something needs fixing then :)
All I could do was open a file, and not edit it. I tried getting into edit mode via the menu as well, but nothing really changes.
Trying to create a new patch doesn't work. On a more careful test, I realize now that a couple of new patches I tried opening did only show up after I opened an existing patch.
I used Reaper, macOS 15.2
cheers
cheers Miller
On 4/7/25 6:39 PM, Alexandre Torres Porres wrote:
Nice, tried it in Reaper now and it worked! This is exactly what I was dreaming of, but I see we can't yet just edit and create patches (at least not yet). Still doesn't work in MAX though 😅
I had some trouble getting started in Reaper too... it turns out that Reaper doesn't run audio plug-ins unless Reaper's "transport" is running. When the transport is stopped, Pd's GUI doesn't function.
Are you able to open / save patches when the transport is running? If not, there's a problem in there somewhere...
I need to add something to the doc about this, or perhaps even think of a way to keep the Pd scheduler running when audio isn't getting computed...
cheers MIller
On 4/8/25 5:53 AM, Alexandre Torres Porres wrote:
Em seg., 7 de abr. de 2025 às 15:49, Miller Puckette mpuckette@ucsd.edu escreveu:
You ought to be able to create&edit patches... ust open the Pd GUI, make a patch and save it - or open an existing one and edit it while it runs inside the DAW.
Great, that is what I'd hope and expect
If that doesn't workfor you something needs fixing :)
something needs fixing then :)
All I could do was open a file, and not edit it. I tried getting into edit mode via the menu as well, but nothing really changes.
Trying to create a new patch doesn't work. On a more careful test, I realize now that a couple of new patches I tried opening did only show up after I opened an existing patch.
I used Reaper, macOS 15.2
cheers
cheers Miller On 4/7/25 6:39 PM, Alexandre Torres Porres wrote: > Nice, tried it in Reaper now and it worked! This is exactly what I was > dreaming of, but I see we can't yet just edit and create patches (at > least not yet). Still doesn't work in MAX though 😅 >
Maybe there needs to be an option to run a separate loop with a dummy buffer in the case audio dsp is stopped by the host.
On Apr 8, 2025, at 12:26 PM, Miller Puckette via Pd-dev pd-dev@lists.iem.at wrote:
I had some trouble getting started in Reaper too... it turns out that Reaper doesn't run audio plug-ins unless Reaper's "transport" is running. When the transport is stopped, Pd's GUI doesn't function.
Are you able to open / save patches when the transport is running? If not, there's a problem in there somewhere...
I need to add something to the doc about this, or perhaps even think of a way to keep the Pd scheduler running when audio isn't getting computed...
cheers MIller
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Are you able to open / save patches when the transport is running?
yup :) cool
Em ter., 8 de abr. de 2025 às 07:26, Miller Puckette mpuckette@ucsd.edu escreveu:
I had some trouble getting started in Reaper too... it turns out that Reaper doesn't run audio plug-ins unless Reaper's "transport" is running. When the transport is stopped, Pd's GUI doesn't function.
Are you able to open / save patches when the transport is running? If not, there's a problem in there somewhere...
I need to add something to the doc about this, or perhaps even think of a way to keep the Pd scheduler running when audio isn't getting computed...
cheers MIller
On 4/8/25 5:53 AM, Alexandre Torres Porres wrote:
Em seg., 7 de abr. de 2025 às 15:49, Miller Puckette mpuckette@ucsd.edu escreveu:
You ought to be able to create&edit patches... ust open the Pd GUI, make a patch and save it - or open an existing one and edit it while it runs inside the DAW.
Great, that is what I'd hope and expect
If that doesn't workfor you something needs fixing :)
something needs fixing then :)
All I could do was open a file, and not edit it. I tried getting into edit mode via the menu as well, but nothing really changes.
Trying to create a new patch doesn't work. On a more careful test, I realize now that a couple of new patches I tried opening did only show up after I opened an existing patch.
I used Reaper, macOS 15.2
cheers
cheers Miller On 4/7/25 6:39 PM, Alexandre Torres Porres wrote: > Nice, tried it in Reaper now and it worked! This is exactly what I was > dreaming of, but I see we can't yet just edit and create patches (at > least not yet). Still doesn't work in MAX though 😅 >