I think it's a pitty that you are twisting my words, turning the situation completely around and completely ignoring the gist of what I wrote. You now act like I missed your arguments? Which arguments? You didn't name any. And nothing concrete either. While you completely ignored the many factual arguments I gave you, with links and all, in my posts.

It confirms my point exactly. Unfortunately. Still expected more from you. Guess I got to know you better and the way you seem to think you need to operate. You are obviously the type of guy that wants to call 'red' 'blue' and then blame others they are critical about it and kindly ask you to call 'red' just 'red', like the rest of the world. And you call that innovating....

It's a shame.

This was the last thing I wrote here. I'm going to make my decision now. I have a very bad taste about this now and regret every effort I put into this.

Nate schrieb

Thanks for all the feedback! Feel free to continue discussion where we don't agree. By sharing our reasoning it's not my intent to shoot down your ideas, but rather to be transparent and allow you to make the appropriate arguments. If something is really better we'll do that, we just need to be shown why it's better. We're always opened to be convinced! If we don't have the bandwidth to get it done right away, we'll create an issue so it doesn't get lost. BTW, have you seen our roadmap?

You write a lot of text, but basically you're saying screw every consensus in UI/UX land for years. Can't see it another way than you are trying to re-invent the wheel for everything; tooltips, usage of alt, consensus on IN and OUT in computer software for animations not for video...

There's no point in discussing things that are standardised for years / since the beginning of computers. And we are totally on the different side of the spectrum when it comes to making decisions. I'm all for not reinventing the wheel, but follow the rules everybody is using, as it's frustrating for users to learn a completely different approuch for all software programs you use and things are not a standard without a reason; it took years for things to become standard and they became a standard because that seemed the best way in the end.

You seem to overthink every of these standards, making the interface different than other software and doing weird things like using alt as a toggle, but only toggling when dragging with a mouse. That's not only counter-intuitive, but doesn't make sense at all at how alt works since the beginning of computers and the standardised way every other software out there uses it.

You were asking in another thread (the unity forum) on my thoughts on the runtimes guide/api and you write here to continue posting thoughts. But what is my time and effort worth in posting things that aren't even special, but should be acknowledged as they are standards? And what is it worth trying to convince you of things that the rest of the world already is convinced about for years and/or picked a side on? It doesn't seem to matter how much concrete evidence/comparssons/examples of this I hand out to you guys, you are not open to it.

I love Spine and I think it's cool that people keep thinking about things, but this comes across as very subborn to me. The way Alt works in the graph editor is just completely weird to the language of UI/UX and in comparisson to other software using bezier splines with handles either for animations or vector graphics.

I'm sad that this is the standpoint of Esoteric software on UI decisions. But that's your choice and not up to me. I can only hope you're open to suggestions, but I don't feel like that when it comes to these important decisions.

I quit giving suggestions now, as when you're starting doing things so differently than other software around forcing users to be confused when using comparible software / other software in the same workflow and being frustrated to switch all the time (and us something this counterintuitive), because different packages work differently, it's a waste of my time posting this.

This is not personal at all, you seem like a great guy and I think it's great you put time and effort in being on the forum and supplying indepth answers that are really helpful. And I also like Spine a lot. But in the area of UI I guess being critical on in my eyes basic stuff that shouldn't be a dicussion, it just isn't working and it's not giving me a nice feeling. So that's something that obviously isn't working for me, so I guit doing that, as it's not coming across. Sorry.

Nate schrieb

4.0.24-beta is now available and brings separate keying of X and Y for translate, scale, and shear! It also allows keying RGB separately from alpha.
Spine: Changelog: v4.0.24 beta

Cool!

Using 4.0.26-beta here I only see one key-button next to these transform (I would expect this button to be split on X and Y) and when moving an x-keyframe in the graph on for example translate, y still moves along over the time axis. Also I only see 'Translate', 'Rotate' or 'Scale' as a property-row in the Graph or Dopesheet, not TranslateX/TranslateY etc. So far I'm not seeing buttons to sync/not-sync x and y in the UI neither.

So don't see a change really, but I'm probably missing something here?! How can we put keyframes on only x or y of the transforms in the editor?

Nate schrieb

As you explore the AnimationState and other APIs it would be interesting to hear if you get stuck or otherwise where we might be able to improve the documentation to give you an easier time. As much as we try, we can only pretend to look at it with fresh eyes!

