>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. >> >> My comments: I really like MOMENTARY and RANDOMISABLE. AUDIO_RATE_CONTROL >> could be useful, but might be painful for hosts to implement. I dont have >> any particular use for it right now. > >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. >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. --p
