Run And Integrate Cinelerra AppImage With AppImageLauncher
The README appimage file describes the CLI method to install Cinelerra-GG 1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it ./cinelerraGG.AppImpage -------------------------------- Now I have also tried the /GUI method/ to download, Run And Integrate Cinelerra AppImage with installed *AppImageLauncher*. On openSUSE Leap 15.3 (and surely similar on other distros) AppImageLauncher is integrated with Firefox as follows: 1) start download the AppImage file, and a widget popup in Firefox with the option to open it with AppImageLauncher (instead of Saving it) 2) At the end of the download a new popup asks to integrate it with your desktop system. OK -------------------------------- (The AppImage installation directory is /home/user/Application by default, but can be customized in the Launcher widget) That's it. Both *Cin* and *Cin-multi* were installed this way, automatic integrated with icons and in the app-menue in Gnome, see the attached screenshot AppImage.png and urls to articles for detailed info below. I have used *alacarte* to add the icon comment sub-text to *Cin-multi* for multiple bit version.the icon, as also mentioned in a previous post AppImage and Desktop Integration with an app launcher https://www.mail-archive.com/[email protected]/msg02692.html Packages I installed first on Leap 15.3 zypper se -is appimage Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+------------------+---------+-------------------------------------+--------+------------------ i+ | appimaged | package | 9~pre.1495805837.d05eac1-bp153.1.16 | x86_64 | Main Repository i+ | appimagelauncher | package | 2.2.0-travis995~0f91801 | x86_64 | (System Packages) appimaged Daemon handles (un)registering AppImages with the system appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such). The package comes also with appimage.validate CLI tool to verify signature of AppImage files. Version 9~pre.14958... Size 36.5 KB openSUSE Leap 15.3 AppImageLauncher generic https://www.linuxuprising.com/2018/04/easily-run-and-integrate-appimage-file... https://blog.desdelinux.net/en/appimagelauncher-easily-runs-and-integrates-a... https://github.com/TheAssassin/AppImageLauncher AppImageLauncher openSUSE: https://cubiclenate.com/2020/01/09/appimagelauncher-appimage-manager-on-open... https://software.opensuse.org/package/appimaged https://tutorialforlinux.com/2019/12/27/step-by-step-appimagelauncher-opensu... Terje
Terje, Thank you for passing this information along. I will update the README and the manual to include your methodology. On Fri, Oct 1, 2021 at 12:37 PM Terje J. Hanssen via Cin < [email protected]> wrote:
The README appimage file describes the CLI method to install Cinelerra-GG
1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it ./cinelerraGG.AppImpage
--------------------------------
Now I have also tried the /GUI method/ to download, Run And Integrate Cinelerra AppImage with installed *AppImageLauncher*. On openSUSE Leap 15.3 (and surely similar on other distros) AppImageLauncher is integrated with Firefox as follows:
1) start download the AppImage file, and a widget popup in Firefox with the option to open it with AppImageLauncher (instead of Saving it) 2) At the end of the download a new popup asks to integrate it with your desktop system. OK
--------------------------------
(The AppImage installation directory is /home/user/Application by default, but can be customized in the Launcher widget)
That's it. Both *Cin* and *Cin-multi* were installed this way, automatic integrated with icons and in the app-menue in Gnome, see the attached screenshot AppImage.png and urls to articles for detailed info below.
I have used *alacarte* to add the icon comment sub-text to *Cin-multi* for multiple bit version.the icon, as also mentioned in a previous post AppImage and Desktop Integration with an app launcher https://www.mail-archive.com/[email protected]/msg02692.html
Packages I installed first on Leap 15.3
zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+-------------------------------------+--------+------------------ i+ | appimaged | package | 9~pre.1495805837.d05eac1-bp153.1.16 | x86_64 | Main Repository i+ | appimagelauncher | package | 2.2.0-travis995~0f91801 | x86_64 | (System Packages)
appimaged Daemon handles (un)registering AppImages with the system appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such). The package comes also with appimage.validate CLI tool to verify signature of AppImage files. Version 9~pre.14958... Size 36.5 KB openSUSE Leap 15.3
AppImageLauncher generic
https://www.linuxuprising.com/2018/04/easily-run-and-integrate-appimage-file...
https://blog.desdelinux.net/en/appimagelauncher-easily-runs-and-integrates-a... https://github.com/TheAssassin/AppImageLauncher
AppImageLauncher openSUSE:
https://cubiclenate.com/2020/01/09/appimagelauncher-appimage-manager-on-open... https://software.opensuse.org/package/appimaged
https://tutorialforlinux.com/2019/12/27/step-by-step-appimagelauncher-opensu...
Terje
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Phyllis, Just a minor suggestion I forgot to mentione: The file *README.appimag*e works fine to read with cat (cli), but I experienced that usual dual mouse-click on it in a GUI file browser (Gnome Files) can't open it, because is recognized to be of file type Appimage (which it isn't). I rather renamed it to *README_appimage.txt* or optionally just *README_appimage* which both worked the usual gui way 😉 Terje Den 01.10.2021 22:10, skrev Phyllis Smith via Cin:
Terje, Thank you for passing this information along. I will update the README and the manual to include your methodology.
On Fri, Oct 1, 2021 at 12:37 PM Terje J. Hanssen via Cin <[email protected] <mailto:[email protected]>> wrote:
The README appimage file describes the CLI method to install Cinelerra-GG
1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it ./cinelerraGG.AppImpage
--------------------------------
Now I have also tried the /GUI method/ to download, Run And Integrate Cinelerra AppImage with installed *AppImageLauncher*. On openSUSE Leap 15.3 (and surely similar on other distros) AppImageLauncher is integrated with Firefox as follows:
1) start download the AppImage file, and a widget popup in Firefox with the option to open it with AppImageLauncher (instead of Saving it) 2) At the end of the download a new popup asks to integrate it with your desktop system. OK
--------------------------------
(The AppImage installation directory is /home/user/Application by default, but can be customized in the Launcher widget)
That's it. Both *Cin* and *Cin-multi* were installed this way, automatic integrated with icons and in the app-menue in Gnome, see the attached screenshot AppImage.png and urls to articles for detailed info below.
I have used *alacarte* to add the icon comment sub-text to *Cin-multi* for multiple bit version.the icon, as also mentioned in a previous post AppImage and Desktop Integration with an app launcher https://www.mail-archive.com/[email protected]/msg02692.html <https://www.mail-archive.com/[email protected]/msg02692.html>
Packages I installed first on Leap 15.3
zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository ---+------------------+---------+-------------------------------------+--------+------------------ i+ | appimaged | package | 9~pre.1495805837.d05eac1-bp153.1.16 | x86_64 | Main Repository i+ | appimagelauncher | package | 2.2.0-travis995~0f91801 | x86_64 | (System Packages)
appimaged Daemon handles (un)registering AppImages with the system appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such). The package comes also with appimage.validate CLI tool to verify signature of AppImage files. Version 9~pre.14958... Size 36.5 KB openSUSE Leap 15.3
AppImageLauncher generic https://www.linuxuprising.com/2018/04/easily-run-and-integrate-appimage-file... <https://www.linuxuprising.com/2018/04/easily-run-and-integrate-appimage-files.html> https://blog.desdelinux.net/en/appimagelauncher-easily-runs-and-integrates-a... <https://blog.desdelinux.net/en/appimagelauncher-easily-runs-and-integrates-apps-into-appimage/> https://github.com/TheAssassin/AppImageLauncher <https://github.com/TheAssassin/AppImageLauncher>
AppImageLauncher openSUSE: https://cubiclenate.com/2020/01/09/appimagelauncher-appimage-manager-on-open... <https://cubiclenate.com/2020/01/09/appimagelauncher-appimage-manager-on-opensuse/> https://software.opensuse.org/package/appimaged <https://software.opensuse.org/package/appimaged> https://tutorialforlinux.com/2019/12/27/step-by-step-appimagelauncher-opensu... <https://tutorialforlinux.com/2019/12/27/step-by-step-appimagelauncher-opensuse-installation-guide/>
Terje
-- Cin mailing list [email protected] <mailto:[email protected]> https://lists.cinelerra-gg.org/mailman/listinfo/cin <https://lists.cinelerra-gg.org/mailman/listinfo/cin>
Terje, I will rename it README_appimage.txt which is what I should have done in the first place but it was new and I did not know how it would all work out. Below is what it will now say and if it looks OK to you, I will put it on the website tomorrow. Note that I left out any mention of cin.svg because now with AppImage, the source is no longer downloaded to the user and they would have to get it from the website src/cin...tgz file. You lose some capabilities with the AppImage, but the users who have been around awhile can find ways or do their own builds. ****************************************************************************************** AppImage is a software package that can be installed and run on various Linux distros. It has several advantages in that there is no need to install or compile software and no need to have root permission. In addition, no system files are modified and you can simply delete the software by deleting the AppImage file. To install an AppImage, download it, make it executable and run it. It is a compressed image and contains all the dependencies/libraries needed to run. 1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it, for example ./CinGG-date-x86_64.AppImpage ARCH requires install of the "libappimage" package. LEAP 15.3 (openSUSE) requires install of the "appimage" package. ***** Alternative GUI method to download provided by Leap 15.3 user ***** To run and integrate Cinelerra AppImage with installed "AppImageLauncher", follow the next few steps. On openSUSE Leap 15.3 (and hopefully somewhat similar on other distros) AppImageLauncher is integrated with Firefox. 1) Start to download the AppImage file, and a widget popups in Firefox with the option to open it with AppImageLauncher (instead of Saving). 2) At the end of the download a new popup asks to integrate it with your desktop system, so click OK. The AppImage installation directory is /home/user/Application by default, but can be changed. This automatically is integrated with icons and in the Gnome app-menu. On Fri, Oct 1, 2021 at 2:47 PM Terje J. Hanssen via Cin < [email protected]> wrote:
Phyllis,
Just a minor suggestion I forgot to mentione:
The file *README.appimag*e works fine to read with cat (cli), but I experienced that usual dual mouse-click on it in a GUI file browser (Gnome Files) can't open it, because is recognized to be of file type Appimage (which it isn't).
I rather renamed it to *README_appimage.txt* or optionally just *README_appimage* which both worked the usual gui way 😉
Terje
Den 01.10.2021 22:10, skrev Phyllis Smith via Cin:
Terje, Thank you for passing this information along. I will update the README and the manual to include your methodology.
On Fri, Oct 1, 2021 at 12:37 PM Terje J. Hanssen via Cin < [email protected]> wrote:
The README appimage file describes the CLI method to install Cinelerra-GG
1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it ./cinelerraGG.AppImpage
--------------------------------
Now I have also tried the /GUI method/ to download, Run And Integrate Cinelerra AppImage with installed *AppImageLauncher*. On openSUSE Leap 15.3 (and surely similar on other distros) AppImageLauncher is integrated with Firefox as follows:
1) start download the AppImage file, and a widget popup in Firefox with the option to open it with AppImageLauncher (instead of Saving it) 2) At the end of the download a new popup asks to integrate it with your desktop system. OK
--------------------------------
(The AppImage installation directory is /home/user/Application by default, but can be customized in the Launcher widget)
That's it. Both *Cin* and *Cin-multi* were installed this way, automatic integrated with icons and in the app-menue in Gnome, see the attached screenshot AppImage.png and urls to articles for detailed info below.
I have used *alacarte* to add the icon comment sub-text to *Cin-multi* for multiple bit version.the icon, as also mentioned in a previous post AppImage and Desktop Integration with an app launcher https://www.mail-archive.com/[email protected]/msg02692.html
Packages I installed first on Leap 15.3
zypper se -is appimage Loading repository data... Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+------------------+---------+-------------------------------------+--------+------------------ i+ | appimaged | package | 9~pre.1495805837.d05eac1-bp153.1.16 | x86_64 | Main Repository i+ | appimagelauncher | package | 2.2.0-travis995~0f91801 | x86_64 | (System Packages)
appimaged Daemon handles (un)registering AppImages with the system appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such). The package comes also with appimage.validate CLI tool to verify signature of AppImage files. Version 9~pre.14958... Size 36.5 KB openSUSE Leap 15.3
AppImageLauncher generic
https://www.linuxuprising.com/2018/04/easily-run-and-integrate-appimage-file...
https://blog.desdelinux.net/en/appimagelauncher-easily-runs-and-integrates-a... https://github.com/TheAssassin/AppImageLauncher
AppImageLauncher openSUSE:
https://cubiclenate.com/2020/01/09/appimagelauncher-appimage-manager-on-open... https://software.opensuse.org/package/appimaged
https://tutorialforlinux.com/2019/12/27/step-by-step-appimagelauncher-opensu...
Terje
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
What is this cin.svg stuff? It is not in the current README.appimage. On another note, on my Mint 20 system, each start of the AppImage rebuilds the plugin index, even though the file is in .bcast5. MatN
MatN: What is this cin.svg stuff? It is not in the current README.appimage.
cin.svg is in the source code under image/cin.svg -- it was created as an icon when users wanted to hook up the cinelerra startup with an icon that could just be clicked on to launch the program instead of previously having to keyin ./bin/cin (or whatever). From the manual:
Then just start the application by keying in: ./cin in the bin subdirectory OR add a desktop icon by using the appropriate directory to copy the files to, run as root, and edit to correct the directory path. Below are generic directions of how to do this.
cd /cinelerra_directory_path cp -a image/cin.{svg,xpm} /usr/share/pixmaps/ cp -a image/cin.desktop /usr/share/applications/cin.desktop
After you have followed the above, in the cin.desktop file, change the Exec=cin line to be Exec=<your_directory_path>/bin/cin.
On another note, on my Mint 20 system, each start of the AppImage rebuilds the plugin index, even though the file is in .bcast5.
This is on all systems and has been logged in BT #588. I looked at it only a little and am thinking that the code could be changed to not use the job id number.
MatN -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
On Sun, 2021-10-03 at 10:50 -0600, Phyllis Smith via Cin wrote:
MatN:
What is this cin.svg stuff? It is not in the current README.appimage.
cin.svg is in the source code under image/cin.svg -- it was created as an icon when users wanted to hook up the cinelerra startup with an icon that could just be clicked on to launch the program instead of previously having to keyin ./bin/cin (or whatever).
Thanks, understood. Note that that icon is likely now part of the AppImage (AppDir directory).
On another note, on my Mint 20 system, each start of the AppImage rebuilds the plugin index, even though the file is in .bcast5.
Ah no, that is a different one. I am talking about rebuilding file Cinelerra_plugins each time CinGG starts. Currently that takes > 2.5 minutes on my Mint 20.2 (which is why it has some priority for me), on Manjaro it works fine: after first build, a new CinGG start does not re-build that LV2 index it unless you tell it to. MatN
On another note, on my Mint 20 system, each start of the AppImage rebuilds the plugin index, even though the file is in .bcast5.
Ah no, that is a different one. I am talking about rebuilding file Cinelerra_plugins each time CinGG starts. Currently that takes > 2.5 minutes on my Mint 20.2 (which is why it has some priority for me), on Manjaro it works fine: after first build, a new CinGG start does not re-build that LV2 index it unless you tell it to.
OK, I did not read this carefully so will test on Fedora and see if I get a clue. Thanks for correcting me.
Just sounding out if there is interest in supporting these xml formats as import/export. They are used a lot in the professional world. I have no idea how difficult it would be to implement this, or even if it is possible. MatN
On Tuesday, October 19, 2021 3:19:57 PM CEST, mnieuw--- via Cin wrote:
Just sounding out if there is interest in supporting these xml formats as import/export. They are used a lot in the professional world. I have no idea how difficult it would be to implement this, or even if it is possible.
I would say, don't go into this direction, instead make sure that Cinelerra can open and save MXF. -- Stefan
These topics are very interesting to me, and I've tried to discuss them at other times. @MatN The xml format of CinGG is specific and not compatible with that of other programs. There can be no interchange. Andrew has worked on the EDL CMX3600, but it is not fully functional and in any case it is too poor and obsolete (it was born for analog). Perhaps a feasible way would be to make the CinGG xml compatible with OpenTimelineIO (https://github.com/PixarAnimationStudios/OpenTimelineIO), but I have no idea how difficult it would be to create an "adapter". @Stefan Since ffmpeg supports mxf in a basic way, there is an encoding preset available in CinGG; however, I assume you are referring to more advanced features such as timecode and metadata support, so that the SMTP standard is fully respected. Could you provide more details on what is required by this format and what is missing? Do you think it's possible to implement it in CinGG (which also involves implementing timecode and metadata)? [PS: I saw that you are contributing to the AXIOM Beta/OpenCine project; what is the status of the project? I wish you all the luck! https://apertus.org/axiom-beta https://apertus.org/opencine]
On Tuesday, October 19, 2021 4:32:13 PM CEST, Andrea paz wrote:
@Stefan Since ffmpeg supports mxf in a basic way, there is an encoding preset available in CinGG; however, I assume you are referring to more advanced features such as timecode and metadata support, so that the SMTP standard is fully respected. Could you provide more details on what is required by this format and what is missing?
A lifetime ago I was introduced to the company that produced this; <http://www.mxfserver.com/> They basically use a virtual filesystem approach in order to allow one NLE to share information with the other NLE. I think originally implementing all the formats, but having MXF as backend. If you would go for this approach then having operational patterns available describing 'the timeline' being a very interchangeable solution. Now I wonder practically how they have resolved effects and likes not being available in one, but in the other.
Do you think it's possible to implement it in CinGG (which also involves implementing timecode and metadata)?
I cannot really comment on this part :)
[PS: I saw that you are contributing to the AXIOM Beta/OpenCine project; what is the status of the project? I wish you all the luck! https://apertus.org/axiom-beta https://apertus.org/opencine]
It was also quite some years ago with Elphel and later Axiom. I mainly focussed on bootstrapping what was needed to boot a Zedboard. So cannot comment on the progress. At this moment I am working more on the open source linear stuff, OpenSwitcher.org, and QML based rendering solutions. -- Stefan
On Tuesday, October 19, 2021, Andrea paz via Cin <[email protected]> wrote:
These topics are very interesting to me, and I've tried to discuss them at other times.
@MatN The xml format of CinGG is specific and not compatible with that of other programs. There can be no interchange. Andrew has worked on the EDL CMX3600, but it is not fully functional and in any case it is too poor and obsolete (it was born for analog). Perhaps a feasible way would be to make the CinGG xml compatible with OpenTimelineIO (https://github.com/PixarAnimationStudios/OpenTimelineIO), but I have no idea how difficult it would be to create an "adapter".
@Stefan Since ffmpeg supports mxf in a basic way, there is an encoding preset available in CinGG; however, I assume you are referring to more advanced features such as timecode and metadata support, so that the SMTP standard is fully respected. Could you provide more details on what is required by this format and what is missing? Do you think it's possible to implement it in CinGG (which also involves implementing timecode and metadata)?
I hacked unconditional timecode output some time ago not sure how useful it is? I guess other metadata will require some gui changes. Cinelerra - CVE had something like this... (if I remember correctly) https://github.com/vanakala/cinelerra-cve/blob/master/cinelerra/fileavlibs.C === // Metadata AVDictionary *meta = 0; struct tm ctim, *ptm; time_t tst; char string[128]; av_dict_set(&meta, "comment", version_name, 0); tst = time(0); if((ptm = gmtime_r(&tst, &ctim)) && strftime(string, sizeof(string), "%FT%TZ", ptm)) av_dict_set(&meta, "creation_time", string, 0); if(metalist = asset->encoder_parameters[FILEAVLIBS_METADT_IX]) { if(aparam = metalist->find("copyright")) av_dict_set(&meta, "copyright", aparam->stringvalue, 0); if(aparam = metalist->find("title")) av_dict_set(&meta, "title", aparam->stringvalue, 0); if(aparam = metalist->find("author")) av_dict_set(&meta, "author", aparam->stringvalue, 0); } context->metadata = meta; ====
[PS: I saw that you are contributing to the AXIOM Beta/OpenCine project; what is the status of the project? I wish you all the luck! https://apertus.org/axiom-beta https://apertus.org/opencine] -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
It looks like there is support in ffmpeg. Do you think it's possible to read them all in "Resouces --> Info" and maybe be able to add more fields?
Interesting to know that Cin-CVE supports metadata. How does the metadata in Cin-CVE work? Can they be implemented in CinGG? For ffmpeg I found these links: https://ffmpeg.org/ffmpeg-formats.html#Metadata-1 https://wiki.multimedia.cx/index.php?title=FFmpeg_Metadata It looks like there is support in ffmpeg. Do you think it's possible to read them all in "Resouces --> Info" and maybe be able to add more fields?
Stefan, make sure that Cinelerravcan open and save MXF.
In June of this year, Andrew added 6 video MXF formats for rendering/saves
and 2 audio. You can currently read in MXF videos as I just downloaded and tested sample_1280x720_surfing_with_audio.mxf. MatN,
Just sounding out if there is interest in supporting these xml formats as import/export.
If someone has an interest in providing them, we can add them !
MatN,
Just sounding out if there is interest in supporting these xml formats as import/export.
If someone has an interest in providing them, we can add them !
Well, I had a visitor today who works quite a lot with Premiere and DaVinci. Apparently basic editing is done in one program, then the source files and .xml are sent to somewhere else, where e.g. they specialize in color correction. Then the modified sources plus .xml are sent back. This is facilitated because apparently they understand each others xml formats well enough. I am not sure how much of an issue this is for CinGG, I think DaVinci is the only one with a Linux version? Hence my question. MatN
I you have composed a timeline of multiple clips of several different sources, and it turns out that for one source extra color correction (or other effect) is needed, is there a way to select multiple non- consecutive clips on the timeline and attach the effect to all of them? Or do you have to select and attach clip-by-clip? The online help (alt-h) did not mention this as far as I could see. MatN
On Tuesday, October 19, 2021, mat via Cin <[email protected]> wrote:
I you have composed a timeline of multiple clips of several different sources, and it turns out that for one source extra color correction (or other effect) is needed, is there a way to select multiple non- consecutive clips on the timeline and attach the effect to all of them? Or do you have to select and attach clip-by-clip?
I found only one methodology close to this: https://www.cinelerra-gg.org/bugtracker/view.php?id=84 "Sam: "With larger video projects you want to copy several effects elsewhere without the corresponding clips." With the latest GIT checkin, this option is available. Use Ctrl-c to copy a single clip which has effect associated with it. When you use Ctrl-Shift-P on another clip, the effects will be pasted over that clip but not the original clip. I hope that makes sense." - should be in cingg newer than 2018-12-30.. but I hope 'attach effect' can also be modified to affect selected pieces of timeline (edits internally). Something to look into...
The online help (alt-h) did not mention this as far as I could see.
MatN
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
My understanding of the situation is as follows; correct me if I'm wrong. Pro editing programs work on interchange on two fronts: files, with their formats and folders and bins structure, and projects, with their formats and metadata support. CinGG is good for exchanging files and you can also decide on a folder structure that will make importing into other programs easier. This functionality is common to all NLEs, from the pro's to the simple ones. For projects, however, things are more complicated; there are different export structures for a project: AAF, used by Avid, of which a smaller subset is the MXF format. This format is not an EDL format, nor is it an XML format. EDL is a standard interchange format, but today it is no longer used because it is too simple and poor in features. Finally, there is the XML format that is used by almost all NLEs (including CinGG), but each in its own typical way of implementation. So there is incompatibility between the xml of a program and the one used by others. Let's move on to DaVinci Resolve: it was born as a color correction program; to do this in computers, offices and maybe even companies other than those that do video editing and other post-production phases, it has developed great support for all types of files and especially all types of projects in the various programs. Avid, Premier Pro, and Final Cut can also import, export, and handle various xmls, EDLs, and even AAF, but in general the simplicity and compatibility is better going by DVR. In general the most problematic type is xml because it's not standardized (that's what OpenTimelineIO tries to do using mxf). Nowadays, programs can do all phases of a workflow internally, including post-processing, conforming and finalizing. So there is less need for project interchange, especially in the amateur field. It's the way DVR has taken, incorporating all the possible needs of a pro production environment. We'll see if it succeeds (in my opinion it will!).
Phyllis, It looks OK, I just put in a pinpoint in the text below: Den 03.10.2021 02:44, skrev Phyllis Smith via Cin:
Terje, I will rename it README_appimage.txt which is what I should have done in the first place but it was new and I did not know how it would all work out. Below is what it will now say and if it looks OK to you, I will put it on the website tomorrow. Note that I left out any mention of cin.svg because now with AppImage, the source is no longer downloaded to the user and they would have to get it from the website src/cin...tgz file. You lose some capabilities with the AppImage, but the users who have been around awhile can find ways or do their own builds. ****************************************************************************************** AppImage is a software package that can be installed and run on various Linux distros. It has several advantages in that there is no need to install or compile software and no need to have root permission. In addition, no system files are modified and you can simply delete the software by deleting the AppImage file.
To install an AppImage, download it, make it executable and run it. It is a compressed image and contains all the dependencies/libraries needed to run.
1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it, for example ./CinGG-date-x86_64.AppImpage
ARCH requires install of the "libappimage" package. LEAP 15.3 (openSUSE) requires install of the "appimage" package.
***** Alternative GUI method to download provided by Leap 15.3 user *****
To run and integrate Cinelerra AppImage with installed "AppImageLauncher", follow the next few steps.
Build packages for AppImageLauncher (rpm, deb) to install are found here: https://github.com/TheAssassin/AppImageLauncher/releases/tag/continuous
On openSUSE Leap 15.3 (and hopefully somewhat similar on other distros) AppImageLauncher is integrated with Firefox.
1) Start to download the AppImage file, and the download Manager popups in Firefox with the option to open it with AppImageLauncher (instead of Saving). 2) At the end of the download a new popup asks to integrate it with your desktop system, so click OK. The AppImage installation directory is /home/user/Application by default, but can be changed.
This automatically is integrated with icons and in the Gnome app-menu.
------------------------- Terje J. H
Terje, OK, I have updated it on the website to be README_appimage.txt with you pinpoint change included. MatN, It definitely reloads the Cinelerra_plugins every time so that is a problem. On Sun, Oct 3, 2021 at 2:12 PM Terje J. Hanssen via Cin < [email protected]> wrote:
Phyllis, It looks OK, I just put in a pinpoint in the text below:
Den 03.10.2021 02:44, skrev Phyllis Smith via Cin:
Terje, I will rename it README_appimage.txt which is what I should have done in the first place but it was new and I did not know how it would all work out. Below is what it will now say and if it looks OK to you, I will put it on the website tomorrow. Note that I left out any mention of cin.svg because now with AppImage, the source is no longer downloaded to the user and they would have to get it from the website src/cin...tgz file. You lose some capabilities with the AppImage, but the users who have been around awhile can find ways or do their own builds.
****************************************************************************************** AppImage is a software package that can be installed and run on various Linux distros. It has several advantages in that there is no need to install or compile software and no need to have root permission. In addition, no system files are modified and you can simply delete the software by deleting the AppImage file.
To install an AppImage, download it, make it executable and run it. It is a compressed image and contains all the dependencies/libraries needed to run.
1) download AppImage file move from Download folder to your preference 2) make it executable chmod u+x {AppImageFile name} 3) run it, for example ./CinGG-date-x86_64.AppImpage
ARCH requires install of the "libappimage" package. LEAP 15.3 (openSUSE) requires install of the "appimage" package.
***** Alternative GUI method to download provided by Leap 15.3 user *****
To run and integrate Cinelerra AppImage with installed "AppImageLauncher", follow the next few steps.
Build packages for AppImageLauncher (rpm, deb) to install are found here: https://github.com/TheAssassin/AppImageLauncher/releases/tag/continuous
On openSUSE Leap 15.3 (and hopefully somewhat similar on other distros) AppImageLauncher is integrated with Firefox.
1) Start to download the AppImage file, and the download Manager popups in Firefox with the option to open it with AppImageLauncher (instead of Saving). 2) At the end of the download a new popup asks to integrate it with your desktop system, so click OK. The AppImage installation directory is /home/user/Application by default, but can be changed.
This automatically is integrated with icons and in the Gnome app-menu.
------------------------- Terje J. H
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (7)
-
Andrea paz -
Andrew Randrianasulu -
mat -
mnieuw@zap.a2000.nl -
Phyllis Smith -
Stefan de Konink -
Terje J. Hanssen