Hi Nate, thanks for your reaction. Unfortunetely I get the feeling I should've written my post differently as you missed a lot of things in my post where I do exactly what you ask for: explain why and how I'd like to see it. That's unfortunate.

It's a pitty you think it's too much work to react to my posts and think it's wrong of me to compare Spine UI to other players out there with comparable interfaces. If things are built so differently in Spine than most things out there and decide re-invent the wheel to make things better than you might also expect users to bring it up when that's not the case in their vision.

If it's really 'our way or the high way' than I would understand a little better why there's so little reactions from people outside of Spine on this forum and no cooperative feeling IMO.

I understand that I'm not the best in setting the right tone to mention these kind of things and I'm truly sorry for that. I am just not good at that while staying honest and I value honesty and giving others the chance to change things. But I am not just complaining or complaining too much tho and I use this much words because for some reason here I always get the feeling I'm bumping into a wall and need to try very hard to explain why I want things that are normal in other software. Your reaction to my post now endorses this unfortunately.

I think it's a little too easy to think clients should just trust you in creating UI and users shouldn't mention concerns for new UI and just leave when they're not satisfied.

I want to focus on the content instead now, instead of on the communication, as that's not helping either of us I'm afraid and we have to agree to dissagree on some things.

Nate wrote

When you have a long animation, why would you want to see all the keys from frame zero to the end when setting keys?

I don't want to set keyframes when zoomed completely out. That would be unpractical as you write. I want to zoom out for all kinds of reasons as described in my last post. One of them is to have an overview and to have an idea of where I am in the timeline so to orientate. Another one I use all the time is to quickly go to a point where I want to go; zoom out to orientate, locate where to go, zoom in to get details. I'm aware of the auto-functions currently in place, and tried the hell out of them and really embraced them, but they somehow always do something I don't expect and they don't work for me. To be honest I'm scared now to tell you what I would expect as for yet another discussion and more complaining about user feedback.

Nate wrote

It uses a cookie if you check "Remember me". It could be your browser is losing that cookie.

Again: I am logged in, write a post, press submit. So the cookie is still there.

mumu wrote

I think so, too

Thanks, I appreciate your response!

Luke wrote

Hello spineappletree and mumu, I sincerely apologize that your questions were missed. I posted a reply a few moments ago requesting more information. I'll do my best to get some answers for both of your issues!

Thanks, I just posted a response.

Nate wrote

The normally scrollable area of the animation is from frame 0 to the highest frame in your animation. If you drag with the right mouse button, you can pan beyond the normally scrollable area. This should not be slow.

Thanks for your reactions.

The thing is that this way we could never set a keyframe further than the last keyframe we currently have and have to deal with this zoom issue EVERY NEW KEYFRAME when animating from start to finish!! It's extremely frustrating to not being able to zoom out further than to show the last frame. To me that's undoable. It's not very intuitive to need to drag to put a keyframe further away. I'm used to zoom out and place keyframes where I need to. I do that in other design- and animation tools, but can't do it in Spine because of a limitiation I don't get in the first place.

Nate wrote

The limit for zooming out is limited, as you found. With a reasonably small window size, I can see about 3,000 frames in the dopesheet, graph, or audio view, which share the same limits. On a larger screen (2560 pixels wide) I can see 5,670 frames. We need a limit since we have a slider for the zoom level.

IMO We need to be able to zoom out as far as we want to put a keyframe whereever we need it to be. I think having a limit on the zoom is unnecesary. Why can't we zoom just 'endlessly'? Just like other software, like Affinity Designer, Ableton Live, Davinci Resolve, Blender etc.. There I never ever hit any limit on zoom and zoom and pan all the time and feel completely free. With Spine I feel locked up in a cage that's way too small.

To me it doesn't make sense this is limited to a UI-control. I don't know about other people but I would never use a UI fader to zoom in and out anyway, it's just not intuitive to use. We either use keyboard controls like Ctrl-+/-, mouse movements with holding a key like shift or mouse wheel to zoom in with other software I know of. Especially because 90% of the time we would like to define the center of the zoom anyways to zoom from a location.

Nate wrote

We don't have a way to increase the zoom limit, if only because there aren't many people doing such long animations and no one has mentioned it. What actions are you needing to do when zoomed out so far?

Navigate. Enter new keyframes. Have a quick overview. Feeling free to do what you want and how you (creatively) want it without being imposed by the system or being limited by it.

Nate wrote

A workaround is that you can set the timeline FPS lower.

