[LV2] Questions about passing strings and other data from UI to LV2 plugin

[Torbjörn Rathsman]

 This is what I talk about (from sampler example):

LV2_Atom_Forge_Ref set = lv2_atom_forge_object( forge, &frame, 0,
uris->patch_Set); lv2_atom_forge_key(forge, uris->patch_property);
lv2_atom_forge_urid(forge, uris->eg_sample); lv2_atom_forge_key(forge,
uris->patch_value); lv2_atom_forge_path(forge, filename, filename_len);
lv2_atom_forge_pop(forge, &frame);

This is what happens after lv2_atom_forge_set_buffer. I guess I need to
write data from DSP to UI as well when state is reloaded. Also I know the
payload size without strlen.

2016-11-27 12:08 GMT+01:00 Hanspeter Portner <ventosus at airpost.net>:

> On 27.11.2016 09:58, Torbjörn Rathsman wrote:
> > I need to pass a string from the UI to the plugin. From the eg-sample, it
> > appears that an LV2 atom should be written to a atom port.
> >
> > If I understand it correctly
> >
> >  1. Allocate a LV2_Atom_Forge. May that object be on the stack or does
> it have
> >     to survive after the UI event callback has returned?
>
> This could be on the stack, but it makes sense to make it part of UI/plugin
> struct/class directly as the forge needs to be initialized before use
> (lv2_atom_forge_init). e.g. initialize once (in your initialize routine),
> use
> many times...
>
> >  2. Call lv2_atom_forge_set_buffer. How do I know the required size of
> the
> >     buffer? Is it the size of the payload (the string), or does it
> include any
> >     headers. The example sets it to 1024 bytes for no reason. May the
> buffer be
> >     allocated on the stack or does it have to survive the UI after the
> UI event
> >     callback has returned?
>
> It does include headers (and padding), so for your string, a safe minimum
> is:
>   uint32_t capacity = lv2_atom_pad_size(sizeof(LV2_Atom) + strlen(str) +
> 1)
>
> Don't forget to initialize the forge structure (lv2_atom_forge_init), this
> sets
> vital variables in the structure.
>
> I use lv2_atom_forge_set_buffer manly on the DSP side (where you cannot use
> malloc et al.). On the UI side it's more convenient to use
> lv2_atom_forge_set_sink with which you can implement growing buffers and
> don't
> have to ask yourself about maximal buffer sizes in the first place, e.g.
> [1].
>
> >  3. Add some objects. The API uses key-value pairs. Should the size of
> keys be
> >     included in the buffer size?
>
> Not sure what API you mean, but as mentioned above, just use a growing
> buffer.
>
> >  4. Write the data to an atom input port
>
> Yes, but don't forget to use the proper port protocol in the writer
> function,
> e.g. atom:eventTransfer [2].
>
> [1]
> https://gitlab.com/OpenMusicKontrollers/tracker.
> lv2/blob/master/tracker_ui.c#L595
> [2]
> https://gitlab.com/OpenMusicKontrollers/tracker.
> lv2/blob/master/tracker_ui.c#L603
>
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20161127/88a426a4/attachment.htm>