[LV2] Feature request: DSP write_function() ?

[Hanspeter Portner]

On 22.12.20 17:52, Hermann Meyer wrote:
> 
> 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.

Please open an issue on gitlab/github, this is the wrong place for that, imho.