Add a display for numerical values

[napcode]

I think all your beautiful plugins could benefit from a "unified" display for numerical values. The knobs and the corresponding scales are fine for most things but sometime I'd love to see the values I actually dialled in. Take the EQ as an example: sometimes you need to tune a very specific fequency but the button scale is just not enough. The numerical display would always display the the numeric value of the last touched knob / parameter and tell the exact frequency the knob is set at.

[zamaudio]

Yes, I think you're right, I haven't worked out a good way of doing this using DPF yet. But I do want to add this feature.

[jrigg]

Yes, please add this when you've had time to work it out. A text entry field would be very useful too. I've been using the LV2 plugins with the jalv.gtk generic interface so far as I need to be able to set precise values.

[zamaudio]

Fixed in e371bc6 !!

[trebmuh]

@zamaudio : I don't have any numerical value on the Zam* here (fresh GIT build from today: https://github.com/zamaudio/zam-plugins/commit/a0a21f08c7b1b5718358a5776151b834483deb57). Is there any extra needed to make them showing up?

[zamaudio]

@trebmuh: Make sure you uninstall your distro versions of zam-plugins and then reinstall from git.

[trebmuh]

@zamaudio: already done, the build had happened in a chroot (debian pbuilder). Any possibility of a leftover configuration file maybe? As well, I see in this commit several mention to DGL. Isn't it something linked to graphic hardware acceleration?

[zamaudio]

In a debian pbuilder? zam-plugins from git is not a debian package... I think you are using some old source from your distro.

[trebmuh]

@zamaudio : no, I meant I made a package myself from the current GIT with pbuilder which is a chrooted env and then doesn't allow for leftover files from a previous package as you suggested 3 messages above.

Edit: does zam-plugins is using any configuration file under the use home directory maybe?

[trebmuh]

I sort of remember that @falkTX tolds me back in the days that displaying numerical values for the DPF port of the mverb is requiring some hardware support. Could that be the same here?

[falkTX]

dpf uis use openGL. the "normal" provided widgets use version 1.0 and 1.1, while text (via nanovg) uses 2.0.

[jrigg]

The numerical display is working fine here on Debian 8 (amd64, radeon). @trebmuh, did you remember to do 'git submodule init' and 'git submodule update' after checking out the git code?

[trebmuh]

@jrigg : I used to do git submodule update --init but I made a new package with the commands you suggested git submodule init and git submodule update.

Since you are running a debian 8 on a amd64, would you mind please to test the package: http://download.tuxfamily.org/librazik/volatile/zam-plugins_3.7+20160815-git5d9e7c6~repack2-0librazik1_amd64.deb and tell me if you can see those numerical values displayed?

Edit: well, I've tested this package on another computer and I can see the numerical values displayed. It sounds to me that I've got one computer which is not "openGL 2.0 ready". Any idea how I can confirm/infirm that?

Computer I can see the numerical values:

Computer I can't:

[jrigg]

You can look in /var/log/Xorg.0.log to see if hardware acceleration is being used by your GPU. Info about OpenGL compatibility can be found using glxinfo (from mesa-utils package in Debian): https://wiki.debian.org/Mesa

[trebmuh]

Thanks for the pointer @jrigg .

If I look at:

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) G33 
OpenGL version string: 2.1 Mesa 10.3.2
OpenGL shading language version string: 1.20

I'm unsure about what is the number expected to match with the 2.0 from @falkTX saying:

while text (via nanovg) uses 2.0.

Am I hardware-side supposed to be right with OpenGL version string: 2.1 (matching the 2.0), or am I out with OpenGL shading language version string: 1.20 (not matching the 2.0)?

Packages "mesa-utils" and "firmware-linux-nonfree" installed here, and:

$ glxinfo  | grep rendering
direct rendering: Yes

Cheers