So far nothing much, but I had/have some confusing about times though. I needed to tryout things in code to grasp the different timing values of TrackEntry though as the TrackEntry API-descriptions alone weren't enough for me to understand them. Mainly because it took me a minute to understand there are basically two time ranges: a 'local' one per animation, and a 'master' one per track.
To me it wasn't clear which method was using which range. It would be nice if that could be clearer or described in the guide.
(that said, I didn't read the full guide yet, so forgive me if you did if after TrackEntry in the guide)

At first the difference between 'local' animation times and 'global' track times wasn't clear to me just by reading the API. I'm working my way through the guide and jumped into the TrackEntry API as the guide skipped that (would be nice if there could be something about the important TrackEntry though?!). But so far didn't read anything about the difference between animation-related times and track-related times.
Would be an improvement I think if there could be something about that in the guide so at least we know there are two different time 'systems'. Also in relation to delays and timeScale, for one it has an effect on the time and for the other it hasn't. I only knew by trying it out myself and creating my own notes. But for others I'd think it's nice if that would be cleared up in the guide and the difference described better in the API doc.

Also I found the description in the API with animationLast confusing at first. Not only because it sounds like animationEnd, but mainly because as I believe the word 'apply' was used in the guide for animations to append them to the track. But in the description of animationLast 'apply' is related to the apply() method as I understand now.

The description now says:

The time in seconds this animation was last applied.

I think I would have better/earlier understand it and didn't have this confusion if the line was something like:

The time in seconds the apply() method of the animation was last called'.

I also don't get, still, why there is a different getter for getting the 'last applied' time in comparisson to the 'animationTime'. I understand now one is the current pointer in time (updated by update()) and the other one is the time when apply() is lastly called. But I don't really understand yet why we would like to know when the apply was last called. To me all these different kinds of times are both very handy and useful as well as confusing at first. Especially because of delay and timeScale affecting some and others not.

Than it's important to get a full grasp of how the system really works, so to me something like a graphic in the guide about this would have been helpful!

[edit] Another thing that keeps confusing me is when the API 'speaks' about 'removing animation from the timeline'. Like on the description of trackEnd inside TrackEntry, it says:

The track time in seconds when this animation will be removed form the track

But that keeps confusing to me. Eventhough I understand the animation gets removed from the track when done, I would
understand this better without confusing when the focus would be on the ending of the track, rather than the action that follows by that (removing the track), so would be something like

The track time in seconds when this animation is done and so will therefore be removed form the track

Not (yet) sure if this fits all situations though.

Hope this helps!

Nate schrieb

Lastly, for a new project you may want to target 4.0, as the Spine Runtimes will be ready and it will come out of beta in a reasonable amount of time. The new graph is a huge improvement and greatly increases animation quality.

Yes, I would very much like to use everything v4 already. I run both v3 and v4-beta in parallel and try to use v4 in my notes. But for runtimes that's a little difficulat as I'm using pixi-spine and it isn't compatible with spine 4 yet. I put a request there though, so hopefully in a while it's available!

Nate schrieb

There are API docs for the v4-beta here

Nate schrieb

we've added timelines for separate keying of X/Y and RGB/A.

Cool!

And thanks for the info on the forum-links.
Testing:
TrackEntry animationTime 8)

Having worked my way through the editor (both v3 and v4) I have a few questions and feature requests:

Please add a default framerate in settings
As I understand we can change the dopesheet framerate in the playback panel. I don't really get why setting is in a completely different panel and saved (?) per project. I find myself needing to set this setting on each new project, as I'd like to use 24fps.
It would be very helpful to me if there would be a general setting to set the default framerate for the editor players. That way new projects would have that default setting and only when overwritten by the fps setting in the playback panel we get a different setting per project.

Confusing location and incomplete name for fps
Also I think the term 'dopesheet fps' is confusing and not accurate anymore. As for instance in v4 we have the graph that also adapts this framerate. I'd call this setting something more general, like 'editor FPS'.

Please change Alt behaviour while moving handle!!!
For me this is the most important one, as I find this one pretty frustrating to use to be honest (by lack of a better diplomatic word ).

For me the way alt works on handles is unintuitive and even a little weird in v4. I understand with normal dragging at first we can move handles around while both handles of a keyframe remain in sync, so move along with eachother. That's clear to me.

But than when you press and hold Alt while starting to drag a handle it moves the handle without moving the other handle. That's also clear and intuitive to me.

But than it gets weird to me. As suddenly Alt wasn't an additional key to hold during the drag-action, but now suddenly has acted like a toggle switch. As from now on the handle is loose, even without having Alt pressed; if we drag the handle the sync with the other handle is lost forever, until we re-sync it again.

