Andrew, Thanks for looking at this. After I finish testing SGE's BT #538 html improvements, I will at least try your suggestions and I plan to update the manual to clarify simple usage of Batch Render. Right now I can only suggest you to look at

https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra...

... basically try to comment out action:

// thread->update_selected_edl();

put two "/" before this line, and recompile.

... May be it has something to do with internal use of batch render, for DVD/BD creation ?

YES !! I think I remember that it was implemented to facilitate DVD/BD

creation because there was much debugging involved that was tedious. There are *about 250,000 lines of intertwined program code* in Cinelerra-GG proper and rewriting code is not like rewriting a book's paragraph - it is generally non-trivial and requires more than just knowledge of C++.

I recommend reading Igor_ubuntu's post because, as always, it's clear and informative (Andrew: thanks for sharing!). Also the idea of moving and hiding dangerous buttons is great. (the Russian --> Italian translation made with DeepL works very well).

After reading Igor_Ubuntu's extensive article, I still think that a batch render window should be as simple and intuitive as possible a wizard. This is what an audiovisual technician expects to find in such an assistant. In fact, the audiovisual technicians and artists of the union flee from unnecessary complications and especially from assistants without any logic that can even ruin our work. A batch render window has to be explained with just two lines, we are NOT trying to pilot a Boeing 747, we are only trying to do a batch render. Igor to justify the button "Save to EDL Path" has had to write an extensive article ... and it turns out that when an audiovisual technician wants to test different color settings of a project, for example, he will make several .xml versions with the Save as option, which is what this option is for. Something is NOT being done well if for a simple task a long and confusing article is needed to explain the operation of options without sense or work logic in the audiovisual environment. I honestly would not ask any programmer to spend a second of their precious time making hidden and advanced menus of some functions that nobody is going to use, I would simply eliminate the two options mentioned, "Save to EDL Path" and "Warn if jobs/session mismatchet "because no one expects a render window to make changes to the project, beyond the render settings, and what no one expects and wants is a render window that can destroy your work. So I insist, do not waste time beyond removing the functions without any logic or utility and dedicate the time to do more necessary and fruitful things in Cinelerra GG. It is only a recommendation, it is not up to me to decide what should or should not be done in Cinelerra GG. El dom, 10 ene 2021 a las 2:39, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

I added few tooltips based on suggestions from this article, see patch

...

The added tooltips are helpful and probably we should add more so did not check into GIT yet. But I might have to fix the following one (smiley face!)

...

+ set_tooltip(_("Save to loaded EDL (highlighted), will *overwrite* *nighlighted *proj!"));

But apparently 'warn if proj/session mismatch' doesn't work as intended, I'll try to look into it but no promise of solution.

I also slightly updated russian translation because long russian sentence about # of CPU used by plugins was stomping away text in Use HW acceleration dropdown list! .. You might apply it anyway,

Yes, I will apply.

I think some more ru translation work will be needed due to all those

...

added strings (a bit afraid to do it due to possibility of breackage - but there is no other way!)

I agree, have to keep moving forward despite potential errors. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

At no point did I say that the batch rendering function should be removed. It was precisely Ugin's query that made me take a look at the Batch Render wizard. The only thing I have indicated is that this assistant has two functions that do not make any sense. 1 Save to EDL Path can destroy your work 2 Warn if jobs/session mismatchet causes an error, and this function is linked to the first one. What Igor explained in his article in Russian is absurd and very dangerous, both professionals and amateurs when they want to make different versions of a project do not go to the Batch Render window, but simply make several versions with save as. I can't imagine any hobbyist, much less a professional using an application that puts their work at risk. I remember that it is only a recommendation to improve and make a useful, logical tool that does not create problems, and above all that it works and not with meaningless options that cause errors like the "x job EDLs do not match session edl" bug. Greetings Rafa. El dom, 10 ene 2021 a las 16:57, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

*Batch Render is more of an "advanced feature"* and I suspect the casual user will never use it, but it is there for those who need it. A recent example being Ugin who needed it and from what he said in his email, he got it working for him right away without any real problem.

There are quite a few features in CinelerraGG that most people will never use. For example, *Render Farm is 12 pages* in the manual and only someone with more in depth knowledge will ever use it.. The *Title plugin is 10 pages* long but most people can use it without having to read and understand all 10 pages, but still there are questions about all of the time.

So we need to *make Batch Render seem more usable *without having to read only 5 pages AND without removing key features that were added, not for fun, but for necessity. ...Phyllis

On Sat, Jan 9, 2021 at 10:29 PM Rafa Mar Multimedia en Gnu\Linux via Cin < cin@lists.cinelerra-gg.org> wrote:

...

After reading Igor_Ubuntu's extensive article, I still think that a batch render window should be as simple and intuitive as possible a wizard. This is what an audiovisual technician expects to find in such an assistant. In fact, the audiovisual technicians and artists of the union flee from unnecessary complications and especially from assistants without any logic that can even ruin our work.

A batch render window has to be explained with just two lines, we are NOT trying to pilot a Boeing 747, we are only trying to do a batch render. Igor to justify the button "Save to EDL Path" has had to write an extensive article ... and it turns out that when an audiovisual technician wants to test different color settings of a project, for example, he will make several .xml versions with the Save as option, which is what this option is for.

Something is NOT being done well if for a simple task a long and confusing article is needed to explain the operation of options without sense or work logic in the audiovisual environment.

I honestly would not ask any programmer to spend a second of their precious time making hidden and advanced menus of some functions that nobody is going to use, I would simply eliminate the two options mentioned, "Save to EDL Path" and "Warn if jobs/session mismatchet "because no one expects a render window to make changes to the project, beyond the render settings, and what no one expects and wants is a render window that can destroy your work. So I insist, do not waste time beyond removing the functions without any logic or utility and dedicate the time to do more necessary and fruitful things in Cinelerra GG.

