abique

That was the useful comment of the day :D Seriously, share your failure with the world so we can understand your point.

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.

In a few words CLAP features:

- per sample and ramp automation

- per note automation

- you can play a note at any frequency

- extensible design

- preset browsing

- parameters grouping

- event based

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

Did you try the clap host and the clap plugin? :-)

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

What do you think of that?

Hi valdiorn,

Thanks for your message!

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.

Cheers :)

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.

How is growing D? I played with it 6 years ago, then I totally forgot it.

Note that Hefur has not been designed to replace existing large scale (in the number of torrents) BitTorrent trackers.

It is very useful for small setups and distributions like Archlinux and Debian: http://tracker.archlinux.org:6969/stat http://bttracker.debian.org:6969/stat

The white list of torrent is on the disk: a folder of .torrent files. So when Hefur restarts it scans this folder and recreate the white list.

The peers will recontact the tracker periodically. So the restart is safe.

If you push torrents to the tracker through RPC, then you'll have to push them again on restart.