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

Tim termtech at rogers.com
Mon Oct 29 06:52:31 CET 2018

On 10/29/2018 12:40 AM, Hermann Meyer wrote:
> Hi Tim
> On guitarix we wrap the LADSPA/LV2 plugins to our own internal plugin 
> format and save instructions in json format.
> Downside of cached information is, that it could clash on plugin load 
> when the plugin have changed it's ports (updated).
> So when you save plugin information on your own, you need to check 
> before you at least load the plugin, if the cached information is still 
> valid.
> regards
> hermann

Hi Hermann.

Yes that was of great concern from the start of this effort.

Scenario 1: While the the program is not running, the user
  installs, moves, removes, or upgrades a plugin, then runs
  the program.
I have an idea at program startup to compare the date/time
  of each given plugin path with the one of the cache file.
If different, reload the cache.

Scenario 2: While the the application is running - perhaps already
  for hours into a project - the user decides to install, move, remove,
  or upgrade a plugin. Watch out !
I have an idea to 'watch' all the given plugin paths for changes
  and take appropriate action: Crash ;-)
I don't think the scenario is too drastic though.
The plugins already loaded into memory should still hopefully be OK.
It might not be wise to alter my data or info of an already loaded
  plugin if it is deleted or removed or upgraded, but at the very
  very least I would like to be able to support loading a
  'brand new' plugin if it suddenly appears.

Also IIUC sometimes plugin ports can be created on-the-fly? Ouch.

About my cache format: Since the highest denominator (most advanced)
  in all these plugin types would be LV2, I think it would be really
  cool if the Turtle tools or libraries could report ALL types
  of plugins and generate new ttl files on the fly from found plugins.
Then we could all simply use our same LV2 discovery codes to examine
  all plugin types found.
So in this 'grand' scheme TTL files would not only come with
  installed plugins but also generated on the fly for new
  discovered plugins lacking such information.
Sound crazy?

Hope you saw my guitar instructional video post on LAU a
  few months back.


> Am 28.10.18 um 06:29 schrieb Tim:
>> Hi list, I'm working on version 2 of MusE's safe plugin
>>  scanner which now creates cached text lists of all plugins
>>  found on the system, seven formats: ladspa, dssi, dssi-vst,
>>  LinuxVst, vst, lv2, and our own MESS).
>> Currently each cache file is a custom xml template describing all
>>  the various features of each plugin found, in one common format.
>> For six of the formats listed above it went smoothly but when
>>  I made the LV2 section I kept thinking - I'm re-inventing the wheel.
>> LV2 already uses Turtle text description files, so it was a bit odd
>>  making a converter from/to my xml format to/from lilv ttl scans.
>> Question: Can rdf, or ladspa rdf, or Turtle files be used to
>>  generally specify ANY type of plugin, so that the various
>>  tools and libraries associated with rdf, lrdf, or ttl or lv2
>>  can read them in a common way?
>> This would also allow me to introduce lrdf (or something rdf-based)
>>  into MusE and really take advantage of features like enumerated
>>  value strings and so on.
>> It'd be great if some rdf tool or library function could scan all
>>  my existing ladspa and dssi (and other) plugins for me and present
>>  me with an rdf file so I don't have to do all the work.
>> Even if the file might lack the ability to fill in those ladspa
>>  enumeration value strings when scanning an unidentifiable plugin.
>> Thanks.
>> Tim.
>> _______________________________________________
>> Linux-audio-dev mailing list
>> Linux-audio-dev at lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-dev

More information about the Linux-audio-dev mailing list