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

[Hanspeter Portner]

On 27.11.2016 14:08, Torbjörn Rathsman wrote:
> 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.

I see, you're trying to implement the patch extension.
I'd recommend to look at eg-params as a proper example instead [1].

When UI is initialized (or wants to reload the whole state), it sends an empty
patch:Get message to the DSP. The DSP listens for patch:Get messages and answers
them with patch:Set messages. If some value is changed on the UI side, it sends
a patch:Set message to the DSP. If some value changes on the DSP side, it sends
a patch:Set message to the UI.

[1] http://lv2plug.in/git/cgit.cgi/lv2.git/tree/plugins/eg-params.lv2

> 2016-11-27 12:08 GMT+01:00 Hanspeter Portner <ventosus at airpost.net
> <mailto: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
>     <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
>     <https://gitlab.com/OpenMusicKontrollers/tracker.lv2/blob/master/tracker_ui.c#L603>