On Fri, Sep 25, 2009 at 1:18 PM, Fons Adriaensen <[email protected]> wrote:
> None of this would be produced by linear interpolation. not my code :) talk to steve harris if you wish, otherwise check in with hans baier and ask him about the work he has done on interpolation models in 3.X, since he may have a deeper understanding of what the 2.X code is doing. > >> in 3.X, there are some choices about what type of interpolation to >> use. the underlying assumption here is that if the user wants ardour >> to varispeed (and note that the same code is used for >> scrubbing/shuttling too), then they do not care *much* about quality. >> this is not "sample rate conversion" in the traditional sense - its >> "resample so that we can stay in sync". > > Still, there's no point in using any DAW if the result is not > recorded somehow and used later. So quality does matter. eh? lots of people are using ardour as a playback engine driven by timecode, with no intention of recording the output. when you're editing and scrubbing/shuttling, i would have imagined that in the vast majority of cases you would *not* be recording what you are doing. what am i missing? >> If a signal is recorded >> > with some speed error, and then played back with the same >> > speed error the result should be the original signal. Since >> > it will be resampled on playback it has to be resampled on >> > record as well, in the opposite direction. >> >> sure. however, i have no great interest in implementing this because >> from my perspective, the "errors" that occur when the timecode source >> is not sample clock synced are generally *not* repeatable, and thus >> attempting to support this would actually not accomplish the goal. > > It would. Even if the record/playback errors are not the same, the > expected result depends on their ratio, even if that ratio is not > unity or constant. we must be thinking of a different use case. the code i wrote to do varispeed-sync-tracking was designed to handle a "wobbly" timecode source such as an ADAT tape machine. its timecode speed is not constant but suffers from very small motor-induced variation. from the experiments i did, that variation is essentially random, and if you played the same material twice, it would be subject to two different sets of timecode variations. i cannot see how encoding the varispeed into the on-disk material is useful in this case. are you talking about something different? > Ciao, > > -- > FA > > Io lo dico sempre: l'Italia รจ troppo stretta e lunga. > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
