Command length and general user convenience

I think we’ll have to drag this issue in the open and properly discuss it, rather sooner than later.

Right now the code supports a wide range of arguments for some desired parameters. For instance using medium quality. -m -r medium -r 720,1280 (although this would default to 60FPS, not 30) --medium_quality --resolution medium

Personally I’m fine with that. It’s not like this is adding over hundred lines of code, when reading the code it’s easy to isolate and skip these areas, and the performance overhead is almost certainly not even anywhere near being measurable.

Now we have people like @huguesdevimeux who are for cutting down some of that (#64), with which I could live. Although I think that’s not really necessary.

We also have @eulertour with statements like… this here on my current PR:

At some point these should probably be merged into a single --render_quality flag which takes 4 arguments.

Let’s also make properly clear what’s at stake with decisions like these. Currently, and particularly with my pending constants.py changes we can drive manim like this: manim project scene -psm I like it that way. When working on my projects I usually have to re-render stuff a lot, and for very different reasons, so using it like this I often switch the m for an l, or remove it, or, now with the new changes, add a k. I can quickly get manim to get me what I need.

On the other hand it sounds like @eulertour is more in favor of enforcing people to have to use manim like this: manim C:\FullProjectFolderName\project.py scene --media_dir D:\SomeOtherProbablyNotSuperShortAbsolutePath --preview --save_last_frame --render_quality medium

Now I don’t know about you, but for me, that there is just ugly and panic inducing in the extreme. I unironically estimate that if I always had to use manim like this then my recent video would’ve probably included a couple real extra hours of work, solely dedicated to writing out and copypasting commands. Please, for the love of deer goats, let’s not go there. Yes?

If anything, manim is tool. It’s code is there for us to create something that is as powerful and convenient to use as possible. We should never sacrifice even the tiniest bit of either of those unless there’s substantial gains for the other we can’t get otherwise. I’d even argue we should add the ability to define FPS in the arguments as opposed to having it only tethered to predefined qualities. And maybe add an addition to not just start at a specific animation but also end at one as opposed to always rendering through to the end.

Thoughts and opinions?

[XorUnison]

I gotta admit, when I read it I did feel it was kinda aggressive… but glad to see things are working out between you two… I think?

We’re fine as far as I think. Talked it over on Discord, and as I said there, no offense was meant by me.

Anyway, about all of this… (there’s just too much to quote one part) I’m in favor of reducing them all into one -r flag. We can just have something like -r m and that’s it. That’s adding 2 characters, and might even be clearer than before. --render_quality would just be an alias. (We need at least one alias. Come on!)

That’s my opinion

Yeah. -r x wouldn’t make any real difference to the shortest use I can think of and if anything would make it easier because we’d have all 26 letters free for resolutions after an -r (or q or whatever, though I’d stick with r). The more I thought about this, the more I shifted towards being in favor of that. We could also see about making some of the letter assignments more fitting maybe, if we completely remove m/l/e/k for resolutions and instead refer to -r for that.

[leotrs]

@XorUnison thanks, ammended.