In what way is this library "designed specifically for Windows 64-bit systems" ?

Also I recommend against committing zip files (and other release binaries) into your repository as it will blow up the repository size when you do updates.
Does Codeberg not support release artifacts?

I don't really understand why you put this on patchstorage.com .. since you are not sharing any patches here.
The zip file contains some screenshots. Seems to me that there are better ways to share those ..

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