Am 13.08.26 um 02:08 schrieb Fons Adriaensen:
On Wed, Aug 12, 2026 at 05:30:12PM +0200, Hermann Meyer wrote:
Save way to get it is a atom port, let your dsp part know that the GUI is up
and running and ask it for all the states you need, for example, the
SampleRate. Then you didn't relay on any host behave.
Or even just a standard 'float' control port. But then
it will show up in any host generated GUI.
Sure, just use lv2:portProperty pprop:notOnGUI ;
to hide it from the host generated UI.
However, a Atom port will save you much more trouble than that and could
forward a lot more information you may need. As already pointed out, you
could ask the dsp for the complete state, not only the sample rate, when
the GUI re/start.
3. A GUI may want to show an optional second window
(e.g. a frequency response). The only way to get
a meaningful title for such a window seems to be
to go through a lot of X11 magic to get the plugin
window's WM_NAME. Or is there a better way ?
That is far from any way LV2 related. Use a toolkit to manage multiple
windows from your plugin.
This is not about window management. The plugin window's title
should inform the user of e.g. wich track of a DAW the plugin
is in. If the host provides the parent window it can set the
title (and Ardour does this). But the same information is not
available in any other way in case it may be needed. All it
would take is a char* to the instantiate call.
Okay, then I misunderstood that, maybe because that never interested me.
I use my own tittles for my side windows anyway.
There are a far couple of them out there,
...
and when I remember right, you've written once a X11 toolkit yourself?
Indeed, and that is by now more than 25 years old. It was
used originally on Sun / Solaris machines for some custom
software I developed for ESA. It's still used for all my
software that has a GUI, but will be retired soon.
For the LV2 exeriments I'm using a new one which is even
simpler. Total source code ATM less than is 30 kB.
It only provides the basic functions to create windows,
receive events, and some utilities. Nothing else. Standard
widgets (buttons, rotary knobs, faders,... are no longer
separate X11 windows. Each window's contents are just
provided to X11 as a cairo image surface. Also provides
HDPI support. Some of my Jack apps, e.g. zita-eq1, are
already using it, but I'll wait releasing those until
the dust has settled down a bit.
Funny, I moved the other way round. 10 years ago I used single windows
with control areas for my plugins,
this days I prefer full featured widgets.
If sample rate is such basic is debatable,
You can't even correctly compute the FR of a simple
digital filter without knowing the sample rate. If
you don't understand why this is, Google 'frequency
warping'.
When you check the available LV2 plugs you'll soon find out that the
majority of them didn't request the Sample Rate in the UI.
However, I, before I relay on a "may be implemented or not" feature of a
host, use a atom port and solve the issue myself.
important to know the buffer size were others may be more interested in the
current sample position.
In the extreme case a host could just provide *nothing*
at all to the DSP and GUI when creating them, not even
the sample rate or the list of audio ports. Need this
info ? just ask for it !
Indeed extreme, but a lot cleaner than an arbitrary choice
apparently decided upon without much consideration or
experience.
Ciao,
