Hype 5, the future, real projects!

Looking (quickly) at Lottie and Rive, I guess you never needed the complexity that hype has to offer. That is ok though. :slight_smile: I personally love the mirade of options Hype has to offer with its different scenes for example.
Say Scene one you have 5 buttons. No way of telling which button a user will press first. Now you can get complex with scripting or keep it simple and each button leads to another scene where this or that happens.
You can use Hype for much more then "just" animation, but that is up to you, the user.

My biggest wish would be an automated system to (evenly) spread out properties on a timeline. Dragging those 50 times out by hand when creating an animation with 50 frames gets frustrating at some point. :wink:

3 Likes

Prior to Hype 5, I hope there will be a call for version 4.5 beta testers. There was such for the v. 4.0 and it was a really great testing experience back in 2018!

1 Like

I'm not sure I exactly follow what properties (on a single element) you'd need even spacing with keyframes but wouldn't just use a single animation for the duration... Unless you mean staggering animations of the same property across different elements? But I do think there's theoretically interesting ideas of doing distribution of keyframes.

Can you elaborate on this or show an example where you did it manually? Thanks!

Sorry for being so unclear, I had a movie made a while back but couldn't find it yesterday. I hope this video makes it more clear I had to trim it down and I have no video editing tools other then quicktime here.

4 Likes

That seems like a job for some code :slight_smile:

Yes, very clear!

I had wanted to do a "stagger" but never thought about it in terms of the distribute/align tools before. Thanks!

Hi
I am happy to sheare my thought on the next version of Hype :wink:
Here a small list:

▪	Scene "programming sequence" see attached image to a better understood
▪	Layer with timeline in the scene, like layer in Illustrator/Designer
▪	Multilanguage string, when a proget need to be translate for different language (english, italian, german...), link to audio file related to the current language
▪	Having the concept of Object. Where an object is any element with own characteristic able to life in a slide/canvas, build a library of reusable object, where is easy to modify the object its self, drag the object from the library, object may have js code attached to him with parameters
▪	May be interesting to have "Super Object" like create a questionary, quiz, drawing canvas, checkbox, table, DB access, think on how may be useful using Hype to create a lesson/courses for an LMS like Moodle...
▪	Having button to stop/start/reverse/forward the aninimaton, or a control bar, like the control bar of a video player
▪	3d animation

:blush:

Ciao

Scene Programming can be done using the action panel. Only thing missing is a conditional block with nested actions or you need code.

I think the keyframe system needs fixing.

  • Changing a keyframe on any timeline affects the Main Timeline's state, causing significant frustration. This has led to hours spent correcting unexpected changes, such as opacity values jumping to 200% or other parameters breaking animations. This "helper" feature, reminiscent of Clippy, should be removed due to its counterproductive nature.

  • In timelines apart from the Main Timeline, the requirement to set the first keyframe is particularly complicated. Although relative timelines exist, there's an issue when, for example, an opacity change from 0 to 100 in a fadeIn timeline at second 1 occurs, but the main timeline's opacity is already at 100. This results in an abrupt jump from 100 to 0 at second 1 for the fade-in. It would be preferable for the timeline to consider the first frame as the initial state rather than inheriting it from the Main Timeline. This is something to discuss.

  • Auto-Selecting all keyframes on the first click makes us click once more to deselect (click beside keyframes) and the I need another click to select them again. Please remove the auto selection.

CleanShot 2024-04-09 at 09.56.43
Selecting all shouldn't be the default. Double clicking could select all. Single click should directly select what was targeted.

  • Implementing hold frames is a much-needed feature. When properties like innerHTML or Display are altered, these changes occur instantly without a transition duration. In many animation packages, such instantaneous changes are represented by a single square keyframe at the moment of the change.


Red stuff shouldn't be there

5 Likes

Oh yes, I can testify that this weirdness had happened once in a while;
in my case(s) I had experienced jumps to unexpected values such as minus 100% opacity @Daniel mentioned a while ago that other users had also experienced those weird jumps when fading in and out…

2 Likes

Yeah, it basically shifts all key frames by an offset. I absolutely hate it when this happens. I have not had an example where I found this to be a remotely useful behavior. It was discussed and addressed before as some quirky solution for some edge case, but the repercussions are still felt and should bring this to the forefront of reevaluation.

1 Like

Thanks so much for this list and the diagram of scene programming sequence! I think there definitely should be ways to examine the overall flow.

1 Like

Say for left/top -- when your playhead isn't on any keyframes and you use the scene editor to move an element, I'm curious to know what you think should happen? Do you have thoughts on how you'd like to offset something across all keyframes?

Hi Jonathan,

let's think about this: I want to avoid a situation where actions affect all other key frames and timelines, potentially disrupting previous work. It's too easy to make changes/mistakes in one place and unintentionally impact all others, leading to chaos. This recurring issue makes me question whether I'm not stringent enough in my animation effort or if there's a more significant problem, especially for beginners.

While I don't have an immediate solution, I feel strongly that I'd prefer to prevent these offsets from influencing parameters as a side effect on key frames I've intentionally set to a specific value.

So, let's fire up other animation software packages and collect maybe some feedback on how other animation packages handle this. I'll try to see what after effect does today.

Comparing Hype and After Effects

