[LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?

Tim termtech at rogers.com
Tue Oct 30 21:02:36 CET 2018

On 10/30/2018 01:09 AM, Hermann Meyer wrote:
> Am 29.10.18 um 15:34 schrieb Robin Gareus:
>>> On 10/29/2018 12:40 AM, Hermann Meyer wrote:
>>>> Downside of cached information is, that it could clash on plugin load
>>>> when the plugin have changed it's ports (updated).
>> If that happens you have a much bigger issue than stale caches.
>> Released plugins should not change ports or behavior in a way that is
>> not backwards compatible. Doing so would break existing sessions using
>> the plugin.
> I know, but it happens. So it's better to be prepared for this case.

I see these rules are specifically addressed in the LV2 specs.

I recall a discussion several years ago when the Caps plugins
  author spoke of changing his existing plugins.

The list went wild with warnings not to do it.

I was puzzled so I piped up and asked:
"What's the problem? Shouldn't a plugin be allowed to grow and
  mature with new features and controls?"
After some time thinking about it I realized it was a big mistake
  and I replied that I was wrong.

Adding, removing, or changing controls is a possible crash inducer.
But beyond that there is something else:
The actual sound of the plugin. When users dig up an old song project
  they expect plugins that were used to a) be available and b) sound
  and operate exactly like they did before, barring minor improvements.
So even if just the mere operation and sound of some controls has
  changed, the project will not sound correct.
This is a crucial thing, the integrity of existing projects.

So we have Caps Amp I, II, III and so on.
But I replied that hey, no worries, it's not so bad.
They're improvements and it's no big deal to work with them.


More information about the Linux-audio-dev mailing list