<div dir="ltr"><div><div><div><div><div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Double clicking is good, but to be sure to have the speed handles at<br>
the same speed ("height") on every track I had to:<br></div></blockquote><div><br></div><div>Good observation!  I had not noticed that.</div><div><br></div>As I was trying to reproduce the problem, I picked media that was over 3hrs long.<br></div>This leads to the following horrible discovery.  There is a design bug in the speed auto.</div><div><br></div>The problem occurs when you pick an speed auto position that is far from the beginning.<br></div>Since the video was 3hrs, i casually picked a point near 1.5hrs, near the middle of the</div><div>video edit.  This causes the code in amodule.C to calculate the exact sample time <br></div><div>for 1.5hrs in by integrating time, that is to say adding up all of the discrete sample times,</div><div>up to the speed auto position.  This is:</div><div> 48000samples/sec*3600sec/hr*1.5hrs = 259200000.</div><div>To get the time derivative, it has to evaluate the speed auto at every instance..</div><div>that takes forever... maybe even longer.</div><div><br></div><div>The  upshot of all of this blather is that the speed auto can only be used effectively</div><div>on short edits...  possibly only a few minutes of media.</div><div><br></div><div>It may be possible to upgrade the program to calculate the speed</div><div>positions using direct math forms, but that is complicated.  Another plan is to not</div><div>recalculate the time integral if play is continuous, but that has problems too.</div><div> <br></div>Thank you for such insight on the speed auto update parameters.  This is obviously</div><div>not well tested.  You are probably the first one to put it to use on real cases.  I have</div><div>tried it in the past, but only on small test cases that seemed to work just fine.</div><div><br></div><div>gg/phylliis</div><div><br></div><div>PS: Phyllis says she will try to put some documentation updates into features5 to</div><div>describe the problems and recommendations.</div><div><br></div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 7, 2017 at 3:32 PM, Frederic Roenitz <span dir="ltr"><<a href="mailto:ml1@aimvis.de" target="_blank">ml1@aimvis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> What am I doing wrong?<br>
<br>
... the trick was to be 'ultra careful' instead of only 'very<br>
careful'.<br>
<br>
I just rechecked what I rererererechecked before writing my previous<br>
mail.<br>
<br>
Double clicking is good, but to be sure to have the speed handles at<br>
the same speed ("height") on every track I had to:<br>
<br>
- double click the video handle (not one of the audio handles: video<br>
  speed handles can only be placed between two frames, whereas audio<br>
  speed handles can be placed 'everywhere' (probably on every audio<br>
  sample)).<br>
<br>
- hold the mouse button<br>
<br>
 - move the handles to the upper boundary<br>
 - move the handles to the lower boundary<br>
<br>
 or respectively<br>
<br>
 - move the handles to the lower boundary<br>
 - move the handles to the upper boundary<br>
<br>
- place the handles<br>
<br>
- release the mouse button<br>
<br>
<br>
This is maybe something for Feature5.<br>
<br>
<br>
By the way: Alt- and Shift-keys are also helpful while dragging a<br>
handle.<br>
<br>
<br>
Kind greetings<br>
<br>
Frederic<br>
______________________________<wbr>_________________<br>
Cinelerra mailing list<br>
<a href="mailto:Cinelerra@lists.cinelerra-cv.org" target="_blank">Cinelerra@lists.cinelerra-cv.o<wbr>rg</a><br>
<a href="http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra" rel="noreferrer" target="_blank">http://lists.cinelerra-cv.org/<wbr>cgi-bin/mailman/listinfo/cinel<wbr>erra</a><br>
</blockquote></div><br></div>