[Ardour-Dev] [PATCH] Punch IN/OUT horribly broken

[Sylvain HENRY]

Hi again,

I think that I have solved the bug 1928: http://tracker.ardour.org/view.php?id=1928. See the attached file.
However I would have liked that someone confirm that I'm not making a mistake because I'm not really sure of it.

To figure out what was going on, I used printf before "coverage" function call in libs/ardour/audio_diskstream.cc.
I've done the same kind of thing that on the video linked in the bug report. I got:

{First recording with punch in/out}
...
coverage(r_s -1, r_e -1, t_s 341009, t_e 342033) =>  0
coverage(r_s -1, r_e -1, t_s 342033, t_e 343014) =>  0
coverage(r_s 343014, r_e -1, t_s 343014, t_e 343057) =>  2
coverage(r_s 343014, r_e -1, t_s 343057, t_e 344081) =>  1
coverage(r_s 343014, r_e -1, t_s 344081, t_e 345105) =>  1
...
coverage(r_s 343014, r_e -1, t_s 361489, t_e 362513) =>  1
coverage(r_s 343014, r_e -1, t_s 362513, t_e 363266) =>  1
coverage(r_s 343014, r_e 363266, t_s 363266, t_e 363537) =>  3
finish_capture
coverage(r_s 343014, r_e 363266, t_s 363537, t_e 364561) =>  0
coverage(r_s 343014, r_e 363266, t_s 364561, t_e 365585) =>  0
...


{Second recording with another punch in/out region after the first one, playback set before the first recorded region}
coverage(r_s 343014, r_e -1, t_s 340042, t_e 341066) =>  0
coverage(r_s 343014, r_e -1, t_s 341066, t_e 342090) =>  0
coverage(r_s 343014, r_e -1, t_s 342090, t_e 343114) =>  2   <= PROBLEM
coverage(r_s 343014, r_e -1, t_s 343114, t_e 344138) =>  1
coverage(r_s 343014, r_e -1, t_s 344138, t_e 345162) =>  1
... {playing the first recorded region}
coverage(r_s 343014, r_e -1, t_s 361546, t_e 362570) =>  1
coverage(r_s 343014, r_e -1, t_s 362570, t_e 363594) =>  1
coverage(r_s 343014, r_e -1, t_s 363594, t_e 364618) =>  1
... {end of the first region}
coverage(r_s 343014, r_e -1, t_s 433226, t_e 434250) =>  1
coverage(r_s 343014, r_e -1, t_s 434250, t_e 435274) =>  1
...
{beginning of the recording region}
coverage(r_s 436678, r_e -1, t_s 436678, t_e 437322) =>  2
coverage(r_s 436678, r_e -1, t_s 437322, t_e 438346) =>  1
coverage(r_s 436678, r_e -1, t_s 438346, t_e 439370) =>  1
...
coverage(r_s 436678, r_e -1, t_s 465994, t_e 467018) =>  1
coverage(r_s 436678, r_e -1, t_s 467018, t_e 467056) =>  1
coverage(r_s 436678, r_e 467056, t_s 467056, t_e 468042) =>  3
coverage(r_s 436678, r_e 467056, t_s 468042, t_e 469066) =>  0
coverage(r_s 436678, r_e 467056, t_s 469066, t_e 470090) =>  0
...

r_s = first_recordable_frame
r_e = last_recordable_frame
t_s = transport_frame
t_e = transport_frame + nframes

From what I have guessed, the problem is that the beginning of the first region (while the second recording) should not lead coverage to return 2.
I solved this by resetting first_recordable_frame to -1 after coverage => 3. I don't know if it was the right thing to do, but it seems to work.

I hope this will get ride of this really really annoying bug!

Sorry for the long post,

Regards
Sylvain




      _____________________________________________________________________________ 
Envoyez avec Yahoo! Mail. Capacité de stockage illimitée pour vos emails. http://mail.yahoo.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hsyl20_punch_audio_diskstream.patch
Type: application/octet-stream
Size: 395 bytes
Desc: not available
URL: <http://lists.ardour.org/pipermail/ardour-dev-ardour.org/attachments/20080324/f3b995de/attachment-0002.obj>