You don't need to remove the plugin and add it again. Just change the config in the plugin, and then when you get back to the daw, you should already see the new outputs.
- the plugin can say which parameters are used and which aren't
- the plugin can dynamically add new parameters
- the plugin can expose multiple ports configuration, including repeatable sidechain input which lets the host connect any number of inputs to the plugin, and name those inputs. It is useful for an analyzer.
- The plugin can inform the host that it does not need to process the next block, like when all the voices are off. It will help to save a lot of CPU on big project when you have hundreds of plugin instances idle.
- The interface is very easy to understand and use, anyone can get started from the example synthesizer and host.
You can declare as many output ports as you want. For the sidechain it makes sense to have the repeatable attribute because it let the host decide how many inputs it wants to connect. But for the plugin output, I think that only the plugin can tell the host how many output it wants.
Right now the scenario would be:
- plugin send CLAP_EVENT_NEW_PORTS_CONFIGS to the host
- the host deactivate the plugin
- the host scans the available configurations, the plugin can expose only the new one
- then the host can select the new configuration and activate the plugin
For the UI docking, it comes has an extension for clap. First there is the gui extension, which just has open()/close(), and then comes an other extension: embed (host), embed/win32 (plugin), embed/X11 (plugin), embed/*. So embedding is available only if the plugin support it.
It would be really nice to have the UI done with Qt or Gtk. Yet they're not fit for such plugin UI (because of the global variables and the main loop, ...).
One of my friend (phant0m) is starting to write a UI toolkit which does not rely on global variables, and should be convenient for plugin UI. I think that we can achieve pretty cool UI with a 2D scene graph, with a vector backend like cairo, and some event handling and windowing abstraction. So work is in progress here.
For the process isolation I like a lot the idea, but if I can have bug free plugins, use them in the same process and benefit from a noticeable performance gain, I prefer "in engine" hosting. Also this is the new option of Bitwig: "only as a bit bridge".
Also the one plugin/one process idea is already possible with jack, right?
For the adoption, it is a big challenge. Let's see how it goes ;-)
I hope that I did not forget to answer one of your point.
Hey, yes I've been looking for an other name, but I did not find one. I'm open to suggestion ;-) Also I don't mind too much about the slang term because it is "the clap" and the plugin format is "CLAP". I believe that anything can be turned into a joke anyway :)
If your DAW get this, the burning sensation might spread into the cables, the speakers, the keyboard and even into your genital organ ;-)
Well there is a stat page, as you can see in the link I posted to the Debian tracker and Archlinux tracker. There is no persistant stats logging (nobody needed it yet).
Ensuring that a torrent has at least one seed is not a feature of Hefur, and I don't think that it needs it.