29 Nov
2007
29 Nov
'07
9:42 p.m.
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.
Of course, that "value" could be anything, but I'm not explicitly
supporting that on the API level. If plugins want to use MIDI
messages, they're on their own when it comes to mapping of channels,
CCs etc. That stuff is really beyond the scope of my project, as one
wouldn't be able to configure and control such things normally.
Yes, obviously. I don't quite see what you think I'm trying to say
here. :-)
Right, but that's mostly about Audiality 2 anyway. There, if I for
some reason started with control events without ramping, I'd add
another "control events v2" port type. If that type happens to be a
superset of the first one doesn't really matter, as they're still not
compatible.
Where it makes sense, one can provide converters to/from other types,
but to the host (the low level machinery directly dealing with plugin
graphs, that is), those are just ordinary plugins with only one input
port and one output port.
Nah. I'm just in the middle of another project, and the Audiality 2
code isn't in a state where I could post that without just adding to
the confusion. And, I think we might have a terminology impedance
mismatch. :-)
That's why
I'm using a Port as the smallest "connection unit",
much like LADSPA ports, so there is no need for an event type
field of any kind at all, let alone a URI.
Ports /are/ the smallest "connection unit". But ports can /contain/
events, and if we want multiple kinds of events in a single port,
then the events themselves need a type field. The data in
the events *could* be MIDI or whatever (the host
doesn't even have to understand any of it), but normally, in the
case of Audiality 2, it'll be modular synth style ramped control
events. That is, one port controls exactly one value - just like
in LADSPA, only using timestamped events with ramping info instead
of one value per buffer.
The host might not have to (though in practise it usually does), but
other plugins certainly do. You can't process events if you don't
even know what they are. Extensibility
is a non-issue on this level.
OK, the event extension doesn't define your ramped control events,
so you're not allowed to use them, ever, period.
... looks like extensibility is an issue at this level, eh? ;) What you do if
you want
more stuff is just grab another URI for a new event based
protocol, and you get to start over with a fresh event struct to
use in whatever way you like. (In fact, as it is, the host doesn't
even have to know you'll be using events. It just provides a LIFO
pool of events for any plugins that might need it.)
Sounds like you're thinking too hard. "Events" here are just a bunch of bytes in a
flat buffer.
Mine are implemented as linked lists of small memory blocks, for
various reasons. (I've had a working implementation for years, so
I'll stick with that for now. Not saying it's the best or most
efficient way of doing it, but I have yet to figure out how to bend
flat buffers around my event routing model - or the other way
around.)
I did "hardwire" fixed point timestamps as those are closely related
to the whole deal with sample frames, buffers etc - but the data area
is indeed just a bunch of raw bytes.
There is definitely no protocol here. Please, please
don't
say "protocol". That way lies painful digressed conversations,
trust me.
I'm open to alternative terminology. :-)
What I'm talking about is just the name of "whatever goes on between
connected ports." I don't want the term to be too specific, as it
also covers LADSPA style audio buffers, shared buffers (which can
contain function pointers) and whatever else plugins might use to
communicate.
//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 --'
29 Nov
29 Nov
9:57 p.m.
New subject: "enhanced event port" LV2 extension proposal
On Fri, 2007-11-30 at 02:39 +0100, David Olofson wrote:
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 - 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....
-DR-
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.
That's why I'm using a Port as the smallest "connection unit",
much like LADSPA ports, so there is no need for an event type
field of any kind at all, let alone a URI.
Ports /are/ the smallest "connection unit". But ports can /contain/
events, and if we want multiple kinds of events in a single port,
then the events themselves need a type field. The data in the events *could* be MIDI or whatever
(the host
doesn't even have to understand any of it), but normally, in the
case of Audiality 2, it'll be modular synth style ramped control
events. That is, one port controls exactly one value - just like
in LADSPA, only using timestamped events with ramping info instead
of one value per buffer.
The host might not have to (though in practise it usually does), but
other plugins certainly do. You can't process events if you don't
even know what they are.
11:22 p.m.
New subject: "enhanced event port" LV2 extension proposal
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 --'
30 Nov
30 Nov
midnight
New subject: "enhanced event port" LV2 extension proposal
On Fri, 2007-11-30 at 04:19 +0100, David Olofson wrote:
They're simply byte arrays of timestamped 'events', where an 'event'
is
some length of bytes.
[timestamp|size|data|timestamp|size|data|timestamp|size|data]
(This is current MIDI; add type or whatever results from this thread)
Idea being that timestamps are in frames and everything is in-band and
sample accurate and processed in blocks along with the audio. Hosts can
just directly connect the pointers of an input and output port to the
same buffer and have the plugins talk to each other, or blindly memcpy
the whole thing around. Just Like Audio(TM).
-DR-
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?
5990
days inactive
5990
days old
linux-audio-dev@lists.linuxaudio.org
3 comments
2 participants
participants (2)
-
Dave Robillard -
David Olofson