Re: [Audacity-devel] Sample-level time accuracy

[Martyn S. <mar...@gm...>]

Hi there

On 24/09/2010 23:04, Vaughan Johnson wrote:
> On 9/22/2010 5:48 PM, Martyn Shaw wrote:

<snip>

>> and I see that it's WaveClips that actually have an offset, so I
>> figure that I'll fix it there only.
>
> Yes, I think that's right.

That's still my conclusion, although I have a nagging doubt.  I'm no 
longer convinced that the last change I made to WaveClip.cpp (r10691) 
  is 'correct' and don't intend on making further changes until I 
figure that out.

And I've happened across (again) related problems in Envelope (which 
has been an ongoing issue for years IIRC, but I may now have a handle on).

> Also, I took a bit closer look at your original list in this thread of
> WaveTrack and WaveClip methods that probably need changing. I think
> you'll run into lots of cases similar to WaveTrack::SetOffset() and
> WaveClip::SetOffset(), where many do not need to have the QUANTIZED_TIME
> change, as the real work is done at a lower level. For example,
> WaveTrack::Cut() just calls WaveTrack::Copy() and WaveTrack::Clear()
> (which just calls WaveTrack::HandleClear()), and so the changes need to
> be in WaveTrack::Copy() and WaveTrack::HandleClear(), not in
> WaveTrack::Cut(). Of course, those workhorses are the more complicated
> methods to fix!

This is true, and I meant that I would drill down into those methods 
to find where QUANTIZED_TIME should be used, and where it isn't needed 
(which may be most of them in WT, as you say).

>> What should we do with overlapping waveclips in an aup???  Easily
>> possible to create with Audacity and a text editor (just set the
>> <waveclip offset=" to overlapping values),
>
> I question whether we should support such perversion. AUP files should
> be written by Audacity, not text editors. :-)

true but...

>> and probably 'out there' in
>> legacy files.  We draw them OK, but possibly fail elsewhere.
>>
>
> I think legacy files have no notion of clips.

By 'legacy' I meant 'any AUP files written by any previous versions 
(including betas)'.  We have allowed "random" <waveclip offset="x.xx"> 
things in AUPs before, we shouldn't fail to give an acceptable result 
(or at least not a project that will crash) on reading them in the 
future.  I have 'belief' but not 'proof' (I haven't tried) that 
earlier versions could create a series of clips that don't fit into 
the time available for true (sample accurate) non-overlapping clips. 
For example:
Clip 1: 2 samples, offset 0.
Clip 2: 2 samples, offset 1.5 samples
Clip 3: 2 samples, offset 3 samples
or something like that, I don't know.  Maybe I'll try and create that 
without r10691.

> Dominic, have you been following this thread? As the original architect,
> I think he might have valuable input on this whole thread, so if he
> doesn't respond here, Martyn, I recommend summarizing it and emailing
> him directly. Maybe Markus, too, as he did the adaptation to clips. That
> applies to your question in the "r10691 committed" email about why
> mOffset (of a Clip) is a double, not a sampleCount. I think your
> reasoning on all this is right, but there may be something I'm missing.

I want to do that but can't, at present, formulate a sensible summary 
/ question.

TTFN
Martyn

> - Vaughan
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel