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