It is only a recommendation, it is not up to me to decide what should or should not be done in Cinelerra GG.

El dom, 10 ene 2021 a las 2:39, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

I added few tooltips based on suggestions from this article, see patch

...

The added tooltips are helpful and probably we should add more so did not check into GIT yet. But I might have to fix the following one (smiley face!)

...

+ set_tooltip(_("Save to loaded EDL (highlighted), will *overwrite* *nighlighted *proj!"));

But apparently 'warn if proj/session mismatch' doesn't work as intended, I'll try to look into it but no promise of solution.

I also slightly updated russian translation because long russian sentence about # of CPU used by plugins was stomping away text in Use HW acceleration dropdown list! .. You might apply it anyway,

Yes, I will apply.

I think some more ru translation work will be needed due to all those

...

added strings (a bit afraid to do it due to possibility of breackage - but there is no other way!)

I agree, have to keep moving forward despite potential errors. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Thank you very much Ugin for commenting on your experience... I had never looked at Cinelerra's batch render window. I go looking at tools, I test them, and then I try to write a tutorial on it to help hobbyists looking for a good tool. And your query caught my attention and I decided to take a look at the batch render assistant... the first thing I saw about this wizard is that it is not very intuitive, and the second my blood ran cold when I saw that it had a function that could destroy an entire project with a single click, and then another option that is linked to the aforementioned function, which is also misleading. I totally agree with you that these options without any practical sense, as much as Igor tries to convince us otherwise, that they can frustrate the user experience. Nobody likes to lose their job. And I find it difficult to recommend an editor that in a click given by mistake, this happens to us every day when we work with computers, lose all their work without going back. And I'm sorry to repeat myself, but when a professional needs two versions of the same project to do tests, he does not go to the batch render window to play his project, he simply makes a save as and that's it, and then loads these files in the batch render. I always say what I think, this creates enemies, and I am delighted with this, because normally these enemies are very egocentric people who cling to their ego without attending to reasons, and I am not like that, if I am wrong and they tell me, I even give thanks, and it's people like that that I like to surround myself with. If Igor is wrong with the fact that his working method is not practical and he likes to have an application that a wrong click can make you lose your job, which can be an hour or months... well there he, but I take the right to politely tell you that your proposal lacks all logic and is impractical or labor-saving, on the contrary, makes the batch render wizard a tool to avoid. Sorry for my long expositions, maybe I shouldn't write more about this topic because I have already said what I think many times. El lun, 11 ene 2021 a las 13:30, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

Since I was mentioned in this thread, I will say that during the batch rendering tests, 4 files were deleted from me. Then I did not know the reasons for deleting them, and before experiments I always try to make backups, but for someone this behavior can ruin the whole wonderful impression of Cinelerra-GG. -- Ugin.

10.01.2021 21:10, Rafa Mar Multimedia en Gnu\Linux via Cin пишет:

...

At no point did I say that the batch rendering function should be removed. It was precisely Ugin's query that made me take a look at the Batch Render wizard. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Thank you very much Ugin for being honest. I find it a real shame that Cinelerra has these shadows that can disenchant users. Nobody likes losing their job. Just today I find an email from a blog reader. Cinelerra was suddenly closed, it "hung", as we say in computer jargon and when trying to recover his work he mistakenly gave the option "Save backup" instead of "Load backup" and the poor man was desperate wondering if there was any way to get his work back, because apparently he had been working on a project for a long time and he forgot to save, and the application accidentally closed ... So I'm seeing that Cinelerra has many traps that can ruin your work. That an application closes is something that happens even in the best professional applications ... but that an application has an option that can ruin your work, I am only seeing this in Cinelerra GG. And it's a shame, and the more I think about it, I can't understand what the point is to have an option to save a backup, with a keyboard shortcut and everything. If when you want to save your project, you just press "s" and that's it. If this option, without any sense and logic, were not in Cinelerra today, a user could have recovered their work, their time ... I think that those responsible and advisers for the development of Cinelerra GG should consider very seriously these trap options that can disenchant the most fervent user of Cinelerra GG. And honestly more than making a programmer work making advanced menus in a batch render window, for options that do not make any sense in these types of windows, I see it as a great waste of time, this is my opinion and again I am sorry to say it As I think about it, I think it would be better to remove // these options and spend this valuable time adding to Cinelerra GG these wonderful FFMPEG transitions that you have shared in another email. Sorry again for the "roll". Sincerely Rafa. El lun, 11 ene 2021 a las 18:36, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

Rafa, don't worry about expressing your thoughts directly. We are all Linux users here, which means that we all like direct communication. -- Ugin.

11.01.2021 18:30, Rafa Mar Multimedia en Gnu\Linux via Cin пишет:

...

Thank you very much Ugin for commenting on your experience... I had never looked at Cinelerra's batch render window. I go looking at tools, I test them, and then I try to write a tutorial on it to help hobbyists looking for a good tool. And your query caught my attention and I decided to take a look at the batch render assistant... the first thing I saw about this wizard is that it is not very intuitive, and the second my blood ran cold when I saw that it had a function that could destroy an entire project with a single click, and then another option that is linked to the aforementioned function, which is also misleading. I totally agree with you that these options without any practical sense, as much as Igor tries to convince us otherwise, that they can frustrate the user experience. Nobody likes to lose their job. And I find it difficult to recommend an editor that in a click given by mistake, this happens to us every day when we work with computers, lose all their work without going back. And I'm sorry to repeat myself, but when a professional needs two versions of the same project to do tests, he does not go to the batch render window to play his project, he simply makes a save as and that's it, and then loads these files in the batch render. I always say what I think, this creates enemies, and I am delighted with this, because normally these enemies are very egocentric people who cling to their ego without attending to reasons, and I am not like that, if I am wrong and they tell me, I even give thanks, and it's people like that that I like to surround myself with. If Igor is wrong with the fact that his working method is not practical and he likes to have an application that a wrong click can make you lose your job, which can be an hour or months... well there he, but I take the right to politely tell you that your proposal lacks all logic and is impractical or labor-saving, on the contrary, makes the batch render wizard a tool to avoid. Sorry for my long expositions, maybe I shouldn't write more about this topic because I have already said what I think many times.

