<div dir="ltr">Andrew, safety comes first before speed. If working fast can lead to the destruction of my work, I prefer to go slow, if there is a guarantee that I will be able to work fast without the danger of losing my job, then welcome is this option that allows you to work fast.<br>Ugin if he had had this option of making incremental versions, without stepping on his original file, he would not have lost 4 jobs.<br>We have to think about new users and not create unnecessary frustration.<br><br>If Cinelerra GG intends to be an editor for adventurers and kamikazes who like the risk of losing their job, I will have to remove it from the open source and free applications of the center <a href="https://ladatstudios.com/">https://ladatstudios.com/</a> where I collaborate as an audiovisual teacher, as I did in 2019 with Kdenlive. It is not a threat, in my role as a teacher I always have to think of the best for my students, in my role as a free applications blogger I have to think of the best for my readers and the possibility of losing a job for trying to do a batch Render is not a good option for anyone.<br><br>Greetings and forgive my extensive responses.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie, 15 ene 2021 a las 6:40, Andrew Randrianasulu via Cin (<<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">В сообщении от Friday 15 January 2021 08:35:57 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):<br>
> *Phyllis, Andrew, Andrea Paz, Igor BEGHETTO, Ugin...*<br>
> *IMPORTANT TO READ BECAUSE THIS COULD BE THE DEFINITIVE SOLUTION*<br>
> <br>
> Thinking about the render window issue I have come up with an option that I<br>
> think would be very easy to implement and would make the "Save to EDL Path"<br>
> button stop being dangerous and the window could be left with all the<br>
> functions and buttons just as it was before starting this debate<br>
> <br>
> Let me explain, would it be possible that the option "Save to EDL Path" if<br>
> it is pressed with an xml file name that already exists on the disk does<br>
> not alter this xml and what it does is a copy of it adding a number to the<br>
> file?<br>
> <br>
> For example:<br>
> - I have "MyProject.xml" existing on the disk and I have this EDL loaded in<br>
> the EDL Path box:<br>
> - If I change the name, for example "MyNewProject.xml" before pressing the<br>
> "Save to EDL Path" option, the wizard, as it does now, will create a new<br>
> xml file with this name because this file does not exist yet in the disk<br>
> and is created from 0.<br>
> - If I don't change the name and the file already exists, what Cinelerra<br>
> will do is never overwrite the existing xml information, but create a new<br>
> xml with a number added to its name.<br>
> - For example, I have "MyProject.xml" existing on disk and I press "Save to<br>
> EDL Path" Cinelerra, what in this case it will create a copy with a number<br>
> at the end, creating a new xml called "MyProject_001.xml"<br>
<br>
<br>
But doesn't this negate some aspects of quick workflow made possible  by this behavior?<br>
<br>
<br>
<br>
> <br>
> In this way, this button is no longer a dangerous button and Igor_ubuntu<br>
> will be able to continue working in his personal way, creating as many<br>
> versions as he wants of his projects from the render window, and he will<br>
> even benefit from this new working mode of the option "Save to EDL Path" in<br>
> case you have not been careful to change the name and click it<br>
> accidentally, this will not destroy your work, it will just create a new<br>
> xml, which is always a better option than destroying a job.<br>
> <br>
> And the other issue is that the option "warn if jobs/session mismatched"<br>
> simply comes deactivated by default, as my friend has left, if it is<br>
> activated it will remain active until the application is closed. Without<br>
> Cinelerra remembering its last state and always starting off. So in this<br>
> way if someone does tests and then wants to render from the terminal they<br>
> do not have the problem of the error of the EDL sessions that do not match.<br>
> <br>
> I think that the render window remains the same as GoodGuy left it with the<br>
> improvement that it will never destroy an existing xml file on disk.<br>
> <br>
> El jue, 14 ene 2021 a las 11:08, Rafa Mar Multimedia en Gnu\Linux (<<br>
> <a href="mailto:rafamar.mm.ig@gmail.com" target="_blank">rafamar.mm.ig@gmail.com</a>>) escribió:<br>
> <br>
> > hahahahaha the budget only gives for a bay leaf :-)<br>
> > Sincerely Rafa Mar<br>
> ><br>
> > El jue, 14 ene 2021 a las 10:35, Igor BEGHETTO via Cin (<<br>
> > <a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>>) escribió:<br>
> ><br>
> >> Yeah! I am The Winner!<br>
> >> Where is my cup? I want a gold metal cup, not a plastic cup!<br>
> >> Mah! (italian expression of disappointment)<br>
> >><br>
> >> IgorBeg<br>
> >><br>
> >><br>
> >> Il 13/01/2021 17:37, Rafa Mar Multimedia en Gnu\Linux via Cin ha scritto:<br>
> >> > I vote blank, so for the moment Igor wins.<br>
> >> --<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>
> >><br>
> ><br>
> <br>
<br>
<br>
-- <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>