Andrea, a few answers below. This just seems confusing, but we should have done this initially when Andrew-R supplied the patch. 1- how to do if you want to compile the 8-bit version?
I would change the section "Multibit build for x265-8/10/12-bit" to note how to compile the 8-bit only version. Although I really do not think anyone would bother to do this. - cd /path_to/cinelerra-5.1/thirdparty - edit the file "Makefile" using the # character at the beginning, comment out the line: x265.cfg_vars?=chmod +x ./configure; chmod +x ./multilib.sh; - then the next 2 lines should be uncommented, that is remove the # sign at the beginning #x265.cfg_vars?=$(call cmake_config,source) #x265.cfg_params?= -DENABLE_SHARED=no -DENABLE_CLI=no - delete or rename the 3 patch files in thirdparty/src (they will be something like x265-xxxxx.patchx)
2- Do the appimages reverse their names? multibit --> new std; old std --> 8-bit?
The CinGG-20230131-x86_64.AppImage name will remain the same, but just will now be the multibit version. The CinGG-20230131-x86_64-multibit.AppImage will no longer exist. I am not going to bother creating an 8-bit appimage as it just seems unnecessary. I will just leave CinGG-20230131-x86_64-older-distros-multibit.AppImage as the same name to avoid any confusion. Also, while you are at it, could you update the date on this appimage names? so CinGG-20230131... would be CinGG-20240630, etc. just so more up to date.
3- Will the einhander repository continue to have only the std version (which will be the multibit from now on)?
Yes, einhander version should now be automatically built as the multibit version because he uses the GIT checkin. Also, please delete any references to CinX in the manual as it is irrelevant.