Okay, so I fired up After Effects… as seen in the video: Once a timeline is set to “record” (indicated by a little stopwatch icon for each property), any movement or change to a property results in the creation of a new keyframe. This approach assumes that creating a keyframe was intentional by the animator and there is no need for side effects. I'd go as far as to say animators would get furious if keyframe were to change as a side effect. So what about the case for positional adjustments (like repositioning an entire animation) after the fact? In After Effects, one would link it to a null object and move that null object (rebasing the offset).

Transferring this logic to Hype, moving anything would always create a keyframe if the timeline already contains keyframes (that fact acting like the stop watch intent in After Effects). So, again how do we handle moving an entire animation in such a scenario? Since Hype doesn't support virtual null objects, one workaround is to group an animation and apply an offset to the group after the fact, but this leads to nesting. Since groups are actual DIV elements and not virtual, this should probably not be the default case for handling the intent. In Hype, there should be an optional mode that translates all positional keyframes upon dragging (possibly with a modifier like shift-drag), limiting this behavior to the particular edge case of positional adjustments after the fact. I'd say for most other properties, there is hardly a case to be made that shouldn't just create new keyframes.

Another approach to solve positional offsets after the fact, if Hype were to adopt the After Effects approach, is how groups are decomposed. For example, if a layer with positional keyframes is grouped, moved, and then the group is decomposed, Hype adjusts the positional keyframes to reflect the new positional state post-decomposition. Giving us another way to reposition as a workaround. Sidenote: After Effects would simply revert to the original state without the virtual null object modifier upon removing a null object association. Although that difference between a virtual modifier and an actual one like a group, makes sense.

Thanks for your additional thoughts. A lot of tools like After Effects don't need to deal with many of the additional complexities of hype documents, including:

  • What to do when on an alternate timeline
  • Making new layouts where offsetting is a common workflow for a while

While using 'null objects' no doubt becomes muscle memory after a while, it is most definitely not an intuitive solution for offsetting. Many users coming into Hype (especially Standard edition) have never animated before. Once you get the fairly universal concept of keyframes, one could intuit that you can return to a keyframe to modify that position, use the add keyframe/record to make new keyframes, and then simply discover what dragging otherwise does. Dragging as offset at least looks pretty clear since the motion path indicator drags with the object. The goal would always be to never hide common operations.

There's definitely deficiencies with the current paradigm. Other options like keyframe vs offset mode would have their own frustrations as well. Hype's MO is to never do things like throw up dialogs or restrict UI access, as this is the primary way to get people to hate your software :).

At the very least I think some rough edges can be polished with:

  • fixing opacity-like properties as appearing to have numbers outside of their natural bounds
  • likewise fixing discreet values (like display on/off) to not always require 2 keyframes and just have state changes
  • allow choosing a base timeline when working with alternates so it is more clear where values may be coming from
2 Likes

Totally agree, I was just exploring the differences.

This might be big focus, but many power users would be happy to pay recurring to shift the attention and focus partly more on people using the software continuously.

Yes, but I believe the key issue is that exposing all modes simultaneously, leading to recording modes and free adjustment interfering, results in the unintended side effects, specially for professional users. I still feel that this subtle point is not fully understood, as my deliberate and intentional work has been altered by a programmatic side effect. Why has my alpha ramp, which initially ranged from 0% to 100%, suddenly shifted to 15% to 115%? That make no sense, to my animation… I wanted to fade something in. I maintain that, aside from a positional side effect for repositioning, no other side effect is really desirable, especially for beginners.

Okay I am repeating myself…

I would prefer not to see this at all. However, if it must remain, ensure that the offsets are not clipped behind the scenes, only in rendering and in the GUI. When you shift something back, you still want the original range and not to shift back clipped values (destructive).

That would be wonderful.

Haven't thought about that. I am not sure how that could be beneficial? Why can't every timeline be its thing entirely. Like a Main Timeline? At least for properties that have keyframes so we can still play multiple timelines at a time? Meaning the first value is unique to each animated property like in the Main Timeline. If you need it to originate from the Main Timeline or the current state, we have the relative timeline.


Thank you for the feedback and assumed progress towards a new release (I understand you can't comment on that) and for being receptive to the shortcomings of the animation side effects. If even a fraction of the accumulated feature requests from the last few years make it into future versions, especially in terms of extensibility :wink: I would be more than happy. There are some breaking changes I truly hope to see, such as the removal of HYPE_element_container logic, but I'm not too hopeful that will happen. Perhaps it could be a switch enabled for new projects only.

2 Likes

IMHO: This is the keyword for development.

1 Like

This is basically something I was looking for in Hype a "stagger" action. For example if your trying to animate the word "announcement" where you have every letter typed out on its separate layers and have one letter that's key framed you can make all the keyframes based on the initial animation, so if selecting all layers that don't have the animation then right click 'stagger' pick a layer to copy the keyframe then select offset seconds and it would automatically create the stager.

@Jonathan yes, no, maybe?

Yes, this is probably how we'd do it.

You hit it that the reason is due to initial values. Timelines are more like streams of animations. But when working with the editor, you need to decide what value you are going to display before there are any animations on a property for that timeline.

This is a good strategy :slight_smile:. There are some cases where containers are still required though (3D transforms to get perspective consistent, which is why they are there in the first place).

Scroll up :smiley: :

  • If there is no keyframe, the initial value is inherited from the main timeline.
  • If there is at least one keyframe, the initial value is the first keyframe.
  • If the timeline is a relative timeline, the initial value is whatever value it is when playing.
2 Likes