El lun, 11 ene 2021 a las 13:30, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

Since I was mentioned in this thread, I will say that during the batch rendering tests, 4 files were deleted from me. Then I did not know the reasons for deleting them, and before experiments I always try to make backups, but for someone this behavior can ruin the whole wonderful impression of Cinelerra-GG. -- Ugin.

10.01.2021 21:10, Rafa Mar Multimedia en Gnu\Linux via Cin пишет:

...

At no point did I say that the batch rendering function should be removed. It was precisely Ugin's query that made me take a look at the Batch Render wizard. -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

I have forwarded this valuable information to you, and I hope it is not too late. I understand that a programmer likes to play with the code and do wonders, but you should consider that a video application is focused on people who are NOT computer scientists and that their knowledge is very basic. And these options "cheat" rather than facilitate the work they make it difficult. The audiovisual technicians must be given the simple tools. I do not know of any application that I work with in my audiovisual professional field that has the ability to step on a backup by user interaction. To justify this I would tell you an anecdote that happened during the production of "Finding Nemo" by Andrew Stanton at Pixar. But I think I bore you with my long writings and I don't see an initiative to correct these "traps" that Cinelerra contains. Rather the opposite, a strong attitude in maintaining them. Perhaps it could be done as in Kdenlive, Adobe etc.., which after a sudden shutdown at the next start gives the option to recover the file that was being worked with. But I usually go to practicality and if something is not useful I eliminate it, I think that eliminating these options (also the batch render option) is easier than making special menus for them or what I just mentioned from kdenlive, which is usually what What applications do after a sudden shutdown. Anyway, thank you very much for the information, I know that some time ago you mentioned this about the backup, but I did not remember very well what it was like, and this user I suppose that when he wrote to me he would have already done tests that they will have overwritten this .prev file Greetings Phyllis. El lun, 11 ene 2021 a las 21:56, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

RafaMar:

...

gave the option "Save backup" instead of "Load backup" and the poor man was desperate wondering if there was any way to get his work back,

from the Manual, section 4.4.3:

*"There is still 1 more backup that may save you. If for some reason you forgot to use Load backup immediately when restarting or you did a Load with Replace current project in your current session, you have a second chance to use File → Load and select $HOME/.bcast5/backup.prev as long as you only loaded a different file and have performed no editing operations."*

I just tested this to verify that it works as stated.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Thanks Andrew, I don't know how to deactivate these buttons, and it's not my place to deactivate them either, I simply recommend from my experience to improve Cinelerra and make it interesting and without kamikaze functions. I have Audacity 2.4.2 backport from Debian upstream running perfectly on Linux Mint 19.3, the only drawback is that the Calf effects interfaces are not graphically pretty, but I don't care, they work just as well with its retro-style interface from the late 90s. I don't know what distribution you use, and I'm sure you know 1000 times more about this than I do, but just in case, the repositories that have allowed me to have Audacity 2.4.2 working perfectly are the ones on this website: https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/audacity El lun, 11 ene 2021 a las 23:51, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от Tuesday 12 January 2021 00:57:48 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

I have forwarded this valuable information to you, and I hope it is not too late. I understand that a programmer likes to play with the code and do wonders, but you should consider that a video application is focused on people who are NOT computer scientists and that their knowledge is very basic.

Well, unlike closed-source applications you also can disable (at least) buttons you do not like _locally_. Yes, such patch may create inconvience later on, if there will be changes in this area upstream.

Sorry, I'm puzzled by another crash (Audacity 2.3.3 crash on launch, while 2.3.2 works ?! on my system), so I'm a bit distracted from CinelerraGG hacking right now ....

...

And these options "cheat" rather than facilitate the work they make it difficult. The audiovisual technicians must be given the simple tools. I do not know of any application that I work with in my audiovisual professional field that has the ability to step on a backup by user interaction. To justify this I would tell you an anecdote that happened during the production of "Finding Nemo" by Andrew Stanton at Pixar. But I think I bore you with my long writings and I don't see an initiative to correct these "traps" that Cinelerra contains. Rather the opposite, a strong attitude in maintaining them. Perhaps it could be done as in Kdenlive, Adobe etc.., which after a sudden shutdown at the next start gives the option to recover the file that was being worked with. But I usually go to practicality and if something is not useful I eliminate it, I think that eliminating these options (also the batch render option) is easier than making special menus for them or what I just mentioned from kdenlive, which is usually what What applications do after a sudden shutdown. Anyway, thank you very much for the information, I know that some time ago you mentioned this about the backup, but I did not remember very well what it was like, and this user I suppose that when he wrote to me he would have already done tests that they will have overwritten this .prev file Greetings Phyllis.

El lun, 11 ene 2021 a las 21:56, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

RafaMar:

...

gave the option "Save backup" instead of "Load backup" and the poor man was desperate wondering if there was any way to get his work back,

from the Manual, section 4.4.3:

