From: Florian J. <flo...@we...> - 2013-01-02 16:12:08
|
Am 01.01.2013 23:30, schrieb Tim E. Real: > > Be aware that once audio files enter the picture, tempo is kind of > 'written in stone' - if tempo is changed the audio files do NOT > stretch in time to accommodate and will be out of sync with midi. > Time-stretching is something I've been trying to add for a long time now > with my AudioConverter class. > > Also Florian said the other day he wants to do something similar using a > handy available library and 'tapping' the tempo. Hi Tim, please tell me more about this AudioConverter class, your efforts to do this, and the current state of it. My concept would be as follows: Wave parts can have either manual tapping info (in case of varying tempo of the imported wave file) or automatic tempo detection (which basically does auto-correlation, and then adds the "tapping info" automatically and equi-spaced) Wave parts have a "source wave" buffer (which is the only wave buffer they have ATM) new: Wave parts have a "new wave" buffer (which holds the tempo-stretched data, or points just to the source wave buffer) All audio-read operations read from the new-wave pointer All audio-write operations are denied if stretching is activated. Stretching automagically updates the new-wave-buffer if you change the tempo, to get the file in sync again. Stretching is NOT done in real time, but is rather pre-calculated. This would nicely tie in with my prerecording feature: That feature would just add even more buffers (a whole stack of buffers), plus a nifty memory management which transparently swaps stuff onto the disk, calculates in-place or just gives you the RAM-buffer. What was your concept with the AudioConverter? greetings flo |