I'm sorry, but this doesn't solve things and make things worse. Not even as a workaround as we clearly need to be able to see the framerate as intended.

Sorry if this comes across as harsh. I like Spine very much, but I don't want to lie and want and need to work with Spine a lot. This is such a crucial part of the workflow and navigation. IMO the interface on zooming is just lacking the way it is build now IMO. After posting this here I found out what you wrote here; that we can drag past the last frame, but it's so unintuitive and just feels weird and as I wrote above, like being trapped in a cage, instead of feeling free, fast, in control and creative. I can't get used to it, it slows things down, it's a frustrating workflow and it's completely unnecesary IMO.

The same with limits in scaling of the viewport. I had trouble with it a few times where Spine just wouldn't let me scale out enouth to reach certain parts. It's just frustrating and completely unnecesary IMO. That seems like the exact same issue, which would, as I understand from your words, be solved then scaling wasn't limited by some UI control (that IMO nobody really misses when it would not be there, or at least could be build another way to not limit the rest of the interface).

I really hope this makes sense, will be taken seriously and really hope, hope, hope, hope, hope, it will change in an upcoming version!

Thanks!

[btw] Why do we need to log in on this forum each time we Submit a post, when we are already logged in?

Weeks ago I posted a question here. I see reactions to every other thing here, except for my question. Even after I bumped the question. It's not the first time I need to bump while other posts get reactions almost instantly.
I'm starting to feeling ignored and I don't like that feeling.

I understand people of Esoteric are busy, but they're not that busy as all surrouding posts get reactions. Also I'm used to other productforums, like the one of Affinity, where each and everyone helps eachother and reacts soon. Not on this forum for some reason I don't get. Especially knowing the amount of Esoteric personal is expanded the last period.

Don't get me wrong, I don't take this personally and I'm also clearly not the only one as I found lots of other threads here which never received any reaction by anyone. But It's dissapointing and frustrating not getting any response and it influences the experience on Spine if bumping to a wall each time.

Cannot reach wanted frame on timelines

At the moment I'm creating an animation based an a musical audio track of around 4 minutes.
Unfortunately so far I can't even manage to get Spine to move the playhead of timelines (both the Graph window as well as the Audio panel) to set a keyframe on what is the last frame of the audio.

When trying to move the playhead beyond the current view there is some scrolling, but it's so increeeeeedibly slow it's practically unusable.

Also when zooming the timeline fully out not all audio is shown in the Audio Panel (or the other timelines). These limits are way too tight for realistic use to create video animations, so I must be missing something here.

How to turn off these limits so we can reach these frames like other frames?

Thanks in advance!

BUMP!!

No slider, but in 4.1 there's a setting to turn off the delay entirely, and it's off by default.

Nice! 8)

Nate wrote

Sorry for the delay! I didn't forget, just needed to make progress on things so I don't get too far behind. When a post is time consuming to respond to sometimes I won't have time to handle it, but I still need to use my time here and there to help in other forum threads.

Absolutely no problem and completely understandable. I get it that you are busy and my post was also quite large. I was just wondering if you read it because we can't see that on this forum. Thanks for letting me know now and taking the time to explain where you are at and what your thoughts on this are in this great detail now. Also great to read that you thought about probable future plans for sequences too in the back of your head, so that's comforting to know for future compatibilty if things will be added or changed. Looks like we're on the same page and the way sequences are built in the beta definitely have a good place for usage too.

I'm very looking forward to these physics too btw. Seems like a great new feature! And will checkout the changes to the curves.

Keep up the great work and have a nice day!

@Nate Thanks for your extensive reply. I wanted to react sooner, but couldn't find the time, needed to let it sink in, testing and taking the time to form a response that is hopefully helpful to you.

Nate wrote

It would be possible to represent sequences completely differently. Instead of using FPS, keys in the dopesheet would control which frame is shown, as you showed above. This is interesting and I agree it would be powerful, but it would take away some of the simplicity given by specifying the FPS.

I hear you and you bring up valid points and giving me great inside in why it is build this way in the beta. Another point against my proposal I can give is that with many frames the graph can get very high quickly. This would probably never be an issue on projects made for runtimes I would expect, as these are probably always build to load quick, especially online. But projects with animations for video might use sequences with a lot of frames though, once people see the benefits.