*"There is still 1 more backup that may save you. If for some reason you forgot to use Load backup immediately when restarting or you did a Load with Replace current project in your current session, you have a second chance to use File → Load and select $HOME/.bcast5/backup.prev as long as you only loaded a different file and have performed no editing operations."*

I just tested this to verify that it works as stated.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Thanks again Andrew. I hardly know how to add a repository and if it doesn't work or doesn't work correctly I go back to the previous one. Regards. El mar, 12 ene 2021 a las 2:40, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от Tuesday 12 January 2021 03:27:41 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

Thanks Andrew, I don't know how to deactivate these buttons, and it's not my place to deactivate them either, I simply recommend from my experience to improve Cinelerra and make it interesting and without kamikaze functions.

Well, at the beginning I also know nothing about this particular codebase :} Try to look at code and guess what line does this or that .... comment it out, recompile, try to launch ....

...

I have Audacity 2.4.2 backport from Debian upstream running perfectly on Linux Mint 19.3, the only drawback is that the Calf effects interfaces are not graphically pretty, but I don't care, they work just as well with its retro-style interface from the late 90s.

:}

Yeah, sometimes binary distributions are fine, but mostly when someone already solved little things like ....

https://forum.audacityteam.org/viewtopic.php?t=105237 https://forum.audacityteam.org/viewtopic.php?f=19&t=104224 (I hit error related to re-building right in source tree, instead of 'build' directory)

The I realized portaudio was patched in Ubuntu/Debian etc:

https://portaudio.music.columbia.narkive.com/rju8OHIE/pa-getstreamhostapityp...

then I realized audacity will not link until you apply

https://gitweb.gentoo.org/repo/gentoo.git/tree/media-sound/audacity/files/au...

:}

so, a lot of adventuring, but at least you can see CinGG is not only software using custom/patched libs ...

...

I don't know what distribution you use, and I'm sure you know 1000 times more about this than I do, but just in case, the repositories that have allowed me to have Audacity 2.4.2 working perfectly are the ones on this website: https://launchpad.net/~ubuntuhandbook1/+archive/ubuntu/audacity

El lun, 11 ene 2021 a las 23:51, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

В сообщении от Tuesday 12 January 2021 00:57:48 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

I have forwarded this valuable information to you, and I hope it is not too late. I understand that a programmer likes to play with the code and do wonders, but you should consider that a video application is focused on people who are NOT computer scientists and that their knowledge is very basic.

Well, unlike closed-source applications you also can disable (at least) buttons you do not like _locally_. Yes, such patch may create inconvience later on, if there will be changes in this area upstream.

Sorry, I'm puzzled by another crash (Audacity 2.3.3 crash on launch, while 2.3.2 works ?! on my system), so I'm a bit distracted from CinelerraGG hacking right now ....

...

And these options "cheat" rather than facilitate the work they make it difficult. The audiovisual technicians must be given the simple tools. I do not know of any application that I work with in my audiovisual professional field that has the ability to step on a backup by user interaction. To justify this I would tell you an anecdote that happened during the production of "Finding Nemo" by Andrew Stanton at Pixar. But I think I bore you with my long writings and I don't see an initiative to correct these "traps" that Cinelerra contains. Rather the opposite, a strong attitude in maintaining them. Perhaps it could be done as in Kdenlive, Adobe etc.., which after a sudden shutdown at the next start gives the option to recover the file that was being worked with. But I usually go to practicality and if something is not useful I eliminate it, I think that eliminating these options (also the batch render option) is easier than making special menus for them or what I just mentioned from kdenlive, which is usually what What applications do after a sudden shutdown. Anyway, thank you very much for the information, I know that some time ago you mentioned this about the backup, but I did not remember very well what it was like, and this user I suppose that when he wrote to me he would have already done tests that they will have overwritten this .prev file Greetings Phyllis.

El lun, 11 ene 2021 a las 21:56, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

RafaMar:

...

gave the option "Save backup" instead of "Load backup" and the poor man was desperate wondering if there was any way to get his work back,

from the Manual, section 4.4.3:

*"There is still 1 more backup that may save you. If for some reason you forgot to use Load backup immediately when restarting or you did a Load with Replace current project in your current session, you have a second chance to use File → Load and select $HOME/.bcast5/backup.prev as long as you only loaded a different file and have performed no editing operations."*

I just tested this to verify that it works as stated.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

My quickly reply. I read all this long debate and the igor_ubuntu's article in his blog about "Batch Render". I think that the problem is How many users use that features? I don't use them but, maybe, somebody yes, as I always said in MantisBT; then you can not decide if delete/hide a function that is used (?) by other users, I think. Would be better that a modal window, with a warning, came out before overwrite a project? Yes. I think that a user can do a test on a short video/project (or create a backup for your own important works) before going on some feature like Batch Rendering, and reading the Manual: many people are doing a lot of work to write it. I would like to know how many people use this and that function, so a developer can make the right thing, if he is not a filmaker/editor. IgorBeg

I would like to know how many people use this and that function, so a developer can make the right thing, if he is not a filmaker/editor.

*Andrew*, in response to IgorB I am in favor of *commenting out the code for the 2 buttons* - Save to EDL Path and Warn if jobs/session mismatched. It would be less confusing than creating an UNSAFE button. I made an attempt to do this yesterday but ended up with SEGV as I am really clueless. I do not want to delete the code because this way the experienced users can recompile themselves and get the feature capability back for their own use.

In the past, deleting code has just led to having to put it back -- case in point is "Piping Video to a Command Line". It was deleted and we got raked over the coals because one person responded that it was the only feature of CinelerraGG that he used.

