Some variables have a value, even though the program hasn't been executed yet. A bit like Math.PI or even console in JavaScript.

VidSeq is the same, but how those variables are stored might be interesting to brainstorm...

Alright imma brain dump rq

These are the defaults btw, final value, 0s duration, linear easing.

The shortest.

subject -> { } 0s linear;
subject -> { } 0s;
subject -> { };

The original way of doing it.

over 0s, linear: subject -> { };
over 0s: subject -> { };
subject -> { };

With scopes and stuff - i actually quite like this, but it can be a bit difficult to understand. Especially considering that it looks like a control structure like if, for, while or until.

over 0s, linear {
  subject -> { };
};
over 0s {
  subject -> { };
};
subject -> { };

Buuut it also means you can do multiple transitions on different subjects with the same time, but tbh I don't know how often that happens.

The benefit of this, is that different properties can have different easings, but it can also be done on multiple lines... Idk

subject -> { prop(0s, linear): val };
subject -> { prop(0s): val };
subject -> { prop: val };

I like the idea of programmatically generating videos, like Motion Canvas (still in alpha) or Manim.

Thise are both frameworks or libraries, I wonder if I'd be the first to make a whole language dedicated for it. It sure would be interesting to see what kind of syntaxes arise for this specific use.

I quite like my old transition syntax, but I definitely think I should rethink the whole lang idea though.

So to start off with, I was thinking of having a tonne of imports, because imports are everywhere, especially in C-like languages. Python has imports, Java has imports, Haskell, C, C++, C#, Perl, JavaScript. Its tough to find a language that doesn't have imports. They're everywhere.

I might add imports in the future, if you want to define scenes in different files or something like that, but for now, I might keep everything together.

That being said, I wonder what a typical program could look like? How can scenes be rendered? Could everything be a child of a Scene object? That'd be useful, as transitions can be done on those scenes, and everything else would transition too!

Interesting.

So there are a bunch of events and things that I was thinking certain functions could use. Functions like while, until, if and unless.

The first two would make it make sense to think of these thingies as events, but the others would do better as booleans.

These are what I'm talking about:

LeftMouse, RightMouse,
ScrollUp, ScrollDown,
Key0 - Key9,
NumKey0 - NumKey9,
KeyA - KeyZ,
KeyEnter,
(etc.)

All of those are written in a way that makes you think of them as booleans, but you can also think of them as events - especially in this specific scenario:

// do something...
pause until KeyN;
// program continues after N is pressed

And, although I'm not sure about the specific pause keyword, I like this syntax - it's very similar to await in JavaScript. It also means you can pause while N is pressed too.

Buuut, it's like a boolean so while foo is the same as until !foo, and if I support not (!), I may as well support and (&) and or (|) too.

pause until (KeyN & KeyE & KeyX & KeyT) | (KeyG & KeyO);

Now that's great and all, but some bugs can arise if a user has the same key event for multiple pause-points. If you held down that key, the transitions could zip past really quickly. This can be resolved by doing something like this:

pause until KeyN;
pause until !KeyN; // or use while instead of until not

But I'd like to do some syntactic sugar and introduce a then (,) boolean operation (it's not really an operation, I just don't know what else to call it). It's certainly an interesting one, and it doesn't really make much sense for an if, but it sure does for a while or until!

pause until KeyN, !KeyN;

...does exactly as above but on only one line! I like it very much.

I don't know how I'll implement it though...

So there are a few variables that already have values assigned to them, like Background, Rect or Text. They are essentially just objects with default values and a native render function. They're called Elements.

Or at least, that was how I originally thought of making renderable objects.

They would be used like this:

let square = Rect { fill: #fff };

But now I'm not sure, it kinda makes sense, but then it comes with the idea of

let test = { x: 0 } { y: 0 };

being valid, and test would be an object with x and y properties.

Maybe I could use this syntax instead? Making it seem as though Elements are functions that create a new object?

let square = Rect({ x: 0, y: 0 });