Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On 10/31/2018 04:36 PM, Tim wrote: > I may have found some serious mistakes in the various .rdf files: > And in swh-plugins.rdf they are also all like that: To illustrate that one, here is swh-plugins.rdf 1416 port #1: Steve Harris st...@plugin.org.uk Analogue Oscillator ladspa:hasLabel="wave" /> And here is the *mismatched* corresponding swh-scales.rdf entry: Also, we have some weird incomplete listings in the rdf files like: Plugin: Bode frequency shifter (CV) Port name: "Mix (-1=down, +1=up)" idx #1 Possible enum values: val="1" label="up" (No corresponding down enum.) Thanks again. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
Ehm... help ? Bug ? I took the time to integrate LRDF library support into the program. We never had lrdf enumerated controls, or lrdf preset support (interesting, I didn't know about those presets). Yeah I know, about 10 years late... I had a bad feeling there were going to be 'mismatches' between what lrdf reports and what the plugin reports. This seems to be happening. I may have found some serious mistakes in the various .rdf files: In blop.rdf all of the listings are like this: -- [ ... ] Quantiser (100 Steps) Mike Rawes mike_ra...@yahoo.co.uk GNU General Public Licence Version 2 or Later ladspa:hasLabel="Range Minimum" /> ladspa:hasLabel="Range Maximum" /> ladspa:hasLabel="Match Range" /> [ ... ] -- And in swh-plugins.rdf they are also all like that: -- [ ... ] Steve Harris st...@plugin.org.uk Impulse convolver ladspa:hasLabel="impulse" /> ladspa:hasLabel="high_lat" /> ladspa:hasLabel="gain" /> [ ... ] -- Meanwhile in tap-plugins.rdf things seem correct: -- [ ... ] Tom Szilagyi TAP Equalizer ladspa:hasLabel="band_1_gain" /> ladspa:hasLabel="band_2_gain" /> ladspa:hasLabel="band_3_gain" /> [ ... ] -- The blop and SWH are not correct and do not jive with what the plugin reports. The result is mismatched enums to ports. Tap plugins however are just fine. What's wrong here? Two different libraries... Did the specs change or was it a mistake? Thanks. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On 10/30/2018 09:36 AM, Hermann Meyer wrote: > > Am 30.10.18 um 08:37 schrieb Hermann Meyer: >> >> >> Am 29.10.18 um 15:34 schrieb Robin Gareus: The plugins already loaded into memory should still hopefully be OK. >>> yep. >>> >>> On Unix systems already loaded .so will be kept in memory. On Windows >>> you cannot write/replace to a file that is currently opened. >>> >>> You can skip and postpone scanning of plugins that are currently in use >>> until the next session load. >>> >> >> During plugin development I check plugins usually (first) in jalv. That's good advise. >> Sometimes I forgot that I've loaded a plug already and update it, >> result is always a crash in jalv. >> >> The same happen in Mixbus4, I've just checked it, out of curiosity. >> Ardour/Mixbus does no do as I suggested (it does not skip loaded plugins). I mentioned it so that others don't make the same mistake. > True, there is no problem when the update didn't happen in-place, means > remove the older bundle and then install the new one ( like most package > mangers does). > In Ardour and jalv's implementation the LV2 world is constructed statically at application start. Changes won't be picked up correctly. It's different for VST Also there may be conflicts by loading the plugin and later open a mismatching GUI (different .so). I usually think of changing or adding/removing plugins to be like adding another [analog] stomp-box effect pedal between a guitar and amp. That involves to re-plug cables. You don't usually do that while playing nor while the amp is turned up. the point is: I don't think it is important that the plugin-scanner must be able to cope with changing plugins. What would be nice though is to support scanning in background with a priority list: When loading a session, first check the plugins that are already in the session. block and wait until they're re-scanned. Then load the session and continue plugin discovery in the background. ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On Tue, 30 Oct 2018 16:02:36 -0400 Tim wrote: >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. This! It simply can't be overstated. One tiny change can completely destroy the sound, and when a musician has put in hours of effort and deep inspiration into a project they will lose all confidence in the system. -- Will J Godfrey http://www.musically.me.uk Say you have a poem and I have a tune. Exchange them and we can both have a poem, a tune, and a song. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
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. Tim. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
Am 30.10.18 um 08:37 schrieb Hermann Meyer: Am 29.10.18 um 15:34 schrieb Robin Gareus: The plugins already loaded into memory should still hopefully be OK. yep. On Unix systems already loaded .so will be kept in memory. On Windows you cannot write/replace to a file that is currently opened. You can skip and postpone scanning of plugins that are currently in use until the next session load. During plugin development I check plugins usually (first) in jalv. Sometimes I forgot that I've loaded a plug already and update it, result is always a crash in jalv. The same happen in Mixbus4, I've just checked it, out of curiosity. True, there is no problem when the update didn't happen in-place, means remove the older bundle and then install the new one ( like most package mangers does). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
Am 29.10.18 um 15:34 schrieb Robin Gareus: The plugins already loaded into memory should still hopefully be OK. yep. On Unix systems already loaded .so will be kept in memory. On Windows you cannot write/replace to a file that is currently opened. You can skip and postpone scanning of plugins that are currently in use until the next session load. During plugin development I check plugins usually (first) in jalv. Sometimes I forgot that I've loaded a plug already and update it, result is always a crash in jalv. The same happen in Mixbus4, I've just checked it, out of curiosity. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On Mon, 29 Oct 2018 15:34:44 +0100, Robin Gareus wrote: >Why? I've never seen someone installing/removing software while >recording or mixing. It also sounds like a bad idea to me. I agree that it is a bad idea, but decided yesterday not to reply to this thread and mention that it is a bad idea, because it could happen. This especially could happen, when using proprietary software, but not being rich, so the approach likely is to purchase software that time, when it's needed for the first time. In the days we used analog audio studios, it could happen that we left the studio, go by car to a music shop or friend, drove back and installed a new effect to the effect rack. There was no need to power off the gear. However, as long as it should be possible to save the state of a session done with computers, it should take less time to download and install new software and to restart the session or even to restart the computers, than to go by car to a music shop or friend and drive back. If possible I already would buy all the needed analog gear and install all the required software already before starting a recording session, but this strategy could suffer from not having the money to pay for everything that perhaps is needed, but not necessarily might be needed. As for free as in beer software the user should install everything that perhaps is needed, even if it shouldn't be necessarily needed, unfortunately not everything is for free as in beer. However, after a while we usually own all we need, so it doesn't happen that often in life. It's similar to a power outage. They already happened several times, but we usually can't remember when one happened the last time, but power outages do happen and it happens that a user needs to install new analog gear or new software during a session. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On 10/29/2018 10:34 AM, Robin Gareus wrote: On 10/29/2018 06:52 AM, Tim wrote: 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. 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. 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. I suggest to prefer a checksum or hash (at least additionally), or use inotify or some existing watch mechanism. Ardour uses stat()'s mtime. There are various issues with this: e.g. zip files do not include timezone, some tar archives include strange timestamps, installers on other platforms do strange things, and some users toy with clocks on occasion. Edge cases like these have lead to countless headaches in the past. 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. yep. On Unix systems already loaded .so will be kept in memory. On Windows you cannot write/replace to a file that is currently opened. You can skip and postpone scanning of plugins that are currently in use until the next session load. Yes, that's what I was thinking. 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. Why? I've never seen someone installing/removing software while recording or mixing. It also sounds like a bad idea to me. There's the inconvenience of having to shut down and restart the program. I've had a couple of requests for that. Would be nice since sometimes users just want to experiment with all the various plugins installing and trying each one out. What happens if you run two instances of the same DAW or two different programs that share the plugin cache? Do all programs watch for changes and use lock-files to prevent concurrent scanning? Hm yeah good point. Should be do-able though. One solution is to ask a user to directly or indirectly initiate a scan. Directly by pressing a button or indirectly by opening a session. These actions are rarely performed concurrently. Also IIUC sometimes plugin ports can be created on-the-fly? Ouch. Do you need to know the ports a-priori? The host needs to load the plugin anyway to insert it. So the only interesting part to cache is * Plugin-Name * Plugin-Author * Factory & User Presets * Category/Tags (if any) * Description (if any) I/O and Control Ports are not usually something that's worth caching, except perhaps for "has MIDI I/O" (to detect Instruments for plugins that don't specify a category). What other information are you interested to cache? Is there a benefit to caching port names, default values, for each plugin? Absolutely right. I went a bit overboard with this, storing much more information than I really needed. Sort of to the point of obsessing over it. And to what end? Once instantiated, we re-gather all that information from the plugin anyway. So a lot of it is useless. I should probably stop where I am and just finish up what I've got. 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. RDF is generic, it can describe pretty much anything. I thought there is already a LADPSA ontology. Also LADSPA uses RDF for presets. TTL is just a RDF serialization. There is also some discussion to allow JSON-LD as alternative to turtle for LV2. LV2's ontology provides for a nice description of the basics, it really uses foaf[1] and doap[2,3] for the basics. This leaves some classification (categories, tags) and a presets-name to ID map. I have no opinion about the de/serialization format. turtle is fine with me, as would be JSON-LD. Both can be efficiently parsed (low CPU, low memory, serial I/O) and satisfy
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
On 10/29/2018 06:52 AM, Tim wrote: > 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. >> 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. > > > 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. I suggest to prefer a checksum or hash (at least additionally), or use inotify or some existing watch mechanism. Ardour uses stat()'s mtime. There are various issues with this: e.g. zip files do not include timezone, some tar archives include strange timestamps, installers on other platforms do strange things, and some users toy with clocks on occasion. Edge cases like these have lead to countless headaches in the past. > 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. yep. On Unix systems already loaded .so will be kept in memory. On Windows you cannot write/replace to a file that is currently opened. You can skip and postpone scanning of plugins that are currently in use until the next session load. > 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. Why? I've never seen someone installing/removing software while recording or mixing. It also sounds like a bad idea to me. What happens if you run two instances of the same DAW or two different programs that share the plugin cache? Do all programs watch for changes and use lock-files to prevent concurrent scanning? One solution is to ask a user to directly or indirectly initiate a scan. Directly by pressing a button or indirectly by opening a session. These actions are rarely performed concurrently. > > Also IIUC sometimes plugin ports can be created on-the-fly? Ouch. > Do you need to know the ports a-priori? The host needs to load the plugin anyway to insert it. So the only interesting part to cache is * Plugin-Name * Plugin-Author * Factory & User Presets * Category/Tags (if any) * Description (if any) I/O and Control Ports are not usually something that's worth caching, except perhaps for "has MIDI I/O" (to detect Instruments for plugins that don't specify a category). What other information are you interested to cache? Is there a benefit to caching port names, default values, for each plugin? > 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. RDF is generic, it can describe pretty much anything. I thought there is already a LADPSA ontology. Also LADSPA uses RDF for presets. TTL is just a RDF serialization. There is also some discussion to allow JSON-LD as alternative to turtle for LV2. LV2's ontology provides for a nice description of the basics, it really uses foaf[1] and doap[2,3] for the basics. This leaves some classification (categories, tags) and a presets-name to ID map. I have no opinion about the de/serialization format. turtle is fine with me, as would be JSON-LD. Both can be efficiently parsed (low CPU, low memory, serial I/O) and satisfy requirements (semantic description, ordered data structure). > Then we could all simply use our same LV2 discovery codes to examine > all plugin types found. I'm not sure if that's very likely, nor practical. While serd/sord are generic to deal with turtle/RDF, liblilv is rather specific for LV2. The mechanism to scan/discover plugins and presets is rather different for each standard. Realistically, these days the only interesting plugin formats are LV2, VST and AudioUnit. VST does not even specify a system-wide install location for discovery. The AU format is abstracted by Apple, you can't directly interact with it but have to use Apple's libs. This leaves LV2. On a related
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
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
Re: [LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
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 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
[LAD] [A plugin scanner:] Cache text file formats: rdf, ttl, custom xml?
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
