29 Nov
2007
29 Nov
'07
11:22 p.m.
On Friday 30 November 2007, Dave Robillard wrote:
[...]
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.
[...]
In fact, I'm not even sure myself now... That might have something to
do with it. ;-)
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. Yes,
obviously. I don't quite see what you think I'm trying to say
here. :-)
[snip]
Me neither :) 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 --'