On Monday 09 December 2002 15.29, Steve Harris wrote: > On Mon, Dec 09, 2002 at 02:31:24PM +0100, David Olofson wrote: > [audio rate controls] > > > Well, ok. You can have those *too*. (I'm Santa! :-) > > Well, you can obviously "have" them, but I dont think you want to > have sophisticated support for both. That would make the API > bloaty, and only nuts like me actually use audio rate control in > 2002.
Where's the bloat? We need audio ports anyway, right? > Converting between continuous control and event control is not > reliable, and kinda removes the point of cont. control. Yes, but without converters, you can't do things like applying audio effects on controls... > > > I look forward to a few years where all DSP code can run > > > blockless and with audio rate (or near audio rate) control. > > > > Have you considered that timestamped events may actually have > > *better* than sample accurate timing...? ;-) (Well, I actually > > suspect that subsample accurate timing will show up sooner or > > later - as a buzword or because it actually matters. Maybe we > > should allocate some bits for it while we're at it?) > > I dont think its meaningful. At least not efficiently. I't be a > better use of cycles (and devloper time) to just run the whole > thing at 96k IMNSHO. Yes, but that's only one bit per sample. Is that sufficient for the most extreme accuracy nuts? Anyway, no I don't think there would be much point in messing this, at least not until we've actually seen it in use, and understand better *why* it's used. [...] > > I don't think that DSPs or generic CPUs will *ever* be fast > > enough that you can completely stop worrying about performance. > > You think convolution is heavy stuff? Wait until you see what the > > cutting edge > > Hey, I've never though that you can forget about performance, its > just that the cost of things like blockless processing and > contonuous control get lost in the noise when you start throwing RT > convolvers around. Well, yeah - and if you can run hundreds of *those*, it probably doesn't matter that every single synth voice spends more CPU time processing control data than audio. :-) > And aynway statments like "CPUs will *ever* be fast enough"... are > usually proven false later ;) Yes - but I'd rather not wait ten years before I can actually *use* my software! :-) In fact, I've already waited *more* than ten years already for PCs to become at all usable for serious audio synthesis and recording. Now they are, but since I didn't have Linux/lowlatency some years ago, I never got around to write any hopelessly inefficient software that would have been just fine today. ;-) > There are some hardware synths in existence today that use cont. > control and blockless processing. The improvement in sound quality > is noticable. Do they use that for *everything* (like all parameters, switches etc), or just where it actually matters? //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 ---
