28 Oct
2013
28 Oct
'13
3 p.m.
> In my lv2 plugin, I need to communicate
information from the DSP to
> the UI, but I don't want to break the DSP/UI separation principle (no
> Instance or Data access). On top of that, I'm using LVTK.
he, he, yeah it can get a little confusing... maybe
this will help.
// you're sending things in an atom sequence so get the size information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head (m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time (0);
// after forging a frame_time, just write a normal float (no blank object needed)
m_forge->write_float (1604);
Your ttl file has atom:Float as the buffer type.
I've never used
anything besides atom:Sequence. I imagine this buffer type doesn't need a
sequence head forged first. Maybe David will jump in on how atom:Float
bufferType'd ports are supposed to forged into and out of.
Ok, so I changed my code the way you proposed (with switching in the
ttl to Sequence), but still don't manage to make it work.
I'm wondering if there isn't something wrong with the way I setup the
Forge in the first place. I'm a bit confused with the way to interact
wiith the map object in LVTK.
Scope::Scope(double rate) : Plugin<Scope, URID<true>,
Options<true>>(p_n_ports)
{
m_forge = new AtomForge(p_map);
}
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
I recommend, if you want to use LVTK to do atom
forging, that you subclass
lvtk::AtomForge and add appropriate methods to it...
Here's a snippet that shows how to write patch get/set messages with a
subclassed AtomForge. It also shows how to write raw midi.
http://pastebin.com/C1LYtXpv -- the code in there uses small uses the
nullptr macro. just change those to "0" if you're not using c++11
Could you tell me the advantages of doing that?
But I had a look at the code, I still need to understand how to work
with LV2_URID_Map in LVTK (I cannot find any examples using it).
28 Oct
28 Oct
3:52 p.m.
On Mon, Oct 28, 2013 at 9:00 AM, Aurélien Leblond <blablack(a)gmail.com>wrote;wrote:
The map object is 'just there' for when you need it, like creating new
forges ;) I've always wondered if it made more sense to provide a
accessor method to it for clarity Plugin::get_urid_map() const or
something like that.
That looks right for creating a forge, AtomForge's ctor will call
lv2_atom_forge_init
when the map is passed in (just like you do above)
1) AtomForge inherits LV2_Atom_Forge directly. This makes it possible to
use this class as if it were a regular c-typed forge.. e.g ...
AtomForge* forge = new AtomForge (this->p_map);
lv2_atom_forge_float (forge, 45.0f);
.... would work. It makes it possible to do custom forging using the
normal LV2 Atom API if wanted
2) By inheriting and adding to it keeps all of your forge'ing related code
organized into one place. Its a nice thing to do if you're not into
writing the same lines of code over and over again.
So I suppose its a personal preference kind of thing. Personally, once I
discover how to write a particular atom type correctly, I like to save it
and not have to figure it all out again.
But I had a look at the code, I still need to understand how to work
> In my lv2
plugin, I need to communicate information from the DSP to
> the UI, but I don't want to break the DSP/UI separation principle (no
> Instance or Data access). On top of that, I'm using LVTK.
he, he, yeah it can get a little confusing...
maybe this will help.
// you're sending things in an atom sequence so get the size
information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head (m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time (0);
// after forging a frame_time, just write a normal float (no blank
object
needed)
m_forge->write_float (1604);
Your ttl file has atom:Float as the buffer
type. I've never used
anything besides atom:Sequence. I imagine this buffer type doesn't need
a
sequence head forged first. Maybe David will
jump in on how atom:Float
bufferType'd ports are supposed to forged into and out of.
Ok, so I changed my code the way you proposed (with switching in the
ttl to Sequence), but still don't manage to make it work.
I'm wondering if there isn't something wrong with the way I setup the
Forge in the first place. I'm a bit confused with the way to interact
wiith the map object in LVTK.
Scope::Scope(double rate) : Plugin<Scope, URID<true>,
Options<true>>(p_n_ports)
{
m_forge = new AtomForge(p_map);
}
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size
information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
Still nothing happening on the GUI end ay? Could I just have a link to the
full source code? I'm better debugging hands on. Sorry, I can't recall
the git address to your plugin set.
Forging atoms (in a way that actually works) isn't by any means a straight
forward process.
I recommend, if you want to use LVTK to do atom
forging, that you
subclass
lvtk::AtomForge and add appropriate methods to
it...
Here's a snippet that shows how to write patch get/set messages with a
subclassed AtomForge. It also shows how to write raw midi.
http://pastebin.com/C1LYtXpv -- the code in there uses small uses the
nullptr macro. just change those to "0" if you're not using c++11
Could you tell me the advantages of doing that?
with LV2_URID_Map in LVTK (I cannot find any examples
using it).
4:24 p.m.
The map object is 'just there' for when you
need it, like creating new
forges ;) I've always wondered if it made more sense to provide a accessor
method to it for clarity Plugin::get_urid_map() const or something like
that.
That looks right for creating a forge, AtomForge's ctor will call
lv2_atom_forge_init
when the map is passed in (just like you do above)
Thanks for checking, I really have the feeling I'm missing something
small here :)
The SVN is here:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avw.lv2
(Ingen is the host I use to test them)
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size
information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
Still nothing happening on the GUI end ay? Could I just have a link to the
full source code? I'm better debugging hands on. Sorry, I can't recall the
git address to your plugin set.
Forging atoms (in a way that actually works) isn't by any means a straight
forward process.
5:58 p.m.
On Mon, Oct 28, 2013 at 10:24 AM, Aurélien Leblond <blablack(a)gmail.com>wrote;wrote:
Yep, missing something small seems to happen to me frequently. I'm jumping
over to my Linux machine and will give it a go.
The map object
is 'just there' for when you need it, like creating new
forges ;) I've always wondered if it made more sense to provide a
accessor
method to it for clarity Plugin::get_urid_map()
const or something
like
that.
That looks right for creating a forge, AtomForge's ctor will call
lv2_atom_forge_init
when the map is passed in (just like you do above)
the
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size
information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
Still nothing happening on the GUI end ay? Could I just have a link to full source code? I'm better debugging hands
on. Sorry, I can't recall
the
git address to your plugin set.
Forging atoms (in a way that actually works) isn't by any means a
straight
forward process.
Thanks for checking, I really have the feeling I'm missing something
small here :)
The SVN is here:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avw.lv2
(Ingen is the host I use to test them)
9:30 p.m.
On Mon, Oct 28, 2013 at 11:58 AM, Michael Fisher <mfisher31(a)gmail.com>wrote;wrote:
On Mon, Oct 28, 2013 at 10:24 AM, Aurélien Leblond
<blablack(a)gmail.com>wrote;wrote:
Yep, missing something small seems to happen to me frequently. I'm
jumping over to my Linux machine and will give it a go.
First things first. Your plugin, after modifying ttl files, works fine in
Jalv. For ingen support, your best bet might be to add a Trac ticket on
drobilla.net.
Ok, so I figured out the problem... the GUI ttl file should look
something like this (with a portNotification setting)
<http://avwlv2.sourceforge.net/plugins/avw/scope/gui>
a guiext:GtkUI ;
guiext:binary <scope_gui.so> ;
guiext:portNotification [
guiext:plugin <http://avwlv2.sourceforge.net/plugins/avw/scope> ;
lv2:symbol "notify" ;
guiext:notifyType atom:Float
] .
the Port definition in the plugin's turtle :
... [
a lv2:OutputPort, atom:AtomPort ;
atom:bufferType atom:Sequence ;
atom:supports atom:Float ; # <<<<<< NEED THIS (i
think)
lv2:index 1 ;
lv2:symbol "notify" ;
lv2:name "Notify" ;
] .
I also added more debug output to the GUI... all relevant changes
were committed in a git mirror on Github (its just easier for me to do
that) The only files I modified were scope*.* files
You'll want to look at the GUI code, because I also show you how to
'un-package' the atom in the port_event method.
https://github.com/axetota/avwlv2/tree/devel
The map
object is 'just there' for when you need it, like creating new
forges ;) I've always wondered if it made more sense to provide a
accessor
method to it for clarity Plugin::get_urid_map()
const or something
like
that.
That looks right for creating a forge, AtomForge's ctor will call
lv2_atom_forge_init
when the map is passed in (just like you do above)
the
void Scope::run(uint32_t nframes)
{
// you're sending things in an atom sequence so get the size
information
// from the port buffer
LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
m_forge->sequence_head(m_notify_frame, 0);
// sequences need a timestamp for each event added
m_forge->frame_time(0);
m_forge->write_float(1604);
}
Still nothing happening on the GUI end ay? Could I just have a link to full source code? I'm better debugging hands
on. Sorry, I can't
recall the
git address to your plugin set.
Forging atoms (in a way that actually works) isn't by any means a
straight
forward process.
Thanks for checking, I really have the feeling I'm missing something
small here :)
The SVN is here:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avw.lv2
(Ingen is the host I use to test them)
4 Nov
4 Nov
1:52 p.m.
Hi Michael,
So I have made some progress in my quest to create a LV2 Visual Oscilloscope.
My aim now is to move not a unique float, but a vector of floats (or
audio sample) from the DSP the the UI:
The design I have in mind is as follows:
- During each run() in the DSP side, an array of float is created a
filled with the data from the Audio Input
- At the end of the run(), the vector is writtn into the notify atom port
- This array is caught on the UI side and used to feed the
Osciolloscope GTK widget
What I think I should be doing is using Blank Atom to transfer the
data from DSP to UI, right?
- guiext:notifyType atom:Blank ;
- atom:supports atom:Audio ;
- on the DSP side, use the AtomForge write_raw method to write the
array of floats
Is that the right way to go or is there anything else I should consider?
As the the lv2 scope plugin has 2 inputs that need to be represented
in the GUI, I was wondering if I can pass the 2 arrays of floats in
one go through only one Atom.
From the LV2 documentation, it looks like lv2 is loose
enoigh that i
can pass my own object, but I'm not sure how to approach that via
LVTK
(or via LV2 itself for that matter).
Once again thanks in advance for your help,
Aurélien
On Mon, Oct 28, 2013 at 8:30 PM, Michael Fisher <mfisher31(a)gmail.com> wrote:
On Mon, Oct 28, 2013 at 11:58 AM, Michael Fisher
<mfisher31(a)gmail.com>
wrote:
On Mon, Oct 28, 2013 at 10:24 AM, Aurélien Leblond <blablack(a)gmail.com>
wrote:
Yep, missing something small seems to happen to me frequently. I'm
jumping over to my Linux machine and will give it a go.
First things first. Your plugin, after modifying ttl files, works fine in
Jalv. For ingen support, your best bet might be to add a Trac ticket on
drobilla.net.
Ok, so I figured out the problem... the GUI ttl file should look something
like this (with a portNotification setting)
<http://avwlv2.sourceforge.net/plugins/avw/scope/gui>
a guiext:GtkUI ;
guiext:binary <scope_gui.so> ;
guiext:portNotification [
guiext:plugin <http://avwlv2.sourceforge.net/plugins/avw/scope>
;
lv2:symbol "notify" ;
guiext:notifyType atom:Float
] .
the Port definition in the plugin's turtle :
... [
a lv2:OutputPort, atom:AtomPort ;
atom:bufferType atom:Sequence ;
atom:supports atom:Float ; # <<<<<< NEED THIS (i
think)
lv2:index 1 ;
lv2:symbol "notify" ;
lv2:name "Notify" ;
] .
I also added more debug output to the GUI... all relevant changes were
committed in a git mirror on Github (its just easier for me to do that) The
only files I modified were scope*.* files
You'll want to look at the GUI code, because I also show you how to
'un-package' the atom in the port_event method.
https://github.com/axetota/avwlv2/tree/devel
The map object is 'just there' for when
you need it, like creating new
forges ;) I've always wondered if it made more sense to provide a
accessor
method to it for clarity Plugin::get_urid_map() const or something
like
that.
That looks right for creating a forge, AtomForge's ctor will call
lv2_atom_forge_init
when the map is passed in (just like you do above)
>
> void Scope::run(uint32_t nframes)
> {
> // you're sending things in an atom sequence so get the size
> information
> // from the port buffer
>
> LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
> m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
>
> m_forge->sequence_head(m_notify_frame, 0);
>
> // sequences need a timestamp for each event added
> m_forge->frame_time(0);
>
> m_forge->write_float(1604);
> }
>
Still nothing happening on the GUI end ay? Could I just have a link to
the
full source code? I'm better debugging hands on. Sorry, I can't
recall the
git address to your plugin set.
Forging atoms (in a way that actually works) isn't by any means a
straight
forward process.
Thanks for checking, I really have the feeling I'm missing something
small here :)
The SVN is here:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avw.lv2
(Ingen is the host I use to test them)
5 Nov
5 Nov
6:48 a.m.
On Mon, Nov 4, 2013 at 6:52 AM, Aurélien Leblond <blablack(a)gmail.com> wrote:
Hi Michael,
What I think I should be doing is using Blank Atom to transfer the
data from DSP to UI, right?
It sounds logical to me, yeah. Doing it this way could be done by forging
the Blank atom and then writing the float array as raw. You would need to
map a few uris specifically for this to use inside of the blank object.
seems like peak proptocol etc etc.. would could also be used here. I don't
think there's a single host that supports any of those kinds of features
though....
some fake code doing it with an atom object and a raw buffer, I didn't try
to compile any of this let alone try it in a real plugin.
float buffer [bufsize];
uint32_t object_type = this->map ("http://myuri#object");
uint32_t prop_type = this->map ("http://myuri#prop");
...
ForgeFrame frame;
AtomObject obj (forge.write_blank (frame, 0, object_type));
forge.property_head (prop_type, 0);
forge.write_raw (buffer, sizeof (float) * bufsize);
forge.pop (frame);
and then on the GUI side use an AtomObject::iterator if you want it to look
more like c++.
AtomObject obj (data_from_port_event);
AtomObject::iterator prop = obj.begin();
float* buffer = 0;
while (prop != obj.end())
{
if (prop->key == prop_type) {
buffer = LV2_ATOM_BODY (&prop->value);
break;
}
++prop;
}
if (buffer)
do_something_with (buffer);
regular object getting and querying obviously would also work on the GUI
end.
- guiext:notifyType atom:Blank ;
- atom:supports atom:Audio ;
- on the DSP side, use the AtomForge write_raw method to write the
array of floats
Is that the right way to go or is there anything else I should consider?
As the the lv2 scope plugin has 2 inputs that need to be represented
in the GUI, I was wondering if I can pass the 2 arrays of floats in
one go through only one Atom.
From the LV2 documentation, it looks like lv2 is loose enoigh that i
can pass my own object, but I'm not sure how to approach that via LVTK
(or via LV2 itself for that matter).
Once again thanks in advance for your help,
Aurélien
On Mon, Oct 28, 2013 at 8:30 PM, Michael Fisher <mfisher31(a)gmail.com>
wrote:
First things first. Your plugin, after modifying ttl files, works fine in
On Mon, Oct 28, 2013 at 11:58 AM, Michael Fisher
<mfisher31(a)gmail.com>
wrote:
>
> On Mon, Oct 28, 2013 at 10:24 AM, Aurélien Leblond <blablack(a)gmail.com>
> wrote:
>>
>> > The map object is 'just there' for when you need it, like creating
new
>> > forges ;) I've always wondered
if it made more sense to provide a
>> > accessor
>> > method to it for clarity Plugin::get_urid_map() const or
something
>> > like
>> > that.
>> >
>> > That looks right for creating a forge, AtomForge's ctor will call
>> > lv2_atom_forge_init
>> > when the map is passed in (just like you do above)
>> >
>> >>
>> >> void Scope::run(uint32_t nframes)
>> >> {
>> >> // you're sending things in an atom sequence so get the size
>> >> information
>> >> // from the port buffer
>> >>
>> >> LV2_Atom_Sequence* aseq = (LV2_Atom_Sequence*) p (p_notify);
>> >> m_forge->set_buffer ((uint8_t*) aseq, aseq->atom.size);
>> >>
>> >> m_forge->sequence_head(m_notify_frame, 0);
>> >>
>> >> // sequences need a timestamp for each event added
>> >> m_forge->frame_time(0);
>> >>
>> >> m_forge->write_float(1604);
>> >> }
>> >>
>> >
>> > Still nothing happening on the GUI end ay? Could I just have a link
to
> the
> full source code? I'm better debugging hands on. Sorry, I can't
> recall the
> git address to your plugin set.
>
> Forging atoms (in a way that actually works) isn't by any means a
> straight
> forward process.
Thanks for checking, I really have the feeling I'm missing something
small here :)
Yep, missing something small seems to happen to me frequently. I'm
jumping over to my Linux machine and will give it a go.
The SVN is here:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avw.lv2
(Ingen is the host I use to test them)
Jalv. For ingen support, your best bet might be
to add a Trac ticket on
drobilla.net.
Ok, so I figured out the problem... the GUI ttl file should look
something
like this (with a portNotification setting)
<http://avwlv2.sourceforge.net/plugins/avw/scope/gui>
a guiext:GtkUI ;
guiext:binary <scope_gui.so> ;
guiext:portNotification [
guiext:plugin <
http://avwlv2.sourceforge.net/plugins/avw/scope>
;
lv2:symbol "notify" ;
guiext:notifyType atom:Float
] .
the Port definition in the plugin's turtle :
... [
a lv2:OutputPort, atom:AtomPort ;
atom:bufferType atom:Sequence ;
atom:supports atom:Float ; # <<<<<< NEED THIS (i
think)
lv2:index 1 ;
lv2:symbol "notify" ;
lv2:name "Notify" ;
] .
I also added more debug output to the GUI... all relevant changes were
committed in a git mirror on Github (its just easier for me to do that)
The
only files I modified were scope*.* files
You'll want to look at the GUI code, because I also show you how to
'un-package' the atom in the port_event method.
https://github.com/axetota/avwlv2/tree/devel
6 Nov
6 Nov
4:33 a.m.
Hi guys,
On 11/05/2013 06:48 AM, Michael Fisher wrote:
[..]
ForgeFrame frame;
AtomObject obj (forge.write_blank (frame, 0, object_type));
forge.property_head (prop_type, 0);
forge.write_raw (buffer, sizeof (float) * bufsize);
[..]
That works all right, but it's not proper LV2 Atom/RDF.
- the receiver has no idea about the length
- if the host-buffer overflows there's no way to re-sync
- it cannot be interleaved with other DSP -> UI messages
- `jalv.gtk -d ...` cannot parse it as RDF
- ...
LV2_Atom_Vector is made for exactly that purpose.
from sratom/tests/sratom_test.c:
lv2_atom_forge_property_head(&forge, eg_vector, 0);
int32_t elems[] = { 1, 2, 3, 4 };
lv2_atom_forge_vector(&forge, 4, forge.Int, sizeof(int32_t), elems);
<OT> @Drobilla:
I think the last line is slightly wrong, it should be
lv2_atom_forge_vector(&forge, sizeof(int32_t), forge.Int, 4, elems);
as per ns/ext/atom/forge.h
lv2_atom_forge_vector(LV2_Atom_Forge* forge,
uint32_t child_size,
uint32_t child_type,
uint32_t n_elems,
const void* elems)
not that it really matters because only (child_size * n_elems) is used.
</OT>
Either way, you'll likely need
http://lv2plug.in/ns/ext/resize-port/#minimumSize as well if you're
going to pass large chunks of data around.
-=-=-
<rant mode on>
Anyway even if you make it work, I doubt that you'll have much fun:
Atom messages are written into a ringbuffer in the LV2host in the
DSP-thread. This ringbuffer is sent to the UI by another thread
(jalv.gtk and ardour use a g_timeout() usually at 40ms ~ 25fps), and
finally things are drawn in the X11 thread ie. gtk-main or qt's main.
Other LV2 hosts may do do things differently and you have no control
over it.
As much as like LV2 from a user's perspective and host integration. It
kinds sucks for visualizations. The only realistic way do to RT
*visualizations* (e.g. a scope) right is to bypass the host (use
instance access & a semaphore) and use openGL with vblank-sync using a
custom thread in the UI (drobilla is going to blacklist me now).
Synchronizing even one [audio] thread with the gfx-hardware is not
trivial. Default LV2 communication involves two or more, including some
threads that the LV2-host controls. -- It may be fun for someone to sort
this all out, but not me.
That being said I do like LV2 Atoms, event-queues, mapped URIs, and more
generally the CY-y way of LV2, though. It's very nice, robust and
elegant for control. Sometimes a tad overkill, but heck, therefore it's
portable, too.
However, if you want to write a proper scope, make it a jack application
- or wait for Fons to release zita-scope.
<rant mode off>
-=-=-
I did some tests a while ago, passing raw audio data inside an
LV2_Atom_Vector to the UI. I've just added an over-simplified scope UI
so that you see for yourself. unzip,
make
sudo make install PREFIX=/usr
jalv.gtk http://gareus.org/oss/lv2/audiopipe
# curse loudly
sudo make uninstall PREFIX=/usr
Cheers!
robin
5:41 a.m.
On Wed, 2013-11-06 at 04:33 +0100, Robin Gareus wrote:
Hi guys,
On 11/05/2013 06:48 AM, Michael Fisher wrote:
[..]
Indeed. Don't Do That(TM). Using non-standard types is not so good,
but can be valid. This, however, is not valid. The property value has
no atom header, so the host might look for the type and/or size the
standard guarantees is there, find some float bytes instead, and boom.
Do not send corrupt atoms around!
raw() is very much a "do not use this unless you really very definitely
know exactly what you are doing" function. Perhaps the docs should say
as much.
Anyway, jalv.gtk -d is a good indicator of sanity, it should print
something human readable. Practical reasons aside (e.g. working in
separated hosts like Ingen), debugging is a heck of a lot nicer when you
can just look at the data flying around. If it crashes, it's probably
because the atoms are corrupt.
ForgeFrame frame;
AtomObject obj (forge.write_blank (frame, 0, object_type));
forge.property_head (prop_type, 0);
forge.write_raw (buffer, sizeof (float) * bufsize);
[..]
That works all right, but it's not proper LV2 Atom/RDF.
- the receiver has no idea about the length
- if the host-buffer overflows there's no way to re-sync
- it cannot be interleaved with other DSP -> UI messages
- `jalv.gtk -d ...` cannot parse it as RDF
- ... Anyway even if you make it work, I doubt that
you'll have much fun:
Atom messages are written into a ringbuffer in the LV2host in the
DSP-thread. This ringbuffer is sent to the UI by another thread
(jalv.gtk and ardour use a g_timeout() usually at 40ms ~ 25fps), and
finally things are drawn in the X11 thread ie. gtk-main or qt's main.
Other LV2 hosts may do do things differently and you have no control
over it.
As much as like LV2 from a user's perspective and host integration. It
kinds sucks for visualizations. The only realistic way do to RT
*visualizations* (e.g. a scope) right is to bypass the host (use
instance access & a semaphore) and use openGL with vblank-sync using a
custom thread in the UI (drobilla is going to blacklist me now).
Why? I have constantly said since day 1 that instance-access is
suitable for visualization use. For plugins that do a bunch of stuff
*and* have visualization, they can simply degrade to not having the
fancy visualization part if it's not available. It's people abusing the
facility to do control that I have a problem with, for very good
reasons.
Using instance-access for visualization is 100% OK (assuming graceful
degradation if the plugin does other things). Using it for control is
grounds for being taken out back and shot.
Synchronizing even one [audio] thread with the
gfx-hardware is not
trivial. Default LV2 communication involves two or mo
That being said I do like LV2 Atoms, event-queues, mapped URIs, and more
generally the CY-y way of LV2, though. It's very nice, robust and
elegant for control. Sometimes a tad overkill, but heck, therefore it's
portable, too.
While this is practically true in most cases, it's not really the right
thinking for what's going on here. Essentially what you have between
the plugin instance and UI is a network. The best you get is
"recentish". So, yeah, hardish sync is inherently not happening.
While messages will work just fine for many kinds of basic
visualization, for hyper accurate scopes that want to go so far as to
sync with graphics hardware, obviously it's not the best approach.
That's why instance-access exists. By all means, use it. I'd actually
like to see somebody use the god damned thing for the intended purpose
for a change :P
(If such performance is not required, though, messages are better,
because working across processes and/or networks is handy. Scopes are a
bit much, but e.g. simple meters should certainly do so)
Cheers,
--
dr
4:21 p.m.
Atom messages
are written into a ringbuffer in the LV2host in the
DSP-thread. This ringbuffer is sent to the UI by another thread
(jalv.gtk and ardour use a g_timeout() usually at 40ms ~ 25fps), and
finally things are drawn in the X11 thread ie. gtk-main or qt's main.
Other LV2 hosts may do do things differently and you have no control
over it.
As much as like LV2 from a user's perspective and host integration. It
kinds sucks for visualizations. The only realistic way do to RT
*visualizations* (e.g. a scope) right is to bypass the host (use
instance access & a semaphore) and use openGL with vblank-sync using a
custom thread in the UI (drobilla is going to blacklist me now).
Why? I have constantly said since day 1 that instance-access is
suitable for visualization use. For plugins that do a bunch of stuff
*and* have visualization, they can simply degrade to not having the
fancy visualization part if it's not available. It's people abusing the
facility to do control that I have a problem with, for very good
reasons.
Using instance-access for visualization is 100% OK (assuming graceful
degradation if the plugin does other things). Using it for control is
grounds for being taken out back and shot. 
7 Nov
7 Nov
12:49 a.m.
On 11/06/2013 04:21 PM, Aurélien Leblond wrote:
@Robin: I'll defo have a look at the example you
sent though, that
looks like exactly the type of example I was looking for.
I've just brushed it up a bit, removed all raw-atom write calls, added
RDF attributes for channel-id, etc and also sanitized the drawing
routine somewhat. pushed to
https://github.com/x42/sisco.lv2
Now it is a proper example and should be about halfway towards your needs.
ciao,
robin
9 Nov
9 Nov
8:10 p.m.
On Thu, 2013-11-07 at 00:49 +0100, Robin Gareus wrote:
On 11/06/2013 04:21 PM, Aurélien Leblond wrote:
Perhaps a good candidate for "official" (i.e. included) example?
--
dr
@Robin: I'll defo have a look at the example
you sent though, that
looks like exactly the type of example I was looking for.
I've just brushed it up a bit, removed all raw-atom write calls, added
RDF attributes for channel-id, etc and also sanitized the drawing
routine somewhat. pushed to
https://github.com/x42/sisco.lv2
Now it is a proper example and should be about halfway towards your needs.
9:34 p.m.
New subject: [LV2] LV2: Communicate from the DSP to the UI
On 11/09/2013 08:10 PM, David Robillard wrote:
eg-scope, sure, fine with me; but please give me a few days to add some
more comments to the source: elaborate on Atom-msgs and clearly note
that the scope display itself is horribly wrong design. It's actually a
perfect textbook example of what *not* to do:
* no thread sync. it redraws somewhat randomly
* it's neither accurate nor stable
* it displays raw samples (a proper scope should^Wmust not do that)
* the display itself just connects min/max line segments
* no labels, no scale, no calibration
* ...
maybe Aurélien is going to address some of these issues, and his project
will eventually be suited better for inclusion as official example.
Alternatively removing the drawing routine would IMHO be appropriate for
an example atom-vector communication plugin.
@Aurélien: are you planning to implement a trigger mechanism and/or
history? any plans to add up-sampling and interpolation? what about
markers and numerical readout?
best,
robin
> I've
just brushed it up a bit, removed all raw-atom write calls, added
> RDF attributes for channel-id, etc and also sanitized the drawing
> routine somewhat. pushed to
>
> https://github.com/x42/sisco.lv2
>
> Now it is a proper example and should be about halfway towards your needs.
Perhaps a good candidate for "official" (i.e. included) example?
10 Nov
10 Nov
9:05 a.m.
New subject: [LV2] LV2: Communicate from the DSP to the UI
>> > I've just brushed it up a bit,
removed all raw-atom write calls,
added
>> > RDF attributes for channel-id, etc and
also sanitized the drawing
>> > routine somewhat. pushed to
>> >
>> > https://github.com/x42/sisco.lv2
>> >
>> > Now it is a proper example and should be about halfway towards your
needs.
Perhaps a good candidate for "official" (i.e. included) example?
eg-scope, sure, fine with me; but please give me a few days to add some
more comments to the source: elaborate on Atom-msgs and clearly note
that the scope display itself is horribly wrong design. It's actually a
perfect textbook example of what *not* to do:
* no thread sync. it redraws somewhat randomly
* it's neither accurate nor stable
* it displays raw samples (a proper scope should^Wmust not do that)
* the display itself just connects min/max line segments
* no labels, no scale, no calibration
* ...
maybe Aurélien is going to address some of these issues, and his project
will eventually be suited better for inclusion as official example. Alternatively removing the drawing routine would IMHO
be appropriate for
an example atom-vector communication plugin.
@Aurélien: are you planning to implement a trigger mechanism and/or
history? any plans to add up-sampling and interpolation? what about
markers and numerical readout?
It is a port of the dssi ll-scope:
- trigger mechanism for redraw
- no up-sampling or interpolation I could find in the code, but I could be
wrong there as I didn't dig that deep yet into the gtk widget code
- it has markers but no numerical readout
7:58 p.m.
New subject: [LV2] LV2: Communicate from the DSP to the UI
On Sat, 2013-11-09 at 21:33 +0100, Robin Gareus wrote:
On 11/09/2013 08:10 PM, David Robillard wrote:
I meant the generic idea of trucking stuff via messages for
visualizations, not so much this specific implementation. For the
purpose of an LV2 example, though, many of these aren't so important.
It's more about showing the structure than an actually decent scope.
Maybe a really simple meter would be a better one though.
Anyway, no rush with me these days, as usual :)
--
dr
Perhaps a good candidate for "official"
(i.e. included) example?
eg-scope, sure, fine with me; but please give me a few days to add some
more comments to the source: elaborate on Atom-msgs and clearly note
that the scope display itself is horribly wrong design. It's actually a
perfect textbook example of what *not* to do:
* no thread sync. it redraws somewhat randomly
* it's neither accurate nor stable
* it displays raw samples (a proper scope should^Wmust not do that)
* the display itself just connects min/max line segments
* no labels, no scale, no calibration
* ...
maybe Aurélien is going to address some of these issues, and his project
will eventually be suited better for inclusion as official example.
Alternatively removing the drawing routine would IMHO be appropriate for
an example atom-vector communication plugin.
@Aurélien: are you planning to implement a trigger mechanism and/or
history? any plans to add up-sampling and interpolation? what about
markers and numerical readout?
9 Nov
9 Nov
8:09 p.m.
On Wed, 2013-11-06 at 15:21 +0000, Aurélien Leblond wrote:
[...]
> Using instance-access for visualization is 100%
OK (assuming graceful
> degradation if the plugin does other things). Using it for control is
> grounds for being taken out back and shot.
[...]
Well, there is one simple reason why I cannot use
instance-access -
Ingen doesn't and won't support it :)
My requirements for this scope are:
- must be compatible with Ingen. I want this scope to be used with
other plugins from the avw.lv2 suite
[...]
- I don't want to rely on outside jack apps I
could plug Ingen into.
[...]
As far as synchronization goes, I'm not that
demanding... My scope
needs to be able to compare two inputs, so as long as they are
received in the same "event" I should be ok. The other case would be
to compare the output from a LFO with what I actually hear, but LFO
are so slow that even a 40ms delay shouldn't be much of an issue.
Such a scope is certainly useful. Hardcore graphics stuff like Robin is
into is nice for some things, but not really necessary for most.
--
dr
6 Nov
6 Nov
5:45 a.m.
New subject: [LV2] LV2: Communicate from the DSP to the UI
On Mon, 2013-11-04 at 23:48 -0600, Michael Fisher wrote:
On Mon, Nov 4, 2013 at 6:52 AM, Aurélien Leblond
<blablack(a)gmail.com> wrote:
Bit of a tangent, since this is just host internal (i.e. non-plugin)
stuff, but the blinkenports/meters in Ingen work this way. It actually
works surprisingly well across processes or even a network, though the
current simplistic design (message per port) doesn't scale up to a ton
of ports very well.
--
dr
Hi Michael,
What I think I should be doing is using Blank Atom to transfer the
data from DSP to UI, right?
It sounds logical to me, yeah. Doing it this way could be done by forging
the Blank atom and then writing the float array as raw. You would need to
map a few uris specifically for this to use inside of the blank object.
seems like peak proptocol etc etc.. would could also be used here. I don't
think there's a single host that supports any of those kinds of features
though....
4028
days inactive
4041
days old
linux-audio-dev@lists.linuxaudio.org
16 comments
5 participants
participants (5)
-
Aurélien Leblond -
David Robillard -
Michael Fisher -
Robin Gareus -
Robin Gareus