Andrea Paz, I admire people who speak clearly and say what they think. It never offends me that someone disagrees with me. I always start from the assumption that I can be the one who can be totally wrong. The only thing I can say is THANK YOU VERY MUCH FOR GIVING YOUR OPINION. ---- @Phyllis, I need help, How do you compile a Cinelerra GG .tgz? I have tried and it does not work for me, from the first line it gives me errors. <code terminal> rafa@rafa-pc:~/cinelerra-5.1$ ./autogen.sh + rm -f global_config configure Makefile Makefile.in + rm -f aclocal.m4 depcomp compile install-sh ltmain.sh + rm -f config.log config.guess config.h config.h.in config.sub config.status missing + rm -rf autom4te.cache m4 + '[' '' = clean ']' + mkdir m4 + autoreconf --install ./autogen.sh: línea 11: autoreconf: Command not found <--> Let me explain, I asked a friend who is a programmer for help, I sent him the batchrender.C file so that he could cancel the two mentioned buttons. He forwarded it to me and told me to replace, in the folder where I unzipped the tgz, this file for which he sent me back with the aforementioned functions canceled. And to compile the application to test ... but I am not able to do this step. He also told me that he had NOT deleted any code, only "commented" so that the compilation would ignore it. I don't understand any of this, and I can't test either, the only thing I can do is append this file here in case someone wants to test it. Or if someone is kind enough to show me the steps to compile so I can test. El mar, 12 ene 2021 a las 18:25, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

"Piping Video to a Command Line" - this really bomb! I'm very want comeback this feature. -- Ugin.

12.01.2021 18:33, Phyllis Smith via Cin пишет:

...

...

I would like to know how many people use this and that function, so a developer can make the right thing, if he is not a filmaker/editor.

*Andrew*, in response to IgorB I am in favor of *commenting out the code for the 2 buttons* - Save to EDL Path and Warn if jobs/session mismatched. It would be less confusing than creating an UNSAFE button. I made an attempt to do this yesterday but ended up with SEGV as I am really clueless. I do not want to delete the code because this way the experienced users can recompile themselves and get the feature capability back for their own use.

In the past, deleting code has just led to having to put it back -- case in point is "Piping Video to a Command Line". It was deleted and we got raked over the coals because one person responded that it was the only feature of CinelerraGG that he used.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Who have a friend, have a treasure. I have met with my programmer friend to see us and he has helped me to compile Cinelerra from git sources. Now it even seems simple to me, he says that it was very easy thanks to the good Cinelerra manual, where everything is explained very well. I still don't understand anything. He has tested the file that he had modified and it did not work as expected, causing the application to close. He has apologized, says that not at first he has not paid the attention that he required such a good job and in 1 minute he has written a few lines // of these and some like this /* and */ and the magic has been done, the wizard no longer has dangerous options and works like a charm, without errors of any kind. He has praised how well written the file was. It is a pity that he is not fond of audiovisuals, but he has told me that for specific matters like this we can count on him ... the truth is that what has taken the longest has been the compilation, because the file of the render window in 1 minute has had it working. I attach the corrected file. Thank you very much to all the people who have participated in the debate. P.S. Phyllis this is the good file to correct this issue. He has not deleted anything, only commented, that's what he called it, Maybe you should keep a copy of the original in case some suicidal user has fun breaking their work by playing with the assistant. For me now it's perfect. It can be explained in 4 lines and the only thing you need to know is to add a new line before modifying the input and output routes. Regards. El mar, 12 ene 2021 a las 22:44, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от Tuesday 12 January 2021 22:14:43 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

Andrea Paz, I admire people who speak clearly and say what they think. It never offends me that someone disagrees with me. I always start from the assumption that I can be the one who can be totally wrong. The only thing I can say is THANK YOU VERY MUCH FOR GIVING YOUR OPINION. ---- @Phyllis, I need help, How do you compile a Cinelerra GG .tgz? I have tried and it does not work for me, from the first line it gives me errors.

<code terminal> rafa@rafa-pc:~/cinelerra-5.1$ ./autogen.sh + rm -f global_config configure Makefile Makefile.in + rm -f aclocal.m4 depcomp compile install-sh ltmain.sh + rm -f config.log config.guess config.h config.h.in config.sub config.status missing + rm -rf autom4te.cache m4 + '[' '' = clean ']' + mkdir m4 + autoreconf --install ./autogen.sh: línea 11: autoreconf: Command not found <-->

Try to install this package? On Ubuntu/Debian/Mint (I think)

there is script in cinelerra-5.1/blds/bld_prepare.sh

apt-get -f -y install apt-file sox nasm yasm g++ build-essential zlib1g-dev \ texinfo libpng-dev freeglut3-dev libxv-dev libasound2-dev libbz2-dev \ libncurses5-dev libxinerama-dev libfreetype6-dev libxft-dev libgif-dev \ libtiff5-dev exuberant-ctags ttf-bitstream-vera xfonts-75dpi xfonts-100dpi \ fonts-dejavu libopenexr-dev festival libfftw3-dev gdb libusb-1.0-0-dev \ libdc1394-22-dev libflac-dev libjbig-dev libvdpau-dev libva-dev \ inkscape libsndfile1-dev libtheora-dev cmake udftools libxml2-utils git \ autoconf automake debhelper libgtk2.0-dev libpulse-dev python

but you can just run this script as root, it will install bunch of ...everything.... including autoconf

...

Let me explain, I asked a friend who is a programmer for help, I sent him the batchrender.C file so that he could cancel the two mentioned buttons. He forwarded it to me and told me to replace, in the folder where I unzipped the tgz, this file for which he sent me back with the aforementioned functions canceled. And to compile the application to test ... but I am not able to do this step. He also told me that he had NOT deleted any code, only "commented" so that the compilation would ignore it. I don't understand any of this, and I can't test either, the only thing I can do is append this file here in case someone wants to test it. Or if someone is kind enough to show me the steps to compile so I can test.

