[LV2] Dplug wrapper for LV2

[Auburn Sounds]

> Opaque blobs are, IMO, a bad idea, so the state extension encourages
> transparent state so it can be portably saved in whatever way makes the
> most sense for the host, easily investigated by the user, and so on,
> but you *can* save blobs if you really want to.
>


I've argued several times on IRC about the use case where opaque blogs are
useful. Maybe I'm not clear enough, so let me sum up again.

"If the host does state saving, there is no way to have upgrades over the
lifetime of a plug-in.Because the host know much less about the plugin
semantics than the plugin itself. **Some plug-in parse blobs to upgrade
state to a seemingly incompatible plug-in version.**"

I think it's a good idea for the format acceptance, and for backwards
compatibility for a product existence. Such "chunk parsing" I've seen as an
intern in plugin company.



> > 2. I was looking for a way to describe an in-memory entry-point
> > instead of a lv2:binary that is a file. This would allows LV2 to
> > shine as an internal format within an audio application : the TTL
> > would then be generated dynamically in a way that doesn't have to be
> > specified.
> > Lots of companies end up implementing host and clients for plugins
> > within plug-ins ; a simple "audio module" interface end up being
> > exactly the same thing as... a plug-in and as such better follow a
> > plugin specification. Some build this upon VST3.
>
> Interesting idea.  I don't think this has ever come up.  There are two
> separate things here, though: an entry point that isn't from a dynamic
> module, and generating the data somehow.
>

A TTL could be obtained from an unspecified mechanism too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20190330/85d3df5d/attachment.html>