Which seems to be done by moving the handle again, but now together with alt again. So suddenly Alt has got the opposite meaning; namely to re-unite the handles again. To me this is completly weird and counterintuitive.

For me either of these would make much more sense:

• only drag a single handle when alt is pressed. If alt isn't pressed we always move/rotate both handles (much preferred!!!)
• have a toggle button to switch between loose or synched (is already there I believe, but not a very fast workflow on itself)

Using alt as a permanent toggle, so stays in a state after letting go of the key, is counterintuitive as the whole point of alt, shift and ctr-keys are that they need to be pressed together with other keys to do something. Here we never press another key together with alt, but just drag a mouse, and I never seen any software using alt as a permanant toggle in such a situation.

Please revert this while not everybody is used to this to me weird counterintuitive behaviour to: toggling SINGLE HANDLE on alt down and BOTH HANDLES AGAIN on alt up!

Please keep relation between handles while synching both
In vector software I use when moving one handle, with the other handle moving along (so synched), the relation/angle between both handles always remains the same. In Spine though, when moving one handle that was loose before, but than connected again to the other handle (synched), the other-side-handle jumps to be in line with the dragging handle, so loses the relation angle to the dragging handle.

To me this is unexpected and not what I want. I want the other handle to always keep the same angle around the keyframe in relation to the dragged handle. This works for instance like that in Affinity Designer; when moving a handle, the other handle always rotates around the keyframe with the moved handle so the angle between the two always remains the same. While synched. And when making the handles loose again we can change that angle between the two.

Is it possible to save looppoints?
In the editor we can set loop-points (in/out). Is it possible or would it be an idea to also save this in the file and export them to the json? I think that could be a very handy feature to animate something on screen and keep animating in a loop from the middle to the end of the animation.

Faster tooltips? Or delay setting for tooltips?
Learning Spine it's nice there are tooltips. But it takes a long time before they appear on screen, so I find myself waiting a lot for these, wondering if something's wrong. It gives the feeling the software is slow and that something is loading, eventhough I'm sure it's done on purpose to not block the view of people using the editor or whatever.

To me the tooltip-delay is way too slow now. I would like to set the delay to a much lower value. I can't find this in the settings though, the only thing I find is that we can turn it on or off. Am I missing something perhaps? It would be nice if either the tooltips would have the same speed as Windows tooltips in other programs (that's what I'd expect and feels natural now) or that we could set the delay for tooltips ourselves in the settings.

Thanks!

Nate schrieb

You can use TrackEntry animationTime (also see the other methods available). ...
track0.AnimationTime = 8 / 30f;

At this moment I'm working my way through all timing getters and setters in the API reference of TrackEntry to get to know them / learn them all in detail, and so I found this thread.

In the example you set the animationTime to a value. But according to the API reference on the Spine website animationTime is readonly. Am I missing something? Or is this a typo in the API reference, has something perhaps changed or is there something different when used in Unity specific? (I don't use Unity btw, but am a little confused by this thread)

http://esotericsoftware.com/spine-api-reference#TrackEntry-animationTime

BTW I see that recognised API-text on this forum wrapped with ticks automatically ads links to the reference. That's cool! 8) I wonder how you set the link on your animationTime inline code to the reference though.

Don't understand why this hasn't get any reaction yet. Your demo looks great!

Nice! Wish this forum had like-buttons; would definitely like this! Love this style!
This part of the forum is fun and inspirational too 8) ! Going to look here more often

Wow! Very impressive! Great work

Nate schrieb

The error can be ignored.

Nice! Great to know.

Nate schrieb

Newer editor versions (>= 4.0) read a different hotkeys file: ~/Spine/settings/hotkeys-x.txt where x may be 1, 2, 3, etc. This means there is no errors when going back to < 4.0 versions. We will bump the x number whenever we need to change hotkeys in an incompatible way, instead of reseting all your hotkeys like older versions. There can still be the issue of unrecognized hotkeys when moving from a newer v4+ version to an older but >= 4.0 version.

Great solution! Thanks again for taking the time to explain

Sinisa schrieb

Hello Friebel, let me clear the confusion

I don't think there is any confusion, but a difference of opinion. I see where you're coming from and it's absolutely great you've been taught by the companies you've mentioned and you are absolutely right to be proud about it. I know I would.

