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

Normally a DAW will save the "state" of a plugin (this is probably that binary blob you noted).

So the problem you see with Qlab is that a saved project does not retain the plugdata state? or was it that simply closing the plugdata window resets its state somehow?

Plugdata defers all it's plugin implementation to JUCE and such state management is likely also done there. Perhaps there are other JUCE plugins that have similar issues with their AU builds in Qlab.

@jameslo said:

I don't see any mentions of QLab on plugdata's github

To be honest I'd never heard of this application before today, not that remarkable that it wouldn't be mentioned anywhere.

It makes more sense if you create a bug report on the plugdata github repository, so that the issue can be tracked, discussed and resolved there.

Have you tried running plugdata in your DAW instead? -> https://plugdata.org/

@bklindgren said:

for some reason my pd runs it ok

You are probably running on Windows? It's filesystems are case insensitive, where other OSes are sensitive to different cases.

@oid said:

Isn't this the standard pd work flow?

It is not for me

What is the idea behind the two [*~ 1] objects in the patch? You realize that these do not do anything?

Have you gone over the Designing Sound patches yet? -> http://aspress.co.uk/sd/

This is a really cool inspiration of small, but very usable DSP patches.

There is a very old bug report about this: https://github.com/plugdata-team/plugdata/issues/1195
Maybe follow up there (and mention your OS and plugdata version, which you omitted here).

In the plugin version this is not really expected to work since a plugin host will very likely filter these kind of messages.
Especially with VST3 where the spec is very restrictive on what MIDI can do.

@bocanegra said:

is it possible to do one sample feedback delays?

Btw the answer to this is that the HV_SIMD_NONE flag does single sample processing that allows for such feedback and filter design.

This does compromise any performance increases for targets that enable SSE/NEON/AVX.

The AVX implementation is still buggy and missing some stuff, anyway. However the ~4x performance increase on NEON is valuable enough to keep this in mind.

Very cool! there's some very intriguing algorithms at play here