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.
Cheers.
Tim.
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@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
