After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791330 - lv2: boolean values are inverted
lv2: boolean values are inverted
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.3
Other Linux
: Normal major
: 1.12.5
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-07 02:08 UTC by Wellington Wallace
Modified: 2018-01-15 20:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Wellington Wallace 2017-12-07 02:08:54 UTC
I am testing the Bass Enhancer lv2 plugin from Calf and the effect is only applied when the bypass property is true:

gst-launch-1.0 audiotestsrc freq=50 ! calf-sourceforge-net-plugins-BassEnhancer bypass=1 amount=4 ! pulsesink

But according to the plugin docs https://github.com/calf-studio-gear/calf/blob/master/doc/manuals/Bass%20Enhancer.html it should happen the opposite. The other booleans also seem to be inverted. For example the floor-active property only works when set to false.

I am using gstreamer 1.12.3, lilv 0.22.0 and calf 0.90.0
Comment 1 Tim-Philipp Müller 2018-01-15 20:02:36 UTC
Thanks, looks like the boolean property setter had things the wrong way round:

commit 944f347d0024c3fd5a202eaf30cd79842142ea25 (HEAD -> master)
Author: Tim-Philipp Müller <tim@centricular.com>
Date:   Mon Jan 15 20:01:06 2018 +0000

    lv2: fix inverted boolean properties
    
    https://bugzilla.gnome.org/show_bug.cgi?id=791330
Comment 2 Wellington Wallace 2018-01-15 20:21:17 UTC
Thank you for taking a look at this :-)

I have been using lv2 plugins in my application https://github.com/wwmm/pulseeffects with a workaround for the inverted booleans. How should I proceed to support users with versions of gstreamer that do not have the fix once the one that has is released? Is there a way to know at runtime which gstreamer version is being used? As I use Arch Linux I know it won't take long for it to switch to the next GStreamer once it is released. But for most of the other distributions it may take a lot of time. So I am not sure about what would be the proper way to support both systems.
Comment 3 Tim-Philipp Müller 2018-01-15 20:38:18 UTC
You could do something like:

  use_workaround =
      gst_registry_check_feature_version (gst_registry_get (),
              "element-name", 1, 0, 0)
      && !gst_registry_check_feature_version (gst_registry_get (),
              "element-name", 1, 12, 5);

or somesuch.