6 Feb
2003
6 Feb
'03
3:45 p.m.
On Thursday 06 February 2003 07.50, Tim Hockin wrote:
[...Paul's k5000...]
Not the host; the *sender*. That is the sequencer (which can be part
of the host), or more interestingly, any plugin that has control
outputs.
The top-of-chain plugin (synth) will tell you when it
is silent, of
course!
I think it can be a massive, coarse-grain optimization, if we can
make it work.
I think it'll be rather useless if done on the plugin level, with
synths and other devices with many audio ports. As soon as we start
talking about multitimbral/multichannel synths without internal FX,
we're talking about *trees*; not chains.
----------------------------------------------------------------
On Thursday 06 February 2003 11.21, Steve Harris wrote:
On Wed, Feb 05, 2003 at 08:21:06 +0100, David Olofson
wrote:
[...]
Yeah,
that's basically where I'm getting. I don't really like it,
considering what it does to plugin code, but it's not *that* bad,
and it makes life a lot easier. The cost of having hosts do it
would be *much* higher, and you'd basically have to do it all the
time, I think.
It sounds like the wrong thing, the general case is that the host
generates values its knows to be in range, then the plugin checks
it again to check its in range... If we allow hard ranges (not really neccesary, as
LADSPA shows)
then the host should enforce them.
Which would mean the host has to break in whenever you connect two
controls, *only* to do this.
[...later...]
OTOH the plugin /should/ be resposible for ensuring
that its
outputs dont go outside the specifed ranges.
Of course.
Remeber that, i they are allowed at all, hard ranges
should be
rare. There seems to be a siuggestion in the PTAF document that
host may have to be responsibe for killing denormal numbers anyway,
so they will have to snoop controls in that case.
Ouch. Well, the way PTAF is designed, it seems that hosts have to
handle all events ever sent anyway, but I could be missing something.
Either way, this is *not* the case with XAP, and I think that's a
good thing. I would very much like to settle the issue with ranges
without screwing this up.
----------------------------------------------------------------
On Thursday 06 February 2003 11.38, Steve Harris wrote:
[...audio data...]
"Normalised floating point" is a well know
term, but normalised
between -1.0 and 1.0 is wrong.
Why? Is +/- 42.0 P-P or something a better 0 dB reference? :-)
[...points about silence in RT systems...]
You cant use the "free" cycles, because
youre never sure when the
plugin is going to wake up and start chewing CPU again, and in any
case you dont know how much it was really using.
It's useful in Audiality, but only really when you're dealing with
multiple songs, "rooms" or whatever in the same application. Might be
that it's not a feature that should be in XAP.
[...]
"Silence" is relative. A reverb will onyl
decay to mathematic
silence after a really long time, but that isnt the intention of
this hint IMNSHO.
Good point, though it doesn't make silence useless in Audiality, at
least. If the reverb *does* go "silent" within any reasonably amount
of time, the information is useful. Synths generally go silent as
soon as the release phase of the last note is done (which is
generally well defined), so it's *definitely* useful there.
----------------------------------------------------------------
On Thursday 06 February 2003 11.40, Steve Harris wrote:
[...silence processing...]
I agree, and more than that its not a usful
optimisation (in RT
processing), I dont htink the offline case is important enough to
warrent this level of complexit and debugging nightmare.
If you can point me to a working (not pure research) implemntation
I will consider that it might not be total insanity ;)
Audiality. :-)
The reason I have it is that games and other multimedia stuff should
be able to just set up all FX processing needed for the whole thing
and then not worry about it. You can have the full FX net for every
song in the game "running" at all times virtually without cost. The
plugins won't start burning CPU until you actually send some sound
their way, and they'll stop burning CPU as soon as their tails are
out.
Whether or not this is useful in your average studio is another
matter, but it does *work*.
//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 ---