[LV2] Sharing sample data between plugin and ui

[David Robillard]

On Sun, 2018-10-21 at 14:51 +0200, Stefan Westerfeld wrote:
>    Hi!
> 
> I'm at a point where I want a LV2 plugin to load sample data for
> processing and
> the UI should be able to access the sample data for drawing. Since
> the sample
> data may be large, I think it cannot be sent as one message.
> Splitting it up
> into multiple messages sounds complicated.
> 
> Of course this could be solved by requiring instance access, but as
> far as I
> understand it, instance access is not a recommended feature.
> 
> So I wonder if a good solution would be to only send a filename as
> message from
> the plugin to the UI, and the plugin and UI would load the sample
> from the same
> file. This would break if plugin and UI were running on different
> hosts, but I
> don't know if LV2 is even supposed to support this case.

This is (IMO) the only legitimate use of instance access: optional
visualization.  So if you really need it here for that, I think that's
fine.  Of course then it would only work in-process, if you care.

That said, depending on how/what you want to draw, you may be able to
compress the data to sparse enough peaks that you can send it, and/or
chunk it up.  It's not *terribly* hard to do this in a chunky way if
you want to, see eg-sampler.  There is a relatively standalone peaks.h
that you can use for this, or steal and adapt to do something similar. 
The actual drawing code in this example is pretty crap, but the
underlying mechanism is decent.

Assuming both share a filesystem isn't terrible though.  Ideally things
will work across a network, though admittedly most don't care.  I think
this would be fineish if it can be detected easily, but I'm not sure
about that part.  You can put hostnames in file URIs, but hostnames are
pretty sketchy.  I guess just assuming if the file actually exists,
then it's probably the same one, is good enough for almost all cases...

Depends on what you care about and how much work you want to do, I
suppose.  Personally I really like process- and network- transparent
UIs, but recognize that the cost:benefit is pretty rough sometimes.

-- 
dr