[LV2] Feature request: DSP write_function() ?

[Hermann Meyer]

Am 22.12.20 um 16:42 schrieb Hermann Meyer:
>
> Am 22.12.20 um 16:21 schrieb Hanspeter Portner:
>> On 21.12.20 21:11, Hermann Meyer wrote:
>>> Am 21.12.20 um 20:44 schrieb Hanspeter Portner:
>>>> On 21.12.20 19:43, Hermann Meyer wrote> Synthpod have it own issues
>>>> as well,
>>>> so for example it create controls
>>>>> for patch:writable and patch:readable separately (Means it double
>>>>> controls and only sync the readable ones to the plugin GUi, while you
>>>>> could only change the writable ones, which are basically the same,
>>>>> but
>>>>> threaded different). This do as well not allow to sync the plugin GUI
>>>>> with host provided UI, and easily lead to a overflow in the atom ring
>>>>> buffer.
>>>> Can you show your *.ttl, please?
>>> you know it:
>>> https://github.com/brummer10/Fluida.lv2/blob/master/Fluida/Fluida.ttl
>> Sorry , my bad, git checkout from github nowadays grabs the *main*
>> branch by
>> default, and your experiments are on the *master* branch.
>>
>>>> I think you've misinterpreted something there. An lv2:Parameter either
>>>> is patch:writable (read-write) OR patch:readable (read-only), but not
>>>> both, if I'm not totally mistaken, that is.
>>>>
>>>> If you list the same parameter both as patch:writable AND
>>>> patch:readable,
>>>> then indeed synthpod may show two generic UI elements with only one
>>>> being
>>>> active.
>>>>
>>> See
>>> https://github.com/lv2/lv2/blob/master/plugins/eg-params.lv2/params.ttl
>>>
>>> plug:spring ;
>>>
>>> It stated that parameters which may be changed internal by the
>>> plugin must be
>>> listed as patch:readable
>> Then eg-params is still wrong, because all of its parameters can
>> internally be
>> changed upon a state:restore.
>>
>> Makes no sense to argue here, though, we will know for sure once
>> drobilla will
>> chime in.
>>
>>> and, if they may be changed by the user they must be listed as well as
>>> patch:writable
>>>
>>>
>>> btw. that is needed for the MOD to make parameter sync work, for
>>> Qtractor it
>>> doesn't matter, it works with and without it, for Synthpod it leads
>>> to the
>>> behave described above, for Ardour it leads to a couple of error
>>> messages, Carla
>>> ignore it at all.
>>>
>>> But even if I mark those ports only as patch:writable. synthpod
>>> wouldn't sync
>>> the port values between plugin GUI and host provided UI.
>> Well, synthpod in git now just ignores patch:readables, when they've
>> already
>> been defined as patch:writables. Should fix all your issues.
>>
>> Both sync custom->generic and generic->custom gui work as intended.
>>
>>
>>
> Nice, thanks a lot!
>
> regards
>
> hermann
>
>

Well, I would love to confirm that it works now flawless, but
unfortunately I cant.

While communication between synthpod host UI and plugin GUI works now
bidirectional, synthpod still fails in real use with

(DSP) [Trace] _notification_list_add: failed to append to: MIDI_IN

were MIDI_IN is the atom notification port of the plugin.

on a simple toggle button, or a knob turn, or what ever action from the
plugin GUI.

As soon that happen the first time, no message arrive anymore in the
plugin. Looks to me as if the atom ring buffer didn't erase messages
which have been deliver, so when it's full it's full, no more messages
accepted.

As soon I close the plugin GUI and reopen it, it works again for a given
amount of messages, then it fail again.