[Cin] Debate on batch render

Andrew Randrianasulu randrianasulu at gmail.com
Fri Jan 15 07:11:43 CET 2021


В сообщении от Friday 15 January 2021 09:04:31 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):
> 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.
> Ugin if he had had this option of making incremental versions, without
> stepping on his original file, he would not have lost 4 jobs.
> We have to think about new users and not create unnecessary frustration.
> 
> 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 https://ladatstudios.com/ 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.

Well, I modified my patch is such way dangerous button newer show up by default
(as Phyllis suggested). So, it should be safer this way too?

You also can try to put xml project files under git source control .....

> 
> Greetings and forgive my extensive responses.
> 
> El vie, 15 ene 2021 a las 6:40, Andrew Randrianasulu via Cin (<
> cin at lists.cinelerra-gg.org>) escribió:
> 
> > В сообщении от Friday 15 January 2021 08:35:57 Rafa Mar Multimedia en
> > Gnu\Linux via Cin написал(а):
> > > *Phyllis, Andrew, Andrea Paz, Igor BEGHETTO, Ugin...*
> > > *IMPORTANT TO READ BECAUSE THIS COULD BE THE DEFINITIVE SOLUTION*
> > >
> > > Thinking about the render window issue I have come up with an option
> > that I
> > > think would be very easy to implement and would make the "Save to EDL
> > Path"
> > > button stop being dangerous and the window could be left with all the
> > > functions and buttons just as it was before starting this debate
> > >
> > > Let me explain, would it be possible that the option "Save to EDL Path"
> > if
> > > it is pressed with an xml file name that already exists on the disk does
> > > not alter this xml and what it does is a copy of it adding a number to
> > the
> > > file?
> > >
> > > For example:
> > > - I have "MyProject.xml" existing on the disk and I have this EDL loaded
> > in
> > > the EDL Path box:
> > > - If I change the name, for example "MyNewProject.xml" before pressing
> > the
> > > "Save to EDL Path" option, the wizard, as it does now, will create a new
> > > xml file with this name because this file does not exist yet in the disk
> > > and is created from 0.
> > > - If I don't change the name and the file already exists, what Cinelerra
> > > will do is never overwrite the existing xml information, but create a new
> > > xml with a number added to its name.
> > > - For example, I have "MyProject.xml" existing on disk and I press "Save
> > to
> > > EDL Path" Cinelerra, what in this case it will create a copy with a
> > number
> > > at the end, creating a new xml called "MyProject_001.xml"
> >
> >
> > But doesn't this negate some aspects of quick workflow made possible  by
> > this behavior?
> >
> >
> >
> > >
> > > In this way, this button is no longer a dangerous button and Igor_ubuntu
> > > will be able to continue working in his personal way, creating as many
> > > versions as he wants of his projects from the render window, and he will
> > > even benefit from this new working mode of the option "Save to EDL Path"
> > in
> > > case you have not been careful to change the name and click it
> > > accidentally, this will not destroy your work, it will just create a new
> > > xml, which is always a better option than destroying a job.
> > >
> > > And the other issue is that the option "warn if jobs/session mismatched"
> > > simply comes deactivated by default, as my friend has left, if it is
> > > activated it will remain active until the application is closed. Without
> > > Cinelerra remembering its last state and always starting off. So in this
> > > way if someone does tests and then wants to render from the terminal they
> > > do not have the problem of the error of the EDL sessions that do not
> > match.
> > >
> > > I think that the render window remains the same as GoodGuy left it with
> > the
> > > improvement that it will never destroy an existing xml file on disk.
> > >
> > > El jue, 14 ene 2021 a las 11:08, Rafa Mar Multimedia en Gnu\Linux (<
> > > rafamar.mm.ig at gmail.com>) escribió:
> > >
> > > > hahahahaha the budget only gives for a bay leaf :-)
> > > > Sincerely Rafa Mar
> > > >
> > > > El jue, 14 ene 2021 a las 10:35, Igor BEGHETTO via Cin (<
> > > > cin at lists.cinelerra-gg.org>) escribió:
> > > >
> > > >> Yeah! I am The Winner!
> > > >> Where is my cup? I want a gold metal cup, not a plastic cup!
> > > >> Mah! (italian expression of disappointment)
> > > >>
> > > >> IgorBeg
> > > >>
> > > >>
> > > >> Il 13/01/2021 17:37, Rafa Mar Multimedia en Gnu\Linux via Cin ha
> > scritto:
> > > >> > I vote blank, so for the moment Igor wins.
> > > >> --
> > > >> Cin mailing list
> > > >> Cin at lists.cinelerra-gg.org
> > > >> https://lists.cinelerra-gg.org/mailman/listinfo/cin
> > > >>
> > > >
> > >
> >
> >
> > --
> > Cin mailing list
> > Cin at lists.cinelerra-gg.org
> > https://lists.cinelerra-gg.org/mailman/listinfo/cin
> >
> 




More information about the Cin mailing list