@oid I think you made a small typo, it should say boxes:paint instead of boxes.paint. Also make sure you define 'self.bg' (don't click it, not a link) somewhere.

And yeah, you can put them on different layers too:

function boxes:paint(g)
         g:set_color(table.unpack(self.bg[i][j]))
         g:fill_rect(0, 0, 25, 25)
end

function boxes:paint_layer_2(g)
         g:set_color(table.unpack(self.bg[i][j]))
         g:fill_rect(25, 0, 25, 25)
end

function boxes:in_1_repaint1()
    self:repaint(1) -- repaints layer 1
end

function boxes:in_1_repaint2()
  self:repaint(2) -- repaints layer 2
end

But it'd be more tricky to do that using a single loop. Might still be possible with some lua tricks though

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.

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