El mar, 12 ene 2021 a las 18:25, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

"Piping Video to a Command Line" - this really bomb! I'm very want comeback this feature. -- Ugin.

12.01.2021 18:33, Phyllis Smith via Cin пишет:

...

...

I would like to know how many people use this and that function, so a developer can make the right thing, if he is not a filmaker/editor.

*Andrew*, in response to IgorB I am in favor of *commenting out the code for the 2 buttons* - Save to EDL Path and Warn if jobs/session mismatched. It would be less confusing than creating an UNSAFE button. I made an attempt to do this yesterday but ended up with SEGV as I am really clueless. I do not want to delete the code because this way the experienced users can recompile themselves and get the feature capability back for their own use.

In the past, deleting code has just led to having to put it back -- case in point is "Piping Video to a Command Line". It was deleted and we got raked over the coals because one person responded that it was the only feature of CinelerraGG that he used.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

*Phyllis*, the image you attach is the result of the first attempt, once tested it was corrected and that is why I made a second shipment, which if you compile correctly the window looks exactly as before but without the dangerous options. I have done several tests and they have all been correct. I reattach the file that has been corrected, the one you should use. You can see the differences if you compare it with the original. The one from the first shipment is not right. This is the good one. [image: imagen.png] El mié, 13 ene 2021 a las 4:51, Phyllis Smith via Cin (< cin@lists.cinelerra-gg.org>) escribió:

*RafaMar*, thanks for enlisting help from your programmer friend. Using the batchrender.C file you sent, the menu box is not lined up quite right as you can see in the attachment, but if we use this I think I might be able to fix it myself.

*Andrew*, the other email shows I had a problem with the patch: disable_two_buttons_in_batchrender_gui-5.diff but maybe I did something wrong.

*Andrea_Paz*, I agree with not deleting these buttons and really do not like to just comment them out, but are you totally opposed to doing so?

On Tue, Jan 12, 2021 at 6:20 PM Rafa Mar Multimedia en Gnu\Linux via Cin < cin@lists.cinelerra-gg.org> wrote:

...

Who have a friend, have a treasure. I have met with my programmer friend to see us and he has helped me to compile Cinelerra from git sources. Now it even seems simple to me, he says that it was very easy thanks to the good Cinelerra manual, where everything is explained very well. I still don't understand anything. He has tested the file that he had modified and it did not work as expected, causing the application to close. He has apologized, says that not at first he has not paid the attention that he required such a good job and in 1 minute he has written a few lines // of these and some like this /* and */ and the magic has been done, the wizard no longer has dangerous options and works like a charm, without errors of any kind. He has praised how well written the file was. It is a pity that he is not fond of audiovisuals, but he has told me that for specific matters like this we can count on him ... the truth is that what has taken the longest has been the compilation, because the file of the render window in 1 minute has had it working.

I attach the corrected file.

Thank you very much to all the people who have participated in the debate.

P.S. Phyllis this is the good file to correct this issue. He has not deleted anything, only commented, that's what he called it, Maybe you should keep a copy of the original in case some suicidal user has fun breaking their work by playing with the assistant. For me now it's perfect. It can be explained in 4 lines and the only thing you need to know is to add a new line before modifying the input and output routes. Regards.

El mar, 12 ene 2021 a las 22:44, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

В сообщении от Tuesday 12 January 2021 22:14:43 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

Andrea Paz, I admire people who speak clearly and say what they think. It never offends me that someone disagrees with me. I always start from the assumption that I can be the one who can be totally wrong. The only thing I can say is THANK YOU VERY MUCH FOR GIVING YOUR OPINION. ---- @Phyllis, I need help, How do you compile a Cinelerra GG .tgz? I have tried and it does not work for me, from the first line it gives me errors.

<code terminal> rafa@rafa-pc:~/cinelerra-5.1$ ./autogen.sh + rm -f global_config configure Makefile Makefile.in + rm -f aclocal.m4 depcomp compile install-sh ltmain.sh + rm -f config.log config.guess config.h config.h.in config.sub config.status missing + rm -rf autom4te.cache m4 + '[' '' = clean ']' + mkdir m4 + autoreconf --install ./autogen.sh: línea 11: autoreconf: Command not found <-->

Try to install this package? On Ubuntu/Debian/Mint (I think)

there is script in cinelerra-5.1/blds/bld_prepare.sh

apt-get -f -y install apt-file sox nasm yasm g++ build-essential zlib1g-dev \ texinfo libpng-dev freeglut3-dev libxv-dev libasound2-dev libbz2-dev \ libncurses5-dev libxinerama-dev libfreetype6-dev libxft-dev libgif-dev \ libtiff5-dev exuberant-ctags ttf-bitstream-vera xfonts-75dpi xfonts-100dpi \ fonts-dejavu libopenexr-dev festival libfftw3-dev gdb libusb-1.0-0-dev \ libdc1394-22-dev libflac-dev libjbig-dev libvdpau-dev libva-dev \ inkscape libsndfile1-dev libtheora-dev cmake udftools libxml2-utils git \ autoconf automake debhelper libgtk2.0-dev libpulse-dev python

but you can just run this script as root, it will install bunch of ...everything.... including autoconf

...

Let me explain, I asked a friend who is a programmer for help, I sent him the batchrender.C file so that he could cancel the two mentioned buttons. He forwarded it to me and told me to replace, in the folder where I unzipped the tgz, this file for which he sent me back with the aforementioned functions canceled. And to compile the application to test ... but I am not able to do this step. He also told me that he had NOT deleted any code, only "commented" so that the compilation would ignore it. I don't understand any of this, and I can't test either, the only thing I can do is append this file here in case someone wants to test it. Or if someone is kind enough to show me the steps to compile so I can test.