I think both ways have easy parts and tedius parts. One isn't easier than the other per se, it's just a matter of the use case. The way it works now is indeed easy when we treat the sequence as a player and count on all sequences to be completely prebaked and not used (much) differently; we have play/stop/loop/pingpong/reverse etc and can change the framerate. But when we want to do more advanced stuff and want to treat the sequence as a creative resource to creatively play around with and manually control, it can get complicated fast.

I think it's safe to say lots of Spine users got pretty advanced creative results from Spine and could do that because tools can be manually controlled. I don't believe many people would have thought people would come up with even 3d-looking animations this good for example.

So to assume people would only use sequences for simple playback of prebaked frames is a oversimplification IMO. Not saying that you do simplify this though, as you made that clear in your post and I understand where you're coming from. I'm just a little afraid that the chosen way is too short lived, too simplified for what people really gonna use it for, too limiting and that we soon more users will find out that it's not convenient to do the stuff we'd like to do with sequences.

Than we are building Spine files on a system that soon will be seen as too limited and than it's hard to rebuild it because of compatibility issues etc. That's why I post this while still in beta.

Spine users come up with the craziest creative results, people would not even think would be possible before, just because they have the tools to do so. I think it would be an oversimplification to think users would only use sequences to play a pre-baked animation. The real power is in the control. And only when the control is there great things can happen.

To illustrate this watch this simple real life example; scaling the animation doesn't scale the sequence:

https://youtu.be/CAVzc3ohPVk

I think we agree there are two ways to look at this. As you rightfully pointed out. I understand your view on it better now and agree with you that both ways have pros and cons and in an ideal situation we could either find the right balance or switch to one of the methods, depending on the use case.

Nate wrote

Our goal for this feature was to make an easy way to bring in image sequences, such as those for VFX. Typically those are created with the intention to play them at a particular FPS.

What is 'constant speed'? What will a runtime do with animations in general when the framerate drops? And what will it do with the framerate of sequences when that happens?
- Will Spine animations slow down? Or does the animation keeps its speed, but skips frames to stay on time?

• How about the frame sequences? Does the sequence keep its speed, or skips frames to stay on time?
• Do both keep their sync to each other?[/b]

If a sequence slows the animation down on slow computers, but the sequence is skipping frames instead, or visa versa, the animation goes out of sync and that could cause problems when the sequences are intended to be synced with the 'bone animations'.

Nate wrote

Previously, bringing them into Spine meant setting a key to show each frame. While this gives complete control over when frames are shown, it is quite tedious. With our sequence implementation in the 4.1-beta, it is now very easy. We've wanted this feature since we released Spine via Kickstarter, 9 years ago! It looked like a good feature to get into 4.1, as it wouldn't take too long (spoiler: it was harder than expected).

Yes, we can do it the old way. To recreate the example above like this:

https://youtu.be/ZgGXCcbj8bg

But than it could be even easier to program everything ourselves in the host of the runtime and the whole point of the Spine editor is that we can animate it in the editor right?

It's definitely a way forward in the beta. I am only a little scared that we will start building projects with this new system, which IMO is difficult to use for real life use cases when wanting to be a little more creative besides just playing of a completely pre-baked animation. And yes, I understand that there might be difficulties in framerates when scaling it down. But that's up to the animator to judge IMO and I'm pretty sure people will come up with the craziest new creations just by having the tools, we cannot even predict yet.

I see Spine as an animation editor and think it's safe to assume some people like to animate in Spine. Also sequences. Especially because that might help us keeping the amount of frames needed small and be creative with it. To treat sequences as a player with a framerate is too limited and assumes the use case too much IMO.

Nate wrote

If we had only your proposal, it wouldn't meet the simplicity goals for the most common use case, which again is to play a sequence of images at a specific FPS.

I fully agree that when just wanting to just play a sequence (start / stop and think in frame rates) the chosen path is the easiest. But that's pretty limited. If we even want the slightest do more advanced stuff it gets complicated fast. So I think the simplicity is depending on the use case.

Nate wrote

BTW, for some loosely related if unrequested bonus information, and to anticipate a possible next question of, "if we stick with FPS, why don't we allow it to be interpolated":

Sequences are controlled by a framerate, eg 12 frames per second (FPS). Currently the interpolation between keys for the sequence FPS is stepped. With a constant FPS between keys, we know at 12 FPS after 2 seconds we are showing frame 24.

How would linear or Bezier work? Eg if I'm going from 1 to 10 FPS over 4 seconds, with linear I know that at 2 seconds the FPS would be 5.5. That's OK, but what frames do we show between the keys? If we use the interpolated FPS to show the frames, the frames will appear to change faster than the intended FPS. I've made an animation to show what this looks like:

