Re: [LAD] interesting blog post about syncing blender and ardour

On Fri, Sep 25, 2009 at 1:18 PM, Fons Adriaensen <fons@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Sep 26 00:15:05 2009