On 02/17/2012 12:14 PM, jb wrote:
> On Friday 17 February 2012 11:23:19 Simon A. Eugster wrote:
>> On 02/16/2012 09:27 PM, jb wrote:
>>> Forgot to say that I committed a patch to the AudioAlign branch so that
>>> Kdenlive now displays an error instead of moving the clip in the first
>>> There are probably other placed in Kdenlive where the "playlist.insert_at"
>>> return value is not checked, will keep that on my todo list.
>> Thanks a lot! This works now. But I have another problem:
>> 1. Add d7000.wav on track 1
>> 2. Add h4n.wav on track 1 too, to the right of d7000.wav, and set it as
>> 3. Auto-align d7000.wav, this should give an error imho but does not
>> 4. Move d7000.wav to track 2 -> undo stack corrupted
> We did not check if the region was empty in MLT before moving the clip. If I
> remember correctly, in most places in Kdenlive we first check if the clip can
> be moved using the GraphicsView coordinates (check that no other clip overlap)
> and the make the move in MLT playlist without further verification.
> So in your case, the move was first made in MLT but then failed in Kdenlive
> (because of overlapping clips).
> So I guess this is where a refactoring would help, because currently we have
> the Kdenlive timeline graphics view AND the MLT playlist, and sometimes those
> 2 can lose syncro in these situations.
I also had this idea. A model/view based approach would be very helpful
so we could also add new views (like the thumbnail based view that
displays all clips in the same length). And we could start unit testing
the new classes :)
> I think your problem should be fixed by my last commit to the audioAlign
> branch where I now also check in MLT that the region where we move the clip is
Yes, thank you! I'll try to add FFT based alignment now to get O(n log
n) instead of O(n²) multiplications.