<div dir="ltr"><div class="gmail_default" style="font-size:small">OK, checked into GIT, the export edl patches for CMX3600 generation.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Andrea, if you have time, could you rebuild just to make sure everything compiles OK for you (and maybe try to load into another NLE to see if you have more success or if we just do not know how to do it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Andrew, you should check my work because there were a lot of patches and then patches to the patches, and I am easily confused.  So in the end, I believe I got it right.  Here is what I ended up doing:  <br></div><div class="gmail_default" style="font-size:small">(1) added exportedl.c.patch, <br></div><div class="gmail_default" style="font-size:small">(2) ignored 0001-..., 0004, 0005, 0006 exportedl patches in this thread, <br></div><div class="gmail_default" style="font-size:small">(3) applied patches 0035-..., 0036, 0037, 0038, 0042, 0043. <br></div><div class="gmail_default" style="font-size:small">(4) Recompiled and tested cinelerra with a bunch of cuts and moving sections around to generate an Export EDL file.  <br></div><div class="gmail_default" style="font-size:small">(5) Manually looked at the generated CMX3660 video file and saw that it "seemed" to look comparable to explanations in:</div><div class="gmail_default" style="font-size:small">   <a href="https://xmil.biz/EDL-X/CMX3600.pdf">https://xmil.biz/EDL-X/CMX3600.pdf</a> <br></div><div class="gmail_default" style="font-size:small">pages 11-14</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Also, applied Andrew's patch (for high fps) to pluginfclient.C to match the other changes in ffmpeg.C.  Like I mentioned previously, I have not tested nor know how to test.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Andrew, I found the Android tablet (that has not been powered on for 3-4 years!) and am moving on to checking out Termux.  At least I hope I can.  Thanks for all the work you do to keep Cinelerra going. ...Phyllis<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 5, 2021 at 11:30 AM Andrew Randrianasulu via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Updated patches, this time I tried to import resulting edl into Final Cut Pro for PPC Mac (mac os 9.2.2 on qemu/andoid 0.o) and they worked at least cuts show up, and dissolves (there currently no code for handling wipes) <div><br></div><div>I am not sure if ^z^z tail actually harmless, you can comment writing this tail in patches if unsure/want to test different NLE</div><div><br></div><div>yeah, I missed newline after FCM line, and last line in file.. </div><div><br></div><div>for my surprize FCP 1.2.5 (from 1999!) uses Windows line endings (seen as ^M in mcedit) - may be they were re-using dos/windows code there? </div><div><br></div><div>I simply run 'unix2dos -f' on edl file from patched CinGG and then optionally set Document/creator attribs (mac-specific, under Macos 7.5.5 in Basilisk2 emulator, with ResEdit app) to TEXT/KeyG (four symbols for each, case-sensitive! ) - this allowed FCP to see my edl correctly, but you can select 'show all files' in import->edl menu under 'file' menu item.. </div><div><br></div><div><br></div><div><br><br>On Monday, June 21, 2021, Andrew Randrianasulu <<a href="mailto:randrianasulu@gmail.com" target="_blank">randrianasulu@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think I enabled _writing_ timecode info into rendered files (tested mxf)<div>if you set timecode for your timeline manually - it should be respected. </div><div>If you render selection of your timeline  - timecode will be set at start timecode of your render position. </div><div>if you render selection with already altered (via clapping icon) timeline - it also should work. </div><div><br></div><div>I found you (sometimes?) need to hit 'align timecodes' menu item for refreshing asset timecode info.... but such action will mes up timeline if some assets had no real timecode info.... </div><div><br></div><div>Anyway, try to test those patches and told us how useful (or dangerous?) they are... </div><div><br></div><div>In theory I think this is good idea to get embedded timecodes into rendered files (rel. to your working timeline) , but may be you sometimes want zeroed tc in output files? </div><div><br></div><div><br></div>
</blockquote></div>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>