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 --' _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
