<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span class="gmail-VIiyi" lang="en"><span class="gmail-JLqJ4b gmail-ChMk0b"><span>Ok, your idea is surely easier to implement, and the same is achieved.</span></span> <span class="gmail-JLqJ4b gmail-ChMk0b"><span>It occurs to me to make a schematic sheet of use. Would it be possible to add a "Help" button that opens a pdf file?</span></span><span class="gmail-JLqJ4b"><span>
</span></span><span class="gmail-JLqJ4b gmail-ChMk0b"><span>I could make this file in English (someone should correct it) and in Spanish and provide the file in case you want to translate into more languages, I'm talking about one or two pages at the most.</span></span><span class="gmail-JLqJ4b"><span>
</span></span><span class="gmail-JLqJ4b gmail-ChMk0b"><span>The dangerous button, from the moment it has a warning in case of overwriting, is no longer so.</span></span></span></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 20 ene 2021 a las 11:38, 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">В сообщении от Wednesday 20 January 2021 11:21:42 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):<br>
> Yes, I knew about this part of the manual, but I see it as a bug or an<br>
> error that the render takes into account the insertion point (position of<br>
> the playhead).<br>
<br>
My point was about setting SELECTION in those projects (possibly by creating<br>
10-20 copies of them with dangerous "Save to EDL path" function).<br>
<br>
So, you basically will have 20 little sub-project still around as a batchjob list.<br>
After you load this list you render those fragments ..<br>
Not as neat as your montage (idea) but I wonder if it works currently at all ?<br>
<br>
I mean I'm not very sure what selection will be if you say put THREE <br>
labels without any other indication of desired region ....<br>
<br>
But I think testing In-Out points or visual selection now is fastest route ...<br>
<br>
<br>
<br>
<br>
> <br>
> What I mean is an improvement that on the one hand solves the playhead.<br>
> That we do not have to make sure that this is at the beginning to make a<br>
> render, this is really a mistake (bug).<br>
> <br>
> And in a project to be able to define several non-consecutive sections in<br>
> the same batch render.<br>
> <br>
> The process would be.<br>
> 1 New<br>
> 2 Use current EDL<br>
> 3 (New button) (Set in out points) or (in out reference)<br>
> The fourth point would be to indicate the name and output format.<br>
> <br>
> This collects the time code information of the current position of the<br>
> entry exit points.<br>
> If we move these points to another section and repeat the three previous<br>
> steps, new, will always create a new line with ALL (project), this will<br>
> render the whole project, but if we have moved the marks in out, and press<br>
> the "in out reference" button again, ALL will be replaced by the stretch of<br>
> timecode marked by in out points and export only the fragment. When<br>
> executing it, Batch will export all the defined sections while we can be<br>
> having a snack.<br>
> <br>
> [image: Idea_2.png]<br>
> <br>
> <br>
> I am aware that giving ideas is the easy part of the job... if I had the<br>
> knowledge that you have in C programming it would help you, but in this<br>
> sense I am stupid and useless... I can only try, sorry. Don't feel<br>
> obligated to do this either. The only thing I see as an error is that the<br>
> render takes into account the the position of the play head (the Insert<br>
> Point position as the manual calls it)<br>
> <br>
> Imagine that you have to do a batch render of 20 projects... and you have<br>
> to open one by one to ensure that the playhead is at the beginning... it is<br>
> not very logical... a batch is made with the editor without any project<br>
> loaded, most of the time, and this detail of the play head wastes a lot of<br>
> time without any logic that justifies it, being able to use the entry and<br>
> exit points (in out points) for it<br>
> <br>
> My sincere thanks.<br>
> <br>
> El mié, 20 ene 2021 a las 7:46, Andrew Randrianasulu via Cin (<<br>
> <a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>>) escribió:<br>
> <br>
> > В сообщении от Wednesday 20 January 2021 09:38:26 Rafa Mar Multimedia en<br>
> > Gnu\Linux via Cin написал(а):<br>
> > > Thank you very much Andrew.<br>
> > > I think that initially it would be sufficient that the render will ignore<br>
> > > the position of the playhead.<br>
> ><br>
> ><br>
> > Currently, Batchrender operation described in pdf as such<br>
> ><br>
> > =====<br>
> ><br>
> > You do not have to render an entire projects. We can limit ourselves to an<br>
> > active<br>
> > region that we can set through a selection in Cut and Paste mode, with<br>
> > labels or<br>
> > In/Out Points. Or the rendering will start from the Insert Point position<br>
> > until the<br>
> > end of the project. Remember: if we want to render the entire project (and<br>
> > not<br>
> > just one active region) it is important to bring the Insertion Point to<br>
> > the beginning<br>
> > of the timeline. This is the only way we are sure to include the whole<br>
> > project.<br>
> ><br>
> > =====<br>
> ><br>
> > try to set 'i/o points' in those batches (before rendering) and see if it<br>
> > works for you already?<br>
> ><br>
> ><br>
> > > The rest ... I'm very sorry to give you so much work with this assistant.<br>
> > > But I'm going to see these changes and I'll tell you.<br>
> > ><br>
> > > El mié, 20 ene 2021 a las 6:49, Andrew Randrianasulu via Cin (<<br>
> > > <a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>>) escribió:<br>
> > ><br>
> > > > It still doesn't work, resize event missing, and probably I must do i/o<br>
> > > > points<br>
> > > > just like labels - per job?<br>
> > > ><br>
> > > ><br>
> > > > Also, interested parties can change BatchRenderJob::get_strategy<br>
> > > ><br>
> > > > for returning RANGE_PROJECT and not RANGE_SELECTION ...<br>
> > > ><br>
> > > > Not sure if we should make this GUI-configurable .....<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>
> > > ><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>
> ><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>