On Thu, 16 Jan 2003 10:58:40 -0500 Paul Davis <[EMAIL PROTECTED]> wrote:
> >On Wed, 15 Jan 2003 18:13:35 +0000 > >Steve Harris <[EMAIL PROTECTED]> wrote: > > > >> AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled > >> by a high time res. slider or control data, but shouldn't be connected to > >> the next audio signal by default. I can't think of any simple examples off > >> hand, but combined with MOMENTARY it could be used for sample accurate > >> tempo tapping. > >> > > > >Not to mention that AUDIO_RATE_CONTROL would completely useless in JACK? > >You'd have a buffer-full of samples and apply frequency shift to them, which w > >ould change the length of that buffer, which you couldn't give to JACK unless > >you do some rebuffering. > > this is true of *any* output paradigm. the audio interface only > accepts N frames per second. if you had N frames to deliver in one > second, then stretched them to N*2 frames, it will necessarily take > you twice as long to deliver them - the interface isn't going to speed > up for you. Yes, but then, if you are also having input from realtime-type interface the buffer must be of fixed size. > >Correct me if I'm wrong. We have similar issue with ecasound's Pitch Shifter > >operator in connection with JACK. > > steve has written LADSPA pitch shifters and they work just fine with > the fixed-sized buffer paradigm. Yep, I was just intrigued with the tempo tapping, which cannot be achieved when in and out are realtime. (like jack-rack) Or then I maybe misunderstood the term. janne
