On Thursday 06 February 2003 07.50, Tim Hockin wrote: [...Paul's k5000...] > 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... 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. > 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 ---