Sorry, I don't get the animation you posted with the numbers in it, but I do understand what you mean and of course you are right that easing isn't as smooth (when not done well). But IMO you're assuming too much now for the user:

• What if a user is having a sequence with a higher framerate than the actual animation and the runtime skips frames to match the actual framerate of the animation? Of coarse, if not an integer factor of the actual framerate things don't line up, but that might also be used as an effect for instance and there are ways to make it work too. IMO not even giving the tool to the creator is an oversimplification and thinking for creative people. People come up with the craziest ideas and effects we cannot predict. And even on tv and films a lot of VFX even were invented by 'issues' in technical systems (like the neverending loop of picture in picture because of feedback loops in a video mixer for example).
• It's never sure at what framerate animations plays in the runtime and framerates might drop on slow computers/phones etc.. As stated above; How does the runtime treat sequences vs bone animations when this happens?

BTW, your example gif of the numbers running is an excelent example of a great use case for easing. I can think of ways that are really interesting in animations when animating counters for instance that need to slow down with an ease in the end.

So this long post in short:

• I fully get where you're coming from and I agree my proposal isn't the only way and both ways have pros and cons.
• I understand having a way to play a sequence is better than nothing
• I agree that it's simple to use like this when treated as a player of pre-baked animations. But when needing more control it's getting complicated and frustrating IMO soon; preventing innovation and creative use cases to happen IMO.
• Please don't underestimate Spine users and assume users want simplicity over full control
• Please keep in mind people come up with the craziest ideas and use cases we cannot even think of, once they have the tools
• Hope you could consider the above before launching the system as is. Because once it's out there it could cause compatibility issues when wanting to change later.

I think the best way would be something in between or having both worlds, like you also seem to think. And some things you see as challenge can be solved, like things that auto calculate for you.

But I think the real questions are:

• do we mostly focus to create tools for simplification and limit based on assumptions, or create tools that are easy to use for more advanced users to give users full control? Or else: how could we have the best for both worlds.
• do we launch sequences quickly because now we don't have anything else for that yet and it's nice to mention in the changelog and blogs, or do we rethink the system further to be sure we don't have compatibility issues when needed later?

These are questions only you can answer. I can only hope. Hope this makes sense and you understand I get your points though.

13 jan 2022:

Hi @Nate, it's been two weeks ago since I responded directly to you on the forum but so far no reaction from you here. I see you react daily here and also see you react to forum posts with the message that you missed posts.

Just to be clear you didn't miss this one, as I took the time to test things out, upload a video and respond: could you let me know if you read this post and what you think of it?

Thanks in advance!

Nate wrote

It does, you just need to be creative with how you move the views. Move the dopesheet view into the bottom of the viewport area.

Cool! I wanted to have the exact same panel layout. Great that it's possible! 8)

Erika wrote

I think what you are suggesting is already covered well by the seqeunce properties that are keyable in Animate mode.

Sorry, I dissagree. That's why I took the time to write this feature request and explained why in details. Please re-read the post, it's all in there.

Attaching images can't really have a timeline, because it's more of a boolean option (e.g. an image can be turned on or off) there are keyable settings for the frame by frame behavior that can be changed during the animation for better control (the frame rate, loop, ping pong, hold, etc), but imho this looks incompatible with the graph.
But perhaps the others have a different opinion.

I'm surprised by your strict tone.
You are talking to a developer here. The timeline values handles doubles (values like 6.9). But frame numbers need to be integer values (so values like 7). To show the right frame number is just a matter of getting the integer value from a float value (for example 6,9 will be fr 7, but 6.4 will be fr 6), that's really the only 'challenge' as far as I could think of. How to do that could be discussed about, but nothing too crazy about that, pretty basic stuff on itself. If only there is a will to understand why I am asking this, which is all in the post above. And a little openess to take a minute to see the perspective of a user who doesn't open a feature request and takes the time to explain himself because he has nothing else to do.

I would however suggest you to look better at the properties cause playing in reverse (just to quote an example) is already possible and very easy to do without having to meddle with the graph.

Hey, why being so offensive and pointing with your finger? Like this on me you come across as if you think you have all the wisdom in the world and you see the only truth. Relax. I would appreciate it if you were just a little more open to other professional opinions, don't underestimate who you have in front of you, be a little more customer friendly and if my post isn't clear, just ask.