That said, I have a background and years of professional experience too, but guess it's pointless in pointing that out and I don't feel like doing that either. For me it seems difficult to reach and convince you, because if my last extensive post based on factual information about the industry Spine is in wasn't convincing, it will never be. I'm a little dissapointed by that and was hoping for a little more open mind and realistic look at the real market Spine is in. But it's completely up to you and your choice of course.

You seem to divide people into Animators and Developers though and you practically wrote you don't care about code. I'm very surprised about that and it felt degrading to developers.

Me, for instance, am both an experienced senior Animator/Illustrator/Designer and a Developer. And in the country where I live in and the professional work I did for both tv-graphics-software and internet in our country and abroad for many years, that combination is no exception at all. I'm sure the same counts for the game industry here. It even has a great adventage if you can do both. I don't know you at all, you are probably a very great guy and knows your job well, I don't doubt that, but your post comes across as if you look down on developers as an animator and I don't get that. Like in your world users of Spine don't think about code and should be 'pure animators', if that only exists, even though Spine is made for runtimes in games in the first place, so there are all kinds of users. I don't get that perspective.

Or that every programmer doesn't care or doesn't know a thing about animation. Like the book about animation. I really think in 2020 there are very very little people doing even the slightest thing in animation nowadays that never heard of that book or at least the 12 principles. Also UX/UI designers practise those rules in software- and webdesign nowadays.

To me it comes across as short-sighted, even a little arrogant to me. Maybe you didn't mean it that way, but that's what it feels like to me. I hope you could see Spine wasn't meant for video in the first place, but for the runtimes. That's at least what Esoteric always advertised with: games. And games are all about development meeting design, so there are all kinds of users using Spine, everywhere on that range.

Your post also gave me the strong feeling you skipped all my concrete examples of actual tools and market leaders of animation software in the world Spine is in and actual real life uses cases of animation used for internet and games Spine is made for upfront.

I get it that it's difficult to embrace another opinion about something we learned and used for so long. We all been there at one point. But I was hoping for a little more open mind.

I'm a little dissapointed by your answer, but let's just agree to dissagree, and I believe I was also a little harsh about it in my post, so can't blame you really. And Nate is right, it's only in the video's not in the UI, so that's cool.

But please, no more dividing upfront: animators are cool, illustrators and designers are cool, developers are cool! And they come in all sizes and mixes between the three :smirk:

Nate schrieb

In the v4-beta rotation in setup mode is 0-360, since that is what is needed to describe all possible fixed rotations for the setup pose. In animate mode rotation is not clamped to 0-360. You should be able to set the rotation by typing a number or using the rotate tool and it won't clamp the value.

Doing a quick test with a new file and just one bone (and now in 4.0.23-beta) I see it working too as you described. Not sure why it wasn't working the last time. I'm sure before posting it here I saw an animation being meant to go from 0 to 720 degrees as a flat horizontal line in the Graph editor and saw the textbox changing to 0 when I entered 720. I saw the Graph at that time so I must have been in Animation mode, I'd say.

Strange. But I can't go back in time to see what file I was in and in what order I did things. Well, I see it working now. If I see the strange thing happening again in perhaps some weird combination of actions, I'll inform you.
Thanks for your answer and info.

Trying to open an old file to change and save it with the same version of Spine by temporary running an older version of Spine (3.6.53) with the latest launcher (v4.x) throws issues with the hotkeys.txt file:

https://imgur.com/mX3IrTi

Nate schrieb

Hopefully that gets you back on track!

Thanks for the extensive answer.

The command line options are great! I have uninstalled everything Spine first. Needed to remove an uninstall 'Product'-key-folder from the registry though, because for some reason before the v3-launcher uninstaller was executed and uninstalled v3 from disc, but left keys in the registry causing Windows to think it was still installed. Are removing this 'key-folder' from registry Windows 'Add and Remove Programs' directly updated the list of installed programs and it was then gone as expected.

Then installed just one v4.0.12 launcher and created two shortcuts in the taskbar both using the command line parameter -u, one which starts the latest-stable and the other one starts the latest-beta. Both now have seem to have their own settings and it looks like they can run at the same time even. Don't spotted issues so far.

So great! Looks like it's working now. Thanks again!

Nate schrieb

Long story short, while you can install both launchers at the same time, there is no reason to continue using the v3 launcher. The v4 launcher does everything the v3 launcher does, but does many of them better, plus it can run v4 versions.

Sounds good, so I just removed the old v3 launcher and installed the v4 to a seperate folder for the v3-spine instead, so I have installed two v4 launchers. But now it has unexpected results.

