Re: [LAD] LV2 Oscilloscope
On Thu, Oct 10, 2013 at 6:29 PM, Aurélien Leblond 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On Thu, 2013-10-10 at 20:37 +0200, Lars Luthman wrote: > 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. --ll signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On 10/10/2013 07:42 PM, Lars Luthman wrote: On Thu, 2013-10-10 at 20:37 +0200, Lars Luthman wrote: 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. 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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On Thu, Oct 10, 2013 at 2:11 PM, Harry van Haaren wrote: > On Thu, Oct 10, 2013 at 6:29 PM, Aurélien Leblond 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. > 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
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. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On Thu, Oct 10, 2013 at 8:07 PM, Paul Davis 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On Sat, 2013-10-12 at 16:36 +0100, Aurélien Leblond wrote: > > 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. > > That's through Instance-Access right? > That's exactly what I want to avoid - this plugin is meant to be used > in Ingen and Ingen doesn't support this. No, not using any extensions at all. Just regular shared memory. But if you are writing it for a specific host, use whatever extensions it supports. For Ingen I suppose atoms would be the best way. --lls signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
On 10/12/2013 04:36 PM, Aurélien Leblond 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 tried that but without success. I'm using the LVTK library to develop this plugin. My approach is to: - use the get_supplied_options() method to access the host supplied options - iterate until I find SampleRate problem is get_supplied_options() returns 0 options when called from the UI. Any advice? Speak to your host developer. In my host LV2 UI code I have this: https://github.com/falkTX/Carla/blob/master/source/bridges/CarlaBridgeUI-LV2.cpp#L124 The sample-rate is passed via options feature to the UI, among other things. btw, option extension uses lv2:sampleRate and not lv2param:sampleRate, my mistake. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2 Oscilloscope
Hello, problem is get_supplied_options() returns 0 options when called from the UI. get_supplied_options() should work fine both in UIs and Plugins. My guess is the host only gives the sampleRate option to the Plugin and not the UI. Which host are you working with? Also, you can compile the UI with a -DLVTK_DEBUG=1, and the console will print the validation status for any features passed in by the host. You could also from the UI send a patch get message and make sure the Plugin knows how to respond appropriately. On Sat, Oct 12, 2013 at 1:16 PM, Filipe Coelho wrote: > On 10/12/2013 04:36 PM, Aurélien Leblond 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 tried that but without success. > I'm using the LVTK library to develop this plugin. My approach is to: > - use the get_supplied_options() method to access the host supplied options > - iterate until I find SampleRate > > problem is get_supplied_options() returns 0 options when called from the UI. > > Any advice? > > Speak to your host developer. > > In my host LV2 UI code I have this: > > https://github.com/falkTX/Carla/blob/master/source/bridges/CarlaBridgeUI-LV2.cpp#L124 > > The sample-rate is passed via options feature to the UI, among other > things. > > > btw, option extension uses lv2:sampleRate and not lv2param:sampleRate, my > mistake. > > > ___ > Linux-audio-dev mailing list > Linux-audio-dev@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev > > ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
