20 Jan
2003
20 Jan
'03
1:15 p.m.
On Monday 20 January 2003 16.15, Steve Harris wrote:
Exactly.
Agreed.
At the time, it happens to be a shortcut in Audiality, but as soon as
I implement modulation of the envelope generators, that shortcut will
be essentially useless, since the hold and sustain sections will no
longer be guaranteed flat. (The EG will basically be multiplying the
envelope with one or more streams of control events.)
On Mon, Jan 20, 2003 at 04:13:17 +0100, David Olofson
wrote:
I totally agree on this. The reason why I'm bringing it up is that it
was originally suggested that a RAMP event refers to a specific range
in time; basically a "macro event" that describes two actions; one
now and one at the end of the ramp. (Physically, the latter action
would be "stop ramping", although that has been ruled out as tricky
to implement while not useful.)
5) A more serious issue is that if control
events are not
allowed while ramping, except at the time of the aim
point, there is no way to avoid sending one RAMP event
for each block while ramping. You can't aim further
ahead than the first frame of the next block, or you
might have to break in and adjust the aim before you
hit the aim point.
I dont see why there is a restriction on aiming further ahead than
the current block, this seems like a mistake. It forces the plugins
to be closed to linear than is desirable. Questions:
A) Is it necessary to require that aim points are
within the current block, to avoid "re-aiming"?
I dont see why, the obvoius inner loop for ramp aiming should deal
with this perfectly well, it will just replace the delta_control
number. B) Is STOP
useful enough to be in XAP?
I'd argue for it not be be there. Its hard to see when it would be
useful ,ad its one more thing to handle. SET /could/ be done with a ramp with target time of 0,
not
optimally efficeint,
OTOH, this test must be done somewhere anyway. (Audiality does it on
the sender side, as it has SET + RAMP.) It could be argued that with
pre-recorded event streams, it's better to use SET, as that
eliminates the run-time conditional altogether, but I'm not sure it's
worth it. (It's just one very simple test...) For control streams
generated on the fly, it doesn't matter much where you do it.
but the cases I can think of it wont hurt:
notched switches: will always jump to the target value anyway, so
wont have to do any interpolation.
RAMP is always interpreted as SET? Not the best way to fake ramping,
but then, if you say you do not ramp, you shouldn't be expected to
even fake it. Makes sense.
continuous controls: SET operations will be quite
unusual, and the
overhead is not that big.
So, alternative 1; RAMP events only:
case XAP_A_RAMP:
if(ev->duration)
dvalue = (ev->value - value) / ev->duration;
else
{
value = ev->value;
dvalue = 0.0;
}
break;
- Adds a receiver side conditional for decoding, even if
the input is prerecorded.
- Contrary to the normal logic, duration == 0 implies
that ramping is *stopped* by the RAMP event.
+ Senders don't have to check for 0 duration.
+ duration == 0 becomes a valid and logical case.
+ Won't blow up if a 0 duration is "accidentally" sent.
+ More streamlined API; only one event per control type.
Alternative 2; RAMP and SET:
case XAP_A_SET:
value = ev->value;
dvalue = 0.0;
break;
case XAP_A_RAMP:
dvalue = (ev->value - value) / ev->duration;
break;
- More events in the API.
- Senders must replace 0 duration RAMPs with SET.
- Sending 0 for RAMP duration may have plugins blowing up.
- Turns "ramping with dv == 0" into a special state.
+ No extra conditional for duration; switch() is full decode.
+ No 0 duration testing at all when playing prerecorded events.
Using only RAMP events definitely looks like a great idea to me. I'm
going to try it in Audiality right away! :-)
BTW, using INFINITY for duration (MAXINT for fixed point, provided
MAXINT is not a valid control value) has the same effect as a STOP
event... Should this be allowed? We've already concluded that the
STOP action - whether it's an event of it's own or not - isn't very
useful, so maybe we should just leave this in the "undefined
behavior" domain.
And yes, duration would be of the same type as the control value, I
think. There's no point in making it an integer for float controls,
since plugins will only use it for a aim point -> dv transformation
anyway.
//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 -'
--- http://olofson.net --- http://www.reologica.se ---