At fist I got this error and the new launcher wouldn't start:

'An unexpected error has occurred'

log

Spine Launcher 4.0.11
Esoteric Software LLC (C) 2013-2020 | http://esotericsoftware.com
Windows 10 Home amd64 10.0
NVIDIA Corporation, GeForce GTX 1050 Ti/PCIe/SSE2, 4.6.0 NVIDIA 456.38
Launching: Spine 3.8.99 Professional
ERROR: Error running legacy Spine launcher:
Picked up _JAVA_OPTIONS: -Xmx512M
Spine Launcher 4.0.11-legacy

And now it doesn't matter which of both v4 launchers I run, both run the same Spine version. :upsidedown:

You gave me the impression I could install the v4 launcher double in parallel where one starts v3.x and the other starts v4.x and that I could have seperate and completely individual settings per launcher. But that doesn't seem to work and throws issues. So I am dissapointed.

Unfortunately this is taking me longer than I wanted and I have other things to do. I'm at the point of leaving the beta-version and re-install v3, even though I'd rather install both the v3-spine-stable and the v4-spine-beta to also learn the v4-spine-beta changes in the meantime. But if not possible I only want the stable v3 version installed. If I knew upfront it would be problematic to install both I would have never installed the beta.

I try one last time to ask my question and to be sure we don't have a misunderstanding here:
Are you sure both two v4-launchers can be installed in parallel on the same machine, while launcher A always starts v3-stable and the other v4-beta, while both launchers (or launched Spine versions for that matter) have their own individual settings stored, so there's no conflict?

If not possible no problem, than I just skip (uninstall) the v4-beta and return to v3-stable only. If it is possible though, that would be nice. But please, could you tell me how to do it without issues as described above?

BTW Affinity has a nice system for this; their betas are completely seperated from their stable versions so can be installed at the same time each with their own settings, folders etc.. That way more people start using the beta version as it is always safe to install and has no effect on the stable version. I thought Spine was doing the same, but that doesn't seem the case. Would be great if Spine would though as now it's holding me back to install beta versions to be honest.

I appreciate you guys on being on this forum to help people btw as you're probably very busy creating v4 at the moment. So thanks for your reactions. If not possible to install both, no problem. Than I just uninstall the beta and continue using the stable version. Perhaps I can install the v4-beta only on a different computer than.

Anyway,

Thanks in advance!

Nate schrieb

...

Interesting. You're right, there seems to be two camps. Just found this article having the same confusion:
https://medium.com/@gordonnl/ease-in-or-ease-out-ed9a0969042e

It looks like the difference between the two camps is

• A sees it from the perspective of curves/movement

IN is left, OUT is right (Google, CSS, Greensock, developers ...)

• B sees it from the perspective of keyframes/poses

OUT is left, IN is right (so the complete opposite) (Premiere fades, 12 princ. ...)

What I know for a fact is that all Javascript animation frameworks and CSS I used last years all work with IN at the start of a curve and OUT at the end of the curve. And animations are curve-focussed (type A).

Just take a look here for Greensock (most used animation lib there is on js):
Type A: Ease-In is slow at start
https://greensock.com/ease-visualizer/

Threejs (most used 3D lib for the web)
Type A: Ease-In is slow at start
http://learningthreejs.com/data/tweenjs_for_smooth_animation/tweenjs_for_smooth_animation.html

EaselJs/CreateJs (output of AnimateCC, former Flash, for HTML5)
Used as renderer for games on the web and output by Animate CC when building for HTML5.
Type A: Ease-In is slow at start

Here for CSS
Type A: Ease-In is slow at start
https://css-tricks.com/ease-out-in-ease-in-out/
https://easings.net/

Google Developers about UI animations
Type A: Ease-In is slow at start
https://developers.google.com/web/fundamentals/design-and-ux/animations/the-basics-of-easing

Flash Actionscript 3
Type A: Ease-In is slow at start
https://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl/transitions/easing/Strong.html

Phaser game lib
Type A: Ease-In is slow at start

Robbert Penner's easing equasions
Ported by developers to several programming languages and used inside animation libs.
Type A: Ease-In is slow at start
https://www.pinterest.com/pin/69454019234740420/

Broadcast graphics
Working for years with several graphics software programs (2d/3d from titles to full virtual sets) for broadcast industry (television, like game shows and sports), I've always seen and used type A in both editors and APIs.