If the door to give feedback while the software is even in beta is already closed the only thing you might accomplish is that people don't feel appreciated and heared and stop giving their opinions. If that's what you want than just tell me, than I understand it's 'take it, or leave it' and we as users have nothing to say about that and are not allowed to give input.

I'm trying out the beta version now to get to know the sequence feature. Which I really like btw! Great addition to the software, very useful and yet another 'small' feature with huge amount of possibilities! 8)

The UI to animate sequences now is a completely different thing though. I find it unintuitive and I don't understand why the beta has a workflow to animate sequences that is completely different in comparisson to animate every other property in the graph editor. The way it is build now doesn't only feel unintuitive to me, it's also causing things to not be possible.

Workflow for other properties:

• values over the y-axis
• timing over the x-axis

Workflow for sequences:

• no values visible in the y-axis, everything on the same y-level
• x-axis doesn't show timing the same way, now only shows a representation of the framerate

This is how it looks now:
Everything is on one line in the graph and no handles or other known features:

Because of this workflow we can't do now:

• Speed up or down a sequence with easing by moving handles, like how we can animate other properties
• Hold keys /switch to linear curves / switch to bezier curves. Which is such a great interface with many possibilities
• Play a sequence in reverse (which for some sequences literally makes us use half the resources in runtimes)
• Immediately see in the graph at what frame the sequence currently is at
• Set the sequence to an exact frame-number on a position on the timeline

Expected alternative
Why not use the proven workflow instead to animate sequences? Like so:

That way we could:

• Speed up or down easily with visual representation in the graph editor
• Use easing exactly how we want to by moving the handles of a bezier curve
• Switch to linear 'curve' if we don't want easing
• Switch to hold keyframes if we want to jump to keyframes
• Easily and exactly play the sequence in reverse
• Use exact frame numbers and have a visual representation of exactly on what keyframe the sequence is currently at
• Jump around in the sequence with no problem as we have full freedom in the graph editor
• Use the graph editor for what it is: a 2d graphical editor, and use both axis and all features we are familiar with!
• Only need a single timeline; the one for framenumber (instead of an additional fps timeline as it looks now)
• Use drag'n'drop and selections as expected
• So basically work like with the rotation timeline; when a frame number exceeds the max frame number it just goes round, just like the rotation passes 360 degrees and rotates around from 0 degrees again. So if we put a keyframe at 30 frames in the timeline to go to frame 200, while the sequence only has 50 frames, it loops a few times

Please reconsider the interface to animate sequences. IMO it gots too many limitations now, is lacking ways to do advanced stuff and is counterintuitive IMO, because it's so different to the rest of Spine's graph editors workflow. It also doesn't look very scalable for future features.

Thanks for considering!

Nate wrote

Great, glad it's working as it should now! No problem, glad to help. Most of all I'm glad we don't have any AnimationState bugs to fix.

haha, yeah, that's a stroke of luck!

Misaki wrote

Unfortunately, transform values don’t allow constraining X and Y values for now.
Your suggestion definitely has a point, so I added an issue ticket here:
https://github.com/EsotericSoftware/spine-editor/issues/618
You can add a comment if you have anything to add.

Thanks! Highly appreciated!

Misaki wrote

Regarding handles, the steps you wrote are the correct steps for operating multiple handles at the same time for now. There is no way to automatically select the handle of another axis.
We have received many requests regarding easier ways to adjust or match the shape of curves, and we are considering and discussing various solutions. For example, a change that explained in the following post have been implemented recently:
4.0 Graph editor gives me anxiety

Some of the ideas that we have already considered may be able to solve your needs. I'm afraid that I can't give you a more detailed response yet, but I hope you'll understand that the graph-related improvements are in progress.

That's great news! Looking forward to these new changes! 8)

Misaki wrote

We really appreciate all of your feedback!

Same. Thanks for the quick and helpful response!

Hi Luke! Nice to see you as a new member to the growing team and extra hands with the support and runtime development!

After working my way through Spine events intensively for the last days and creating a test project showing all events and when what fires, my conclusion is I probably either made a mistake somewhere in the old code of the project I talked about in this thread (before I renewed it), or it was my lack of complete understanding of the event system at that time (for instance the fact that complete events DO fire when mixing, but custom 'last-frame' events are not per default, which was confusing to me). While doing tests with the created events test demo I always saw the 'last-frame' event being fired when not currently mixing, so it worked as expected in the test/demo.

I'd say this one can be closed. Thanks again for your help Nate. I appreciate you taking the time! This week I definitely learned a thing or two about Spine events and that's valuable! Keep up the great work.