El mar, 12 ene 2021 a las 18:25, preobraz--- via Cin (< cin@lists.cinelerra-gg.org>) escribió:

...

"Piping Video to a Command Line" - this really bomb! I'm very want comeback this feature. -- Ugin.

12.01.2021 18:33, Phyllis Smith via Cin пишет:

...

> I would like to know how many people use this and that function, so a > developer can make the right thing, if he is not a filmaker/editor. > > *Andrew*, in response to IgorB I am in favor of *commenting out the code for the 2 buttons* - Save to EDL Path and Warn if jobs/session mismatched. It would be less confusing than creating an UNSAFE button. I made an attempt to do this yesterday but ended up with SEGV as I am really clueless. I do not want to delete the code because this way the experienced users can recompile themselves and get the feature capability back for their own use.

In the past, deleting code has just led to having to put it back -- case in point is "Piping Video to a Command Line". It was deleted and we got raked over the coals because one person responded that it was the only feature of CinelerraGG that he used.

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

В сообщении от Wednesday 13 January 2021 08:18:34 Phyllis Smith via Cin написал(а):

RafaMar, I apologize for using the wrong one -- working on 3 different issues today + a big personal problem came up. Will wait to hear back from Andrew and Andrea to see if they are amenable to commenting out the code or prefer to use UNSAFE button workaround.

Oh, sorry for upcoming problem - hopefully it will be resolved ... I think I prefer my version ( :} ) IF you can compile and make it work as expected. You may want to double-check git apply actually applied patch, if you use this tool. Run it with '-v' parameter, and use '-R' if you want to reverse applied patch for me it works like this: root@slax:/dev/shm/tmp/cinelerra-goodguy-20210112/cinelerra-5.1# LANG=C git apply -v /home/guest/botva/src/cinelerra-git/cin-5/disable_two_buttons_in_batchrender_gui-5.diff /home/guest/botva/src/cinelerra-git/cin-5/disable_two_buttons_in_batchrender_gui-5.diff:18: trailing whitespace. /home/guest/botva/src/cinelerra-git/cin-5/disable_two_buttons_in_batchrender_gui-5.diff:79: trailing whitespace. /home/guest/botva/src/cinelerra-git/cin-5/disable_two_buttons_in_batchrender_gui-5.diff:121: trailing whitespace. Checking patch cinelerra-5.1/cinelerra/batchrender.C... Applied patch cinelerra-5.1/cinelerra/batchrender.C cleanly. warning: 3 lines add whitespace errors. I think checkbox in Preferences control ANOTHER warning about EDL from different versions of Cinelerra... Probably some tooltips there will not hurt ... in https://git.cinelerra-gg.org/git/?p=goodguy/cinelerra.git;a=blob;f=cinelerra... strange, I can't see where this version actually checked ..... I treied to load old Cin 5.1 project, and it shows warning about locally-encoded effect/plugin names and show nothing on timeline, but I guess this is different warning ... need to dig into history ....

Glad to hear you can compile yourself now -- it will be important as the GIT repository is updated so you can test early. For example, you should now be able to see in the build you and the programmer did, the latest Spanish translations you provided.

On Tue, Jan 12, 2021 at 9:20 PM Rafa Mar Multimedia en Gnu\Linux via Cin < cin@lists.cinelerra-gg.org> wrote:

[skip]

What do you think about a middle way, if igor_ubuntu, Andrea_Paz, RafaMar, and so on, agree with me? Hide (and disable) only the "Save to EDL path" button for avoid mistake and lose your project BUT leaving the "warn if jobs/session mismatched" checkbox. That checkbox is not dangerous for losing your project and it may be useful sometimes. IgorBeg Il 13/01/2021 09:36, Andrea paz via Cin ha scritto:

*Andrea_Paz*, I agree with not deleting these buttons and really do not like to just comment them out, but are you totally opposed to doing so?

No problem from me.

RafaMar, the "warn if jobs/session mismatched" checkbox is not always turn on. Cinelerra-GG remember the status of that checkbox by your changes: so if you have checked it then it will be checked also for the next time. As this checkbox works is right. IgorBeg Il 13/01/2021 10:25, Rafa Mar Multimedia en Gnu\Linux via Cin ha scritto:

Igor, ok, I agree to keep this option*(I guess you reffered to"warn if jobs/session mismatched")*, since it does not imply any danger of losing the xml project, but with a small change, which by default is turned off.

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.

*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" 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@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@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@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/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. Greetings and forgive my extensive responses. El vie, 15 ene 2021 a las 6:40, Andrew Randrianasulu via Cin (< cin@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@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@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@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Safety always has to come first, always. Would you work with hard drives a thousand times faster than current ones, but if you do a bad shutdown, you lose all your information without the possibility of recovering it? I do not. It is always better slow but surely than fast with irrecoverable risks. As is the possibility of a wrong click on this button with a very valuable file in the EDL path and Cinelerra with another project loaded ... a simple mistake, click and goodbye work. So I do not want to work, and I find it difficult to recommend an application that can give a user this "bad shot". I think that GG would have had no problem in reviewing the function of this button and given the great risk that it entails, it would have done the resource of numbering the file, instead of overwriting it if the precaution had NOT been taken to rename in the "EDL path: " In this way, for users like Igor Ubuntu it remains the same, and for new users it is no longer dangerous.

*You also can try to put xml project files under git source control...* This I don't know how to do it. I don't even know what it is.

