[LAD] "enhanced event port" LV2 extension proposal

[David Olofson]

On Friday 30 November 2007, Dave Robillard wrote:
[...]
> > Sounds like there's a fundamental difference there, then. I'm
> > using a model where a port is nothing more than something that
> > deals with a value of some sort. There are no channels, voices,
> > different events or anything "inside" a port - just a value. An
> > output port can "operate" that value of a compatible input port.
> 
> LV2 ports can contain /anything/.  It's a void*, completely 100%
> opaque in every way.  There might be 'channels' or 'voices' or
> a 'value' or whatever in there, it's just data.

Well... That's really what I have as well, looking at the actual 
specification. Sorry for just causing confusion here... :-/

There are no explicit limitations to what A2 ports can deal in. It's 
just that there is no host level concept of channels, voices or 
anything like that, whatsoever, below the port level.

There is 2D addressing *above* the port level, for telling plugins 
what ports you're talking about, and that's all there is to it, as 
far as the host is concerned.

You could use some port type for "raw" MIDI (all channels on one 
port), so you can route that around the graph, much like physical 
MIDI cables. (I'll most probably use that for MIDI<->control mappers 
and the like in plugin form. The host design is pretty much modelled 
after the microkernel OS idea; plugins are the processes, ports are 
the the interface to IPC etc. So, I don't want to force I/O code and 
whatnot into the actual host, but rather provide that as plugins.)

That's as far as you get with those MIDI (or any other multichannel) 
ports, though. If you want to do modular synth style wiring (control 
by control), you need other types of ports - like ramped control 
event ports - if the host is to be of any assistance in wiring them.


[...]
> > Yes, obviously. I don't quite see what you think I'm trying to say 
> > here. :-)
> [snip]
> 
> Me neither :)

In fact, I'm not even sure myself now... That might have something to 
do with it. ;-)


> There are of course infinite ways to do 'events' for plugins (and an
> infinite number of interpretations of what 'events' means).  Nice
> thing about LV2 is you can do them all.  Something like your
> non-flat event stuff (with queueing and linked lists and dispatching
> and such, rather than plain old directly connected buffers) may find
> a place in LV2 as well -

Right; dispatching and stuff... I think this is about where the 
confusion starts. How is this supposed to be done here? Are 
LV2 "enhanced event ports" opaque, all-in-one, somewhat like 
the "raw" MIDI I'm talking about above, or how are LV2 hosts supposed 
to deal with them?

I've been confusing this with the way I address ports in A2, which 
doesn't really have anything to do with the API. Again, there are 
just ports (abstract objects) that can be connected (through plugin 
callbacks), and that's all we see of it from the host side.

Now, the "standard" event model I'll use for most plugins will share 
queues for simplicity and performance - so events will need to be 
marked somehow (internal index to something, usually), so the plugin 
knows which event goes where. This, however, is stuff that only 
plugins actually using this event model need to deal with. You can't 
see this on the plugin API level - and some plugins may in fact use 
some other event system with just a flat buffer for each port->port 
connection, for that matter. :-)


> may have to for certain message-based 
> (ahem) "programming" modular stuff ala Max.  What we have now is the
> sample accurate hard realtime sort of 'events' (ala Jack MIDI).
>
> Havn't quite figured out the bridging of those two worlds yet....

We are talking "abuse of real time event system for passing of 
asynchronous messages" or something along those lines...?


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'