7 Dec
2002
7 Dec
'02
9:32 p.m.
David Olofson <david(a)olofson.net> writes:
Yes - but we're not talking about MIDI here. We *may* require that
events are never lost, and even that it's not legal to send two
identical events in line to an event port, unless you really mean
something else than to set a controller to the same value twice.
Think ahead about how these sorts of requirements will be enforced:
will they be a "law of nature" (code checks to see if an app broke
the law, and takes action, like nature takes action when you try
to change the current flowing through an inductor :-), or will
it be unchecked by code? If its the latter, you can get into
this mode where everyone has extra checking and work-around code,
to handle impolite API users who aren't obeying the requirements.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
7 Dec
7 Dec
10:26 p.m.
New subject: [linux-audio-dev] Plugin APIs (again)
On Sunday 08 December 2002 03.27, John Lazzaro wrote:
Well, I wasn't seriously suggesting that we have that kind of silly
rules. Still, they would not be totally unreasonable, given that you
can never have two event sources manipulate the same control in a
useful way; it would just result in the value jumping around. So, who
would send the same value twice?
If someone frequently tries to set a control to the value it already
is set to, that's bad manners.
If a plugin actually starts recalculating filter coefficients and
stuff as a result of receiving such a control event, that could alse
be considered bad manners - BUT, avoiding it would mean an extra
conditional. Why have a conditional to avoid doing something
relatively harmless, that can only happen as a result of someone else
being nasty?
That said, if hosts want to filter event streams from poorly written
event generators, fine - but IMHO, it's a waste of resources,
shouldn't be needed at all, and can only prevents something that's
relatively harmless.
Anyway, there might be cases where we can use "trigger" controls,
where the value is an argument, and the plugin is supposed to
actually *do* something as a response, every time, regardless of the
value of the argument.
If we want those, they should be explicitly marked as special - just
like non-RT events. Or just like the few MIDI CCs that filters may
not remove. The only difference is that we don't have a fixed set of
controls with implicit rules, but use use some hints and flags
instead.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
David Olofson
<david(a)olofson.net> writes:
Yes - but we're not talking about MIDI here. We *may* require
that events are never lost, and even that it's not legal to send
two identical events in line to an event port, unless you really
mean something else than to set a controller to the same value
twice.
Think ahead about how these sorts of requirements will be enforced:
will they be a "law of nature" (code checks to see if an app broke
the law, and takes action, like nature takes action when you try
to change the current flowing through an inductor :-), or will
it be unchecked by code? If its the latter, you can get into
this mode where everyone has extra checking and work-around code,
to handle impolite API users who aren't obeying the requirements.
8059
days inactive
8059
days old
linux-audio-dev@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
David Olofson -
John Lazzaro