You will have to create the same behavior using what is available indeed. Also checkout compatible abstractions like https://github.com/Wasted-Audio/heavylib (included in plugdata)

In the strictest sense you can use a "list", but not the [list] object.
A list is simply a message that contains multiple values, like [1 2 3 4(

Similarly you can use a table/graphical array (canvas object), but not the [array] object.

vst1 does not exist, do you mean vst2 or vst3?

To host lv2 plugins there is https://github.com/jnonis/pd-lv2
For hosting vst2/3 plugins there is https://github.com/Spacechild1/vstplugin

And no it is not possible to run desktop audio plugins hosted inside a pd patch on the Daisy.
Please see https://wasted-audio.github.io/hvcc/docs/09.supported_vanilla_objects.html for supported objects in the Heavy Compiler.

@timothyschoen relevant ticket: https://github.com/juce-framework/JUCE/issues/333

The issue is no longer specific to Linux, as JUCE now also supports Jack Audio on macOS and Windows (and with the relatively simple patch I published last year it can be easily ported to older versions of JUCE).

Which camera is it? (there seems to be more than one for Raspi)

Make sure you have the v4l2 drivers for it, otherwise it won't be recognized.

Start building custom plugin GUIs using DearImGui:

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