You're close now, I think if you also remove pdlink.c, it should compile

@rg.kies Seems like the Opus library (used by pdlink~) is failing to compile. It did compile for me on aarch64, but I guess the Rpi has a more reduced instruction set? I'll try to reproduce this on my own Rpi!

For now, if you go into CMakeLists.txt, and outcomment (put # in front of every line) this:

add_subdirectory(Source/Shared/link)

...

target_link_libraries(pdlink PUBLIC link)
target_link_libraries(pdlink_tilde PUBLIC link opus)
target_include_directories(pdlink_tilde PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/Source/Shared/libsamplerate ${CMAKE_CURRENT_SOURCE_DIR}/Source/Shared/opus)

That will enable you to compile without the pd.link~ object while I'm working on a fix.

Heh, awesome to hear! It's definitely a bit of a Swiss knife. For my job, I had to encode a lot of MIDI pitch data into audio files (so they could easily be read in sync with other audio), that could have been a lot more painful if not for plugdata!

I originally though this was a VST3/JUCE bug, but it seems that that has been fixed in JUCE now: https://forum.juce.com/t/juce-vst3-sysex-midi-bug/58893/4

So I'll check why this isn't solved in plugdata yet...

Yeah this is happening next version! Ofelia was never an official part of plugdata, but I maintained a version as an external with plugdata support added. However, combining JUCE and OpenFrameworks turned out to be really tricky, so now we've switched to Gem, which was a bit easier to implement.

From my side, it's not like I have a very strong preference for either one, I like both. But Gem turned out to be easier to include without having to resort to all kinds of hacks.

@Ice-Ice Yeah, that's unfortunately expected. In this update we moved the plugdata folder from an OS specific path to the user documents folder. This makes it easier to find, or to explain where it is. I also wanted to have a clean start, because we saw some issues with people using plugdata since the early days, where their settings file had gone through a load of updates, and contained a lot of old trash.

The new add menu only allows drag and drop, no clicking. This has caused confusing for more people, so next version you will also be able to click them.

And nice to hear! I also came from Max, but I wanted to work in a DAW of my own choice

@Ice-Ice Hi! What version of plugdata are you using? For me on plugdata v0.8.0 (macOS), the color and width messages to arrays seem to work.

@eeropic Good to see! I've been missing this too, it's kind of annoying that you lose your clipboard content when you restart Pd. And it's nice that purr/plug/pure-data will soon all do this, makes it easier to share parts of patches on a forum, or copy/paste between pd flavours.

Hi, what OS are you using?

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