[LV2] Combining MIDI + Atom Transport + Resize Port

[Vladimir Sadovnikov]

Sorry, I had an issue in UI wrapper in the second case. After I fixed it (the UI 
wrapper wrote to atom port with invalid index), Ardour worked fine.
Carla crashed the UI.

Today I've tested the nightly build of Ardour, and both cases work well.

Also the case with separated MIDI and generic Atom ports is back-compatible with 
Ardour up to 4.2.0 (didn't test for older versions).

Filipe Coelho (falkTX) also made some fixes in Carla today, so it starts the UI 
now but currently works slowly.
His issue was also related to many URIDs mapped by the plugin.

> http://tracker.ardour.org/view.php?id=6823
No, it's not my issue. I use Atom:Path for transfers.

> http://tracker.ardour.org/view.php?id=6829
It's not my case, too. I use Atom:Path, again.

So, I think, currently I'm ready to make the release in a few days.
Robin Gareus (x42) and Filipe Coelho (falkTX) have done some improvements of the 
code,
so Ardour and Carla became more stable with Atom transport.

Great thanks to them.


28.04.2016 11:52, Hanspeter Portner пишет:
> On 27.04.2016 22:12, Vladimir Sadovnikov wrote:
>> [...]
>> The MIDI ports:
>>          [
>>                  a lv2:InputPort, atom:AtomPort ;
>>                  atom:bufferType atom:Sequence ;
>>                  atom:supports atom:Sequence, midi:MidiEvent ;
>>                  lv2:index 4 ;
>>                  lv2:symbol "in_midi" ;
>>                  lv2:name "Midi events input" ;
>>          ] , [
>>                  a lv2:OutputPort, atom:AtomPort ;
>>                  atom:bufferType atom:Sequence ;
>>                  atom:supports atom:Sequence, midi:MidiEvent ;
>>                  lv2:index 5 ;
>>                  lv2:symbol "out_midi" ;
>>                  lv2:name "Midi events output" ;
>>          ]
>>
>> And the UI communication ports:
>>
>>          [
>>                  a lv2:InputPort, atom:AtomPort ;
>>                  atom:bufferType atom:Sequence ;
>>                  atom:supports atom:Sequence, patch:Message ;
>>                  lv2:designation lv2:control ;
>>                  lv2:index 72 ;
>>                  lv2:symbol "in_ui" ;
>>                  lv2:name "UI IN" ;
>>                  rdfs:comment "UI -> DSP communication" ;
>>                  rsz:minimumSize 615424 ;
>>          ] , [
>>                  a lv2:OutputPort, atom:AtomPort ;
>>                  atom:bufferType atom:Sequence ;
>>                  atom:supports atom:Sequence, patch:Message ;
>>                  lv2:designation lv2:control ;
>>                  lv2:index 73 ;
>>                  lv2:symbol "out_ui" ;
>>                  lv2:name "UI OUT" ;
>>                  rdfs:comment "DSP -> UI communication" ;
>>                  rsz:minimumSize 959488 ;
>>          ]
> I'd expect the midi event ports to have the lv2:control designation, not the ui ports.
>
>> Now in Ardour I got SEGFAULT:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [...]
> Cannot really help without any code or at least a binary. As you don't want to share your code yet, can't you come
> up with a dummy, minimal, shareable, non-working example plugin that exhibits your issues?
>
> You seem to use patch:Message to communicate between DSP/UI. Ardour (<=4.7) intercepts atom:Path patch:Messages and
> will block any other patch:Message [1] or even crash on them [2]. Maybe you're experiencing the same bugs as I have?
>
> [1] http://tracker.ardour.org/view.php?id=6823
> [2] http://tracker.ardour.org/view.php?id=6829
>
>> In Carla I get strange behaviour: all atoms are serialized into MIDI ports, there is no transfer over 'in_ui' and
>> 'out_ui' ports. So my plugin and UI does not see transferred Atom objects.
>>
>> So we get that both variants do not work well and I can not release the LV2 version of plugins (the LinuxVST version of
>> plugin, indeed, works well because has no LV2 Atom Transport).
> Whenever you're doing something out of the ordinary in an LV2 plugin (even if it's very well according to the spec), you
> can expect (count on it, even) for bugs to show up in one or another host.
>
> My humble Moony plugins [3] use separate UI atom ports + dedicated realtime event ports (MIDI et al.). The setup seems
> pretty similar to yours truly. http://open-music-kontrollers.ch/lv2/moony#a1xa1 (one in the bundle that makes sense to
> actually be run in a DAW) runs fine in Qtractor (0.7.5), jalv (git master only) and Ardour (git master only).
>
> [3] http://open-music-kontrollers.ch/lv2/moony
>
>> - Is it a normal practice to separate MIDI ports into independent Atom ports? What's the proper solution?
>> - How the hosts should handle MIDI ports implemented as independent Atom ports?
>> - Is it a normal practice to combine MIDI event transport and Atom transport into one Atom port? What's the proper >
> solution, again?
>> - How the hosts should handle combined MIDI and Atom transport with enabled Resize Port extension?
>> - How the hosts should handle multiple Atom ports with the same direction (Input/Output)?
>> - Why official LV2 Specs do not say anything about how to use multiple Atom ports by the plugin and how to handle
> multiple Atom ports by the host?
>
> Either way should be valid, imho, e.g. processing everything (UI + realtime events) in a single atom port or
> splitting them up into dedicated realtime event + UI atom ports.
>
> http://lv2plug.in/ns/ext/resize-port#minimumSize is pretty clear: if a plugin requests rsz:minimumSize for one of
> its ports AND the host supports that property, it MUST provide it. If the host does not, it is obviously broken.
>
> Even if the host provides you with a large enough atom port, you still may run into problems if the host has
> a too small ringbuffer between DSP/UI threads for the amount of data you want to send, that's what may happen in [4].
>
> [4] http://tracker.ardour.org/view.php?id=6679#c17707
> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in