On 10/28/26 1:26 PM, Sam via Cin wrote:
Hi Rob,
welcome back, and thank you for this careful mail. Your concerns are fair, so let me go through them one by one.
What you see today is an alpha. Not everything is ported yet, so some things you rely on may still be missing or behave differently. That is exactly where reports like yours help us.
using appimage (CinGG-qt6-alpha-20261027-anylinux-x86_64.AppImage)
Windows on two monitors. The timeline is the main window. Every other panel (Viewer, Compositor, Resources, Effect Inspector and so on) is a dock that you can tear off into its own top-level window: drag its title bar out of the main window, or double-click it. Then put it on your second monitor. Window > Save Layout... keeps the arrangement, and Ctrl+Shift+F1 to F6 bring a saved layout back.
As long as the Qt MDI interface is used and floating windows are "children" of the timeline window I think it will be problematic for me. Upon testing I can only "move" a floating window once (when I pull it out of the timeline window) then afterwards it only responds to resize events. Also, child floating windows are not allowed to be "behind" the main timeline window which makes it too easy to accidentally merge the floater back into the timeline panel and screw up the timeline layout panel. I really do prefer separate/independent X11 windows for each function. using openbox, xorg, and nvidia-570.207 driver. in twinview config when I'm editing content, and xaphod config any other time
Pretty versus power. Agreed, and that is why the keys came first. Another step in that direction is in the works: a remote control through which scripts and AI assistants can drive Cinelerra, every command and every effect, each step undoable. It is not in an AppImage yet.
You had me until you mentioned AI. Long passionate anti-AI rant, so I'll digress. re - color scheme: just bring up the global configuration screen over top of the main app MDI panel and it's pretty obvious that something needs to be done to make the popup more distinguishable from the background.
Audio tracks drawn only half way. To reproduce it I need a few details: was it the traditional AppImage from August or the Qt6 alpha (and which date), what kind of clip (container, codec, length, number of audio channels), and at which point the waveform stops.
It happens with pretty much every media clip I load, upon first load. Once the thumbs exist in .bcast5 directory the clip loads properly upon subequent tries. If I delete the indexes and thumbs then it burps again. I've tried with both you-tube content (av1/opus/matroska) and with h264/aac content. Latest august (traditional UI) cingg does not suffer the problem, just the Qt appimage I tried listed above.
Build. Please tell me which repository you cloned (the traditional git or the Qt6 one), the commands you ran, your distribution and compiler, and the last 50 lines of the output. If it was the Qt6 repository built with CMake: CMake has a recursion limit that the Qt6 deployment helpers can hit, and running cmake with -DCMAKE_MAXIMUM_RECURSION_DEPTH=5000 is worth a try. origin is: https://git.cinelerra-gg.org/goodguy/cinelerra.git
last pulled commit (HEAD) was: commit 3a30a189bfda351205615618fc2b206901bb6934 (HEAD -> master, origin/master, origin/HEAD) Author: Good Guy <good1.2guy@gmail.com> Date: Tue Oct 20 10:59:07 2026 -0600 Credit FFmpeg team and Andrew for patches for FFmpeg 9.0.2 generated standard configure program and ran with all defaults uses traditional gmake debian13: gcc 14.2.0-19 no output available because I deleted all artifacts and "git clean" on local repo after failure. build ran correctly. It was the install to /usr/local that barfed.