Start by reading the manual? -> https://github.com/pure-data/deken/tree/main/developer

This is absolutely insane

You don't need the [+ 1] if you do [sel 0 1 2].

Also this [$1 20( is completely unnecessary.

Sidenote is that number-boxes turn into [f ] objects in the Heavy compiler which are like a number storage (that you can store and retrieve values from). If you have a lot of them they will add to the total program memory of your project.

The externals. It's debatable whether or not the patch that loads these externals would also fall under this license. I would say it doesn't, but if you use abstractions that are GPL you could argue that it does.

Definitely take care with license issues when distributing someone elses code. This kind of due diligence is often omitted and can cause issues down the line.

@porres said:

etxernals will use GPL, which won't allow you to sell.

This is not how the GPL works. It allows commercial use so you can definitely sell any such products.
However if you are distributing these products to users they have the right to see the source-code (as per the GPL).

How to use samples in the Heavy compiler

There are some people using gumroad to sell patches.

You would of course need to make sure that you are not including any code/abstractions from someone else, unless that code has a license that allows you to distribute/change/sell/etc.

What kind of information do you mean?
What these audio systems are, or how they are used in PD?

This can be quite a deep rabbit-hole, so maybe define the boundaries of what you need to know.

Creating synced instrument and effect plugins

@ddw_music said:

Hm, here's a thought -- Cardinal synth (VCV Rack fork) should also save patches into plug-in settings, which could get arbitrarily large. Maybe try that in QLab, for differential testing. If they both fail, you would have more ammunition to go back to QLab. If QLab handles a large Cardinal patch but fails on plugdata, that seems more like a plugdata bug.

Cardinal's AU implementation is completely independent of plugdata. Of course testing any other AU is useful to test, but ideally the same plugin framework is used to pinpoint where the issue is (with the framework or with the plugin).