Figma design software (UI with animations)
Type A: Ease-In is slow at start
https://uxdesign.cc/figma-5-ways-to-add-animation-to-your-designs-e3c521aa8902

Some random tutorials on UI/internet/games animation
Type A: Ease-In is slow at start
https://medium.com/motion-in-interaction/animation-principles-in-ui-design-understanding-easing-bea05243fe3
https://blazinggames.blogspot.com/2018/02/the-key-to-animation.html

But...

To my surprise I now see Premiere is not in camp A, but in camp B:
They look at it from a keyframe focussed way: LEAVING a keyframe (OUT) or ARRIVING at a keyframe (IN)

After Effects
Looks like After Effects is also in Camp B, just like Premiere.
https://helpx.adobe.com/after-effects/user-guide.html/after-effects/using/speed.ug.html#:~:text=Do%20one%20of%20the%20following,coming%20out%20of%20selected%20keyframes).

I just looked in DaVinci Resolve and they don't seem to use the terms, but only show icons of curves as far as I see it now.

conclusion for me
If I were to write animation-software that's extensively used for code, used by developers and used for internet and games, like Spine, I would choose for method A without a doubt, so IN is left and OUT is right of the curve, so focus on curves. Next to that I think it's most logical to think in curves, as that's at least how my brain works (my brain sees curves/movement and uses keyframes/poses to get those curves/movement), I think it's also best to stick with what other big companies and technologies in that market have chosen:
Google, CSS, Greensock, gamelibs, flash/as3, threejs, createjs etc. all chose type A (perspective on curves, IN is left, OUT is right) and the developer world seems to have chosen the same in general. I think that's the market Spine is in so to me that would be the obvious choice to go with.

Especially because when working with both Spine and Javascript or other animation code libs together it's very confusing to use both systems together. We want to have one universal way of using the terms and developer-world seems to have chosen type A. Otherwise when animating one thing of the project with Greensock and than animating with Spine in the same project would be confusing.

Another reason to chose type A: We always first say ease-in and than ease-out when we say both so it makes sense ease-in is left and ease-out is right.
I see that's also happening in toonboom (I don't own the software, but see it on their page). So it looks like they work curve-focussed too (type A):
https://learn.toonboom.com/modules/animatic-animation/topic/adding-ease-in-and-ease-out-to-a-layer-animation

Switching to terms like 'slow out' and 'slow in' doesn't solve this issue, as it's still using IN and OUT, and that's where the confusion is. Also, an ease-in can also be elastic or bounce and that has nothing to do with slow or fast.

Nate schrieb

Friebel schrieb

ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end

Note that you can have a transition that eases out and also eases in.

Yes, I understand. Then the curve has an ease-in-out. Or in libs like Greensock or EaselJs could be things like ease.backInOut or ease.cubicInOut.

Nate schrieb

It's coming in the next version, 4.0.21-beta.

There is some info about the beta and a video that takes you through the basics here:
Blog: Spine v4-beta: it has a curve editor!

Thanks. I've seen that video, very helpful.
There is a mistake in the video though: the voice over is consistently confusing ease IN and ease OUT. Around 7:15 he is talking about ease OUT, while he is showing an ease IN. And after that he says ease IN, while explaining ease OUT.
A curve always goes from IN to OUT, not the other way.

So ease IN is slowly at the start, faster at the end and ease OUT directly starts and is slow at the end. An Ease-In-Out both starts and ends slowly and is fast in the middle. It works like that in all animation software I know of, including js-libs, CSS, Greensock, After Effects, broadcast video editing etc.

I think it is too important to not mention this here. Please use the right terms in videos as for beginners watching this video and never worked with easing before, with this video they learn it the wrong way causing confusing and miscommunication with others when actually using it in real life.
He says it so many times consistently wrong in this little tutorial that I would advise you guys to re-record the video with the right terms to prevent beginners learning it the wrong way. It's hard to correct when learned wrong and used for years.

Nate schrieb

Is there a reason that you want to use the v3 launcher?

v3 launcher was already present as v3 was installed with it. Never got a question by Spine to update the launcher.
v4 launcher was installed because I asked you if it was possible to run v4-beta in parallel without affecting v3 and its config. And what I got from your anwer was that it was possible to install in parallel, because there are two different launchers not affecting each other. But maybe I misunderstood?

If there's a way to install both the stable v3 and the beta v4 in parallel on the same machine, completely seperated without conflicts and with each program using their own settings, with the v4 launcher, I'm happy to switch to the v4 launcher.
Is that possible?