Re: [music-dsp] warts in JUCE
On Sat, Sep 5, 2015, at 01:23 AM, robert bristow-johnson wrote: > same problem (if that *is* a problem) if you pass sampleRate alongside > the AudioSampleBuffer rather than inside of it. I agree, that would be the worst of both worlds. (At least from this perspective -- there may be other reasons to make an API that way.) The most relevant point I think is that, because this is a class-based object oriented language, your filter function doesn't have to be just a function: it will generally be implemented as a class (with a processing function, but also a constructor) instead. And the class can be supplied the sample rate on construction. So you don't have to pass the sample rate in to the processing function at all, but by constructing different instances of the class you can still set up different versions of the function according to the sample rate in use. There is a middle ground between "a single fixed sample rate throughout the whole application" (or, worse, 44100 hardcoded) and "every process call gets the sample rate supplied to it". > now suppose the source of audio changed (like a different file or > different internal buffer is now gonna be sent out) and it's a different > sample rate attached to it. now the function sees that it's a different > input rate and the interpolation step-size must change and it's > recalculated. A function whose job is to convert between sample rates is something of a special case. > no, it's the opposite. i gotta filter method and you send me an > AudioSampleBuffer and some parameters for the filter such as type (LPF, > etc), Q, and cutoff frequency (in units of physical frequency). i > cannot do the job until i know what the sample rate is. the best thing > is if i look at the AudioSampleBuffer itself That's likely to be too late. When you get audio data, you may be already in a realtime processing context and you may not be able to do rate dependent initialisation any more. You want to know the sample rate before that, and often you aren't in a position to reinitialise on the fly if it changes. So it makes sense for a processing class to get it on construction. Chris ___ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] warts in JUCE
On 6/09/2015 8:37 AM, Daniel Varela wrote: sample rate is part of the audio information so any related message ( AudioSampleBuffer ) should provide it, no need to extend the discursion. There's more than one concept at play here: (1) If you consider the AudioSampleBuffer as a stand-alone entity, then it should carry it's own sample rate. Further, if the object is fully in control of its own buffer allocations then you can argue for all kind of extensions (e.g. zero-padding, power-of-two size, etc.). (2) On the other hand, if the system has a fixed sample rate, then the sample rate is a (global) property of the system, not of the buffers. By definition, all buffers have the same sample rate -- the system sample rate. Further, if the buffers are allocated externally (e.g. by a plug-in host) then the role of AudioSampleBuffer is purely a wrapper (smart pointer) and there is no way for it to provide a mechanism for zero-padding or any other buffer allocation related features. This discussion seems to be about whether AudioSampleBuffer is (1), (2), or both. There is no one-true-answer, but if the object is modeling (2), adding a field for sample rate not only violates the zero-overhead principle but also opens the door to violating a system invariant (i.e. that all buffers have the same sample rate). As far as I know, case (2) addresses the main use-case for JUCE. Personally, I think AudioSampleBuffer is (a) trying to do too much (there should be two objects: a Buffer and a BufferRef); and (b) it's abstraction overkill for the plug-in use-case. Cheers, Ross. ___ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
