10 Oct
2013
10 Oct
'13
7:29 p.m.
Hi all,
I'm still trying to improve the avw.lv2 plugin set (reminder, the port
of AMS internal modules), and one of the new plugin I would like to
have is a visual oscilloscope - it's very useful when working with
modular synth to see what the Osc/LFO are at.
At the moment i'm using the DSSI ll-scope but although it works very
well for low frequencies, the refresh rate is not that great for very
high frequencies - half the graph is not displayed and if I setting it
in frozen mode doesn't work that great for Osc/LFO that changes shape
with time.
My plan was to use the ll-scope gtk widget, add it to a LV2 plugin and
start from there.
The problem I'm at the moment facing is this:
- ll-scope widget requires the sample rate as a constructor but I
can't find an easy way for an LV2 plugin to pass the sample rate.
- what is the cleanest way to access input port data from the GUI? GUI
and plugin are very well separated in LV2, I can't figure out what's
the proper way to do this.
Thanks in advance for everyone's help :)
Aurélien
10 Oct
10 Oct
8:12 p.m.
On Thu, Oct 10, 2013 at 6:29 PM, Aurélien Leblond <blablack(a)gmail.com>wrote;wrote:
- what is the cleanest way to access input port data
from the GUI?
In short: the DSP part should write an Atom event to notify the GUI.
The long: Ardour3 deletes UI instances when the window is closed: that
means the state of the UI is lost.
When re-opening the UI, it must re-request the state from the DSP part.
Cleanest way:
-On UI init(), write a "requestSamplerate" Atom message to the DSP
-On DSP recieve "requestSamplerate", write Atom message with samplerate int
to UI.
That covers all the use cases, and the UI will auto update upon re-init in
Ardour :)
HTH, -Harry
9:07 p.m.
On Thu, Oct 10, 2013 at 2:11 PM, Harry van Haaren <harryhaaren(a)gmail.com>wrote;wrote:
On Thu, Oct 10, 2013 at 6:29 PM, Aurélien Leblond
<blablack(a)gmail.com>wrote;wrote:
The longer.
There are two identical specifications for external-UI. They each have a
different URI.
If a plugin uses one of them (the original) then Ardour will NOT delete the
UI instance when it is closed.
If a plugin uses the other (the version "forked"/"copied" by falktx)
then
Ardour WILL delete the UI instance when it is closed.
Both specifications state that the UI is defunct and no longer usable after
being closed:
* After this callback is called, UI is defunct. Host must call
* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
* again UI must be reinstantiated.
Just wanted to be clear about this F***ING ABSURD situation.
--p
- what is the cleanest way to access input port
data from the GUI?
In short: the DSP part should write an Atom event to notify the GUI.
The long: Ardour3 deletes UI instances when the window is closed: that
means the state of the UI is lost.
When re-opening the UI, it must re-request the state from the DSP part.
11 Oct
11 Oct
2:28 a.m.
On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
If a plugin uses one of them (the original) then Ardour will NOT delete
the UI instance when it is closed.
If a plugin uses the other (the version "forked"/"copied" by falktx)
then
Ardour WILL delete the UI instance when it is closed.
Both specifications state that the UI is defunct and no longer usable
after being closed:
* After this callback is called, UI is defunct. Host must call
* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
* again UI must be reinstantiated.
Thanks for clearing that up: learning in progress on my behalf.
Cheers, -Harry
4:08 p.m.
New subject: lv2 external UI -- was Re: LV2 Oscilloscope
On 10/11/2013 02:28 AM, Harry van Haaren wrote:
On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis
<paul(a)linuxaudiosystems.com>wrote;wrote:
To clarify this a bit and fill in the details:
*All this is only relevant for external UI.*
1) URI: http://kxstudio.sourceforge.net/ns/lv2ext/external-ui
Ardour3.4 behaves according to spec, see the function documentation
of void (*ui_closed)(LV2UI_Controller controller); in the header file
http://kxstudio.sourceforge.net/ns/lv2ext/lv2_external_ui.h
2) URI: http://lv2plug.in/ns/extensions/ui#external
Ardour 2.X - 3.4 does not follow the spec regarding void (*ui_closed).
It just hides the window and shows it again.
The reason for Ardour doing (2) differently is that it was agreed on by
some developers that for many plugins re-initialization does not make
sense (re-init can be CPU intense). Those devs updated the
implementation but forgot or neglected to update the spec.
AFAIK it's also only Ardour that does not follow the spec. Other LV2
hosts that support lv2plug.in#externalui may implement it as synonym to
kxstudio#external-ui.
Otherwise the kxstudio#external-ui and lv2plugin#externalui are
identical (with just a minor cosmetic difference that kxstudio defines a
separate URI for the Host and plugin-widget).
In any case, external UI's should be avoided if possible, there are very
few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
one.
ciao,
robin
If a plugin uses one of them (the original) then Ardour will NOT delete
the UI instance when it is closed.
If a plugin uses the other (the version "forked"/"copied" by falktx)
then
Ardour WILL delete the UI instance when it is closed.
Both specifications state that the UI is defunct and no longer usable
after being closed:
* After this callback is called, UI is defunct. Host must call
* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
* again UI must be reinstantiated.
Thanks for clearing that up: learning in progress on my behalf.
Cheers, -Harry
4:42 p.m.
New subject: lv2 external UI -- was Re: LV2 Oscilloscope
On 10/11/2013 04:08 PM, Robin Gareus wrote:
On 10/11/2013 02:28 AM, Harry van Haaren wrote:
correction. the official URI is
http://kxstudio.sf.net/ns/lv2ext/external-ui#
On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis
<paul(a)linuxaudiosystems.com>wrote;wrote:
To clarify this a bit and fill in the details:
*All this is only relevant for external UI.*
1) URI: http://kxstudio.sourceforge.net/ns/lv2ext/external-ui
If a plugin uses one of them (the original) then Ardour will NOT delete
the UI instance when it is closed.
If a plugin uses the other (the version "forked"/"copied" by falktx)
then
Ardour WILL delete the UI instance when it is closed.
Both specifications state that the UI is defunct and no longer usable
after being closed:
* After this callback is called, UI is defunct. Host must call
* LV2UI_Descriptor::cleanup(). If host wants to make the UI visible
* again UI must be reinstantiated.
Thanks for clearing that up: learning in progress on my behalf.
Cheers, -Harry
Ardour3.4 behaves according to spec, see the function documentation
of void (*ui_closed)(LV2UI_Controller controller); in the header file
http://kxstudio.sourceforge.net/ns/lv2ext/lv2_external_ui.h
2) URI: http://lv2plug.in/ns/extensions/ui#external
Ardour 2.X - 3.4 does not follow the spec regarding void (*ui_closed).
It just hides the window and shows it again.
The reason for Ardour doing (2) differently is that it was agreed on by
some developers that for many plugins re-initialization does not make
sense (re-init can be CPU intense). Those devs updated the
implementation but forgot or neglected to update the spec.
AFAIK it's also only Ardour that does not follow the spec. Other LV2
hosts that support lv2plug.in#externalui may implement it as synonym to
kxstudio#external-ui.
Otherwise the kxstudio#external-ui and lv2plugin#externalui are
identical (with just a minor cosmetic difference that kxstudio defines a
separate URI for the Host and plugin-widget).
In any case, external UI's should be avoided if possible, there are very
few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
one.
ciao,
robin
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
4:45 p.m.
New subject: lv2 external UI -- was Re: LV2 Oscilloscope
On 10/11/2013 03:08 PM, Robin Gareus wrote:
In any case, external UI's should be avoided if
possible, there are very
few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
one.
I'm sorry, but I have to ask - what is for you a "normal" LV2
UI?
Some might say Gtk2 or Qt4 or X11 on Linux, but things are changing fast
that will not allow this.
Gtk3 UIs will not work on Gtk2 hosts, with the same regarding Qt4 and
Qt5 (and vice-versa).
Then don't forget we're moving to Wayland and/or Mir...
Current Qt5 release (as of 5.2) doesn't provide a way to embed widgets
afaik, like the Qt4's QX11Embed/Container.
In my case (of Carla 2.0), I'm moving away from having *any* toolkit
code in the backend except "native" UIs (Linux being X11 for now).
This means UIs that use some toolkit (Gtk2/3, Qt4/5, FLTK, etc) and need
instance-access will not work.
5:01 p.m.
New subject: lv2 external UI -- was Re: LV2 Oscilloscope
On Fri, Oct 11, 2013 at 10:45 AM, Filipe Coelho <falktx(a)gmail.com> wrote:
On 10/11/2013 03:08 PM, Robin Gareus wrote:
In any case, external UI's should be avoided if possible, there are very
few valid use-cases. Just use a 'normal' LV2 UI or let the host generate
one.
I'm sorry, but I have to ask - what is for you a "normal" LV2 UI?
Some might say Gtk2 or Qt4 or X11 on Linux, but things are changing fast
that will not allow this.
Gtk3 UIs will not work on Gtk2 hosts, with the same regarding Qt4 and Qt5
(and vice-versa).
Then don't forget we're moving to Wayland and/or Mir...
Current Qt5 release (as of 5.2) doesn't provide a way to embed widgets
afaik, like the Qt4's QX11Embed/Container.
In my case (of Carla 2.0), I'm moving away from having *any* toolkit code
in the backend except "native" UIs (Linux being X11 for now).
This means UIs that use some toolkit (Gtk2/3, Qt4/5, FLTK, etc) and need
instance-access will not work.
indeed, the situation is deeply messed up. one conclusion if you care about
platform portability is to use GL, but even there, the different
implentations of GL even just on Linux can cause significant headaches.
PUGL which is a part of drobilla's stack is an attempt to provide a
minimal, fully portable subset of GL that a plugin could use on any
platform, with any video driver.
--p
10 Oct
10 Oct
8:38 p.m.
On Thu, 2013-10-10 at 18:29 +0100, Aurélien Leblond wrote:
My plan was to use the ll-scope gtk widget, add it to
a LV2 plugin and
start from there.
The problem I'm at the moment facing is this:
- ll-scope widget requires the sample rate as a constructor but I
can't find an easy way for an LV2 plugin to pass the sample rate.
- what is the cleanest way to access input port data from the GUI? GUI
and plugin are very well separated in LV2, I can't figure out what's
the proper way to do this.
I would just bypass the LV2 host altogether and use shared memory to get
the audio data to the GUI. This is what the DSSI plugin does. This means
that it will not work if the plugin and the GUI are running on separate
machines, but that seems to be pretty rare.
One problem is that there is no obvious way of finding out which plugin
instance a GUI is controlling in order to know which SHM file to read if
there are multiple instances of the plugin running. In the DSSI GUI this
is solved by sending a configure() message with a unique string, but
there is no corresponding call in LV2 without adding more extensions.
You might be able to do it with an atom input port or, if you prefer
avoiding additional extensions, with a control output port that you
write your unique value to in the plugin.
--ll
9:05 p.m.
On 10/10/2013 07:42 PM, Lars Luthman wrote:
On Thu, 2013-10-10 at 20:37 +0200, Lars Luthman
wrote:
LV2 UIs can get the sample-rate using the options extension.
Hosts will set the appropriate option lv2param:sampleRate which the UI
can get on initialization.
I would just bypass the LV2 host altogether and
use shared memory to get
the audio data to the GUI.
...and use the same mechanism to send the sample rate.
9:28 p.m.
On 10/10/2013 08:37 PM, Lars Luthman wrote:
I would just bypass the LV2 host altogether and use
shared memory to get
the audio data to the GUI. This is what the DSSI plugin does. This means
that it will not work if the plugin and the GUI are running on separate
machines, but that seems to be pretty rare.
These days it not as rare as it used to be.
A scope is just 1D - say 1024 pixels width -> 1K values that need to be
transmitted from the back-end to the UI. No need to use shared memory,
really.
The only reason for using shmem would be transmitting _all_ the raw
audio-data for upsampling in the UI-thread[1]. But even so, 1.5 Mbit/sec
is nothing these days. Besides, up/down-sampling requires a ringbuffer
anyway, and shmem won't buy you anything.
Message-passing (LV2 Atom messages) can go directly into the UI's
ringbuffer (no extra copy) and will allow the UI to run remotely.
2c,
robin
[1] Upsampling can be CPU heavy, but since it's for display only, it
should not cause DSP load -> delegate to UI-thread.
4015
days inactive
4016
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
Aurélien Leblond -
Filipe Coelho -
Harry van Haaren -
Lars Luthman -
Paul Davis -
Robin Gareus