@bobpell Hi! The way you just described is totally valid, it's probably how most people do it.

Another way to do it, is with plugdata, a Pd VST3/AU/LV2/CLAP plugin that runs in most DAWs. It's based on pd-vanilla and should be compatible with it for 99%, so you could create patches in Pd and then load them into plugdata to record them. Or you can create your whole project inside plugdata as well, if you want.

I'd say the advantage is that the effort to go from Pd to audio is a bit smaller that way. So if you make a recording in Pd but are not satisfied with it yet, it's less of a hassle to re-record it. And you can also use the DAWs automation to change values in Pd, or get tempo information from the DAW.

The disadvantage is that plugdata is still in development, and as such it's not completely stable all the time.

@flextUser Are you on the develop branch already? I would highly recommend that, we've made a lot of progress. I'm not sure if that will solve your problem but it might help.

A quick thing you can try, is deleting plugdata's internal folder located at %APPDATA%/plugdata on Windows.

If you have ever installed a nightly build from the develop branch, and are now compiling an older version from the main branch, you might run into some problems. plugdata's settings are usually forward compatible, but in this stage of development not very backward-compatible.

@flextUser This looks to me like it didn't find python during the cmake step. Were there any errors when running cmake?

Unfortunately you can't, I put some hooks into the Pd source code that plugdata uses to know when GUI objects change.

What you can do, is use the master branch of my Pd fork, this is mostly up-to-date with Pd (it has multichannel), though it's a little bit behind.

@flextUser It should work, I think you need at least Visual Studio (2019 or higher), python and git bash. If you have that, open git bash and run:

git clone --recursive https://github.com/plugdata-team/plugdata.git
cd plugdata
mkdir build && cd build
cmake .. -G"Visual Studio 16 2019" -A x64
cmake --build .

You can also get nightly builds from the website: https://plugdata.org/download.html

@ddw_music

Nice tutorial!

I've just rewritten the automation parameters system, so DAW interaction should be even smoother in the future:

I'm interested in fixing some of the problems you're describing with [playhead], I agree that the outputs are confusing and unhelpful, so it might be worth it to add a new object, with a similar interface to your [playhead-tick] object, maybe call it [beat]? I think I was planning to do that already, but I forgot about it!

I could also replace the regular [playhead] object, though it might be nice to leave it in for backward compatibility, compatibility with Camomile, and because it provides a lot of low-level information in case you need that.

I also want to think about whether we can reduce the rate at which that data comes through, I could implement something to at least filter out the redundant messages. Your tutorial made me realise that I'm sending the playhead data every Pd audio block (64 samples in plugdata) instead of every DAW audio block, which is useless!

Also, faustgen2~ by agraef is still maintained, it works in vanilla, purr-data and plugdata. There is also a native M1 version since yesterday.

https://github.com/agraef/pd-faustgen

Not really an answer to your question, but in PlugData/ELSE there is also [envgen~], which can be combined with the [function] object. I find that to be a lot more intuitive for creating envelopes.

@gentleclockdivider That's not good, what OS are you on, and are you using the plugin or standalone version? I tried it myself with macOS+Standalone, and I couldn't reproduce it there

This is probably related to PlugData's implementation of [else/keyboard], and not to ELSE itself.

@ddw_music Could you share this abstraction? I'd like to include something like this in PlugData, it would make it much easier for beginners to sync with DAW tempo.