[LV2] Combining MIDI + Atom Transport + Resize Port

[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