Greetings Andrew and thank you very much for your excellent work. El vie, 15 ene 2021 a las 7:12, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от 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@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@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@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@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

*Thank you very much Andrew*, but these things are too difficult for me, I want Cinelerra to be safe and simple. People who like computers understand that they like to play and try these things, but audiovisual technicians are not computer scientists, we simply work with computers because they are a good tool. It is the difference between a mechanic and a racing driver, the driver does not have to know mechanics. El vie, 15 ene 2021 a las 8:00, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от Friday 15 January 2021 09:42:44 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

Safety always has to come first, always. Would you work with hard drives a thousand times faster than current ones, but if you do a bad shutdown, you lose all your information without the possibility of recovering it? I do not.

You might be badly surprized ... :/ (hint: SSDs sometimes die)

...

It is always better slow but surely than fast with irrecoverable risks.

As

...

is the possibility of a wrong click on this button with a very valuable file in the EDL path and Cinelerra with another project loaded ... a simple mistake, click and goodbye work.

There will be *no* this button by default ....

...

So I do not want to work, and I find it difficult to recommend an application that can give a user this "bad shot".

I think that GG would have had no problem in reviewing the function of

this

...

button and given the great risk that it entails, it would have done the resource of numbering the file, instead of overwriting it if the precaution had NOT been taken to rename in the "EDL path: "

In this way, for users like Igor Ubuntu it remains the same, and for new users it is no longer dangerous.

...

*You also can try to put xml project files under git source control...* This I don't know how to do it. I don't even know what it is.

Oh, I actually tried it just now.

So, navigate in terminal to your (hidden) .bcast5 folder

from inside it create .gitignore file with this content:

cat .gitignore *.idx *.mkr

('cat' shows file, for creating it you can use some redirection ...or just your favourite editor)

run:

root@slax:~/.bcast5# git init Инициализирован пустой репозиторий Git в /root/.bcast5/.git/ root@slax:~/.bcast5# git add . root@slax:~/.bcast5# git commit

I use root user here, because I compile / edit from root. Not your idea of safety, so use same procedure in your normal user directory.

Now, if git doesn't known you yet you will be asked to do those two things (only once per user, or once per repo)

git config --global user.email "you@example.com" git config --global user.name "Ваше Имя"

this set name/email globally. Run without --global for only making those settings effective in current git repo.

Now ' git commit' should work, for me it shows mcedit with some prepared commit message and list of files to commit. I just entered phrase describing current date/time and word 'backup'

When you exit editor commit will be made.

[master (корневой коммит) fb0d435] backup-01-15-2021, 09:43 7 files changed, 1939 insertions(+) create mode 100644 .gitignore create mode 100644 Cinelerra_plugins create mode 100644 Cinelerra_rc create mode 100644 backup.prev create mode 100644 backup.xml create mode 100644 batchrender.rc create mode 100644 ladspa_plugins._usr_lib_ladspa

if you do not want your _plugins caches to be there just add them to .gitignore

now, you can use usual git log/ git reset --hard <commit> for reviewing log and resetting settings

Works with any text and xml files :}

In theory you can put git commit at the end of bash command file, and use this file for starting CinGG ? (not tested), so at any app quit it will commit changes, INCLUDING those backup.xml/backup.prev

Of course if your project xml saves somewhere else - just use same procedure there ....

Not as nice as integrated solution, but hopefully should work with any application!

...

Greetings Andrew and thank you very much for your excellent work.

El vie, 15 ene 2021 a las 7:12, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

-- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin

Today I have had some time to play with the batch render again, and I have even discussed it with friends of the same profession, audio visual technicians, and they see a nonsense this way of working from a batch render window, just like me, especially because of the great danger it entails. With how easy it is to make a Save As, we make as many versions as we want and then load them into the batch render, as is always done in any other application. The other option, to warn if the session does not match, has made them laugh ... normally a batch render is done with the application without any project loaded. Or even this is launched from the terminal. And in the conversation someone has said something with which I strongly agree, "It is a real shame that some open source and free applications seem to be focused only for people with high programming and computer skills" I would like that Cinelerra could be used by anyone, such as Blender, Gimp, Inkscape, Olive, kdenlive... etc... without jeopardizing their precious work and not only for use by people with a lot of computer knowledge. I remember days ago a reader of my blog returned to kdenlive because after a sudden closure of Cinelerra he lost all his unsaved work... because he made the mistake of pressing save backup instead of load backup... in kdenlive when this happens and he opens the application again gives you a warning if you want to recover your project, and it is not misleading. Greetings and forgive my long exposition again. El vie, 15 ene 2021 a las 9:16, Andrew Randrianasulu via Cin (< cin@lists.cinelerra-gg.org>) escribió:

В сообщении от Friday 15 January 2021 10:24:59 Rafa Mar Multimedia en Gnu\Linux via Cin написал(а):

...

*Thank you very much Andrew*, but these things are too difficult for me, I want Cinelerra to be safe and simple. People who like computers understand that they like to play and try these things, but audiovisual technicians are not computer scientists, we simply work with computers because they are a good tool. It is the difference between a mechanic and a racing driver, the driver does not have to know mechanics.

Driver better to know where brakes located ..... (completely never tried to drive any car)

Anyway, I'll try to create bash script doing exactly this (automatic backup via ext. tools).

PS: there even was point in some famous book (Art of Unix programming?) that Unix (and Linux by extension) provides set of tools YOU can combine in ways their creators never dreamed about.

I think this is quite important point even on Windows/Mac

Have lovely day ..... -- Cin mailing list Cin@lists.cinelerra-gg.org https://lists.cinelerra-gg.org/mailman/listinfo/cin