28 Oct
2018
28 Oct
'18
7:29 a.m.
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.
29 Oct
29 Oct
6:40 a.m.
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(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
7:52 a.m.
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(a)lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
4:34 p.m.
On 10/29/2018 06:52 AM, Tim wrote:
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.
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. 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 note: Why stop at scanning? There could be a standalone
host with a protocol that interacts with the DAW (at the expense of a
context switch): Much like Bitwig does for sandboxing plugins.
It could be a stripped down jack-application with an additional
state/control API.
2c,
robin
[1] http://xmlns.com/foaf/spec/
[2] https://en.wikipedia.org/wiki/DOAP
[3] http://usefulinc.com/ns/doap#
7:07 p.m.
On 10/29/2018 10:34 AM, Robin Gareus wrote:
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.
Absolutely. I mentioned this in our forum. This thing could grow
from just a scanner to an actual run-time sandbox, since I now have
the framework for running in an external process.
Of top concern is how to share data such as audio in/out buffers.
For inspiration I might look at the old FST or DSSI-VST or
even Jack itself about how to share data between processes.
MusE has some very fine MPSC ring-buffer and multi-threaded
memory C++ templates and so on. Hoping to leverage them.
Thanks for the help!
Tim.
On 10/29/2018 06:52 AM, Tim wrote:
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.
Yes, that's what I was thinking.
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. 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?
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.
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.
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 note: Why stop at scanning? There could be a standalone
host with a protocol that interacts with the DAW (at the expense of a
context switch): Much like Bitwig does for sandboxing plugins.
It could be a stripped down jack-application with an additional
state/control API.
2c,
robin
[1] http://xmlns.com/foaf/spec/
[2] https://en.wikipedia.org/wiki/DOAP
[3] http://usefulinc.com/ns/doap#
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
30 Oct
30 Oct
7:09 a.m.
Am 29.10.18 um 15:34 schrieb Robin Gareus:
I know, but it happens. So it's better to be prepared for this case.
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.
10:02 p.m.
On 10/30/2018 01:09 AM, Hermann Meyer wrote:
Am 29.10.18 um 15:34 schrieb Robin Gareus:
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.
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.
10:11 p.m.
On Tue, 30 Oct 2018 16:02:36 -0400
Tim <termtech(a)rogers.com> wrote:
<snip>
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.
8:58 a.m.
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.
9:37 a.m.
Am 29.10.18 um 15:34 schrieb Robin Gareus:
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.
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.
10:36 a.m.
Am 30.10.18 um 08:37 schrieb Hermann Meyer:
Am 29.10.18 um 15:34 schrieb Robin Gareus:
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).
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.
11:15 p.m.
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
31 Oct
31 Oct
10:36 p.m.
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:
----------------------------------
[ ... ]
<ladspa:UtilityPlugin rdf:about="&ladspa;2029">
<dc:title>Quantiser (100 Steps)</dc:title>
<dc:creator>Mike Rawes
<mike_rawes@yahoo.co.uk></dc:creator>
<dc:rights>GNU General Public Licence Version 2 or Later</dc:rights>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2029.1"
ladspa:hasLabel="Range Minimum" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2029.2"
ladspa:hasLabel="Range Maximum" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2029.3"
ladspa:hasLabel="Match Range" />
</ladspa:hasPort>
[ ... ]
----------------------------------
And in swh-plugins.rdf they are also all like that:
----------------------------------
[ ... ]
<ladspa:SpectralPlugin rdf:about="&ladspa;1199">
<dc:creator>Steve Harris
<steve@plugin.org.uk></dc:creator>
<dc:title>Impulse convolver</dc:title>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;1199.1"
ladspa:hasLabel="impulse" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;1199.2"
ladspa:hasLabel="high_lat" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;1199.3"
ladspa:hasLabel="gain" />
</ladspa:hasPort>
[ ... ]
----------------------------------
Meanwhile in tap-plugins.rdf things seem correct:
----------------------------------
[ ... ]
<ladspa:EQPlugin rdf:about="&ladspa;2141">
<dc:creator>Tom Szilagyi</dc:creator>
<dc:title>TAP Equalizer</dc:title>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2141.0"
ladspa:hasLabel="band_1_gain" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2141.1"
ladspa:hasLabel="band_2_gain" />
</ladspa:hasPort>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;2141.2"
ladspa:hasLabel="band_3_gain" />
</ladspa:hasPort>
[ ... ]
----------------------------------
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.
11 p.m.
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:
----------------------------------------
<ladspa:OscillatorPlugin rdf:about="&ladspa;1416">
<dc:creator>Steve Harris
<steve@plugin.org.uk></dc:creator>
<dc:title>Analogue Oscillator</dc:title>
<ladspa:hasPort>
<ladspa:InputControlPort rdf:about="&ladspa;1416.1"
ladspa:hasLabel="wave" />
</ladspa:hasPort>
<ladspa:hasPort>
----------------------------------------
And here is the *mismatched* corresponding swh-scales.rdf entry:
----------------------------------------
<ladspa:InputControlPort rdf:about="&ladspa;1416.0">
<ladspa:hasScale>
<ladspa:Scale>
<ladspa:hasPoint>
<ladspa:Point rdf:value="1" ladspa:hasLabel="sine" />
</ladspa:hasPoint>
<ladspa:hasPoint>
<ladspa:Point rdf:value="2" ladspa:hasLabel="triangle"
/>
</ladspa:hasPoint>
<ladspa:hasPoint>
<ladspa:Point rdf:value="3" ladspa:hasLabel="square"
/>
</ladspa:hasPoint>
<ladspa:hasPoint>
<ladspa:Point rdf:value="4" ladspa:hasLabel="saw" />
</ladspa:hasPoint>
</ladspa:Scale>
</ladspa:hasScale>
</ladspa:InputControlPort>
----------------------------------------
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.
2210
days inactive
2213
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Hermann Meyer -
Ralf Mardorf -
Robin Gareus -
Tim -
Will Godfrey