Re: More LV2 questions

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,
>