Defining frames with percentages

[Wikunia]

Is your feature request related to a problem? Please explain.
Currently it's not that easy to start with creating an animation with 100 frames and scale it to one with 200 or 500 frames.

Describe the solution you'd like
One way of improving up on it even though it's not directly THE solution to the problem would be the ability to define the frames using percentages.

Something like:

Object(5%:10%,...)

Unfortunately I think that this is not really possible to define it this way based on how % works and how a range works.

A possibility would be to do Perc(5:10) but this only works for integer values so finer control like Perc(5.5:9.4) doesn't work.

A way around this would be Perc(5.5, 9.4) but then it's quite different to what we have with Rel or the standard way.

Maybe you @ric-cioffi have some other syntax ideas as you mentioned this issue during the fourier example.

[ric-cioffi]

I mean there's not much to be done about the user selecting percentages that are not integer frames (there is really no 5.5 frame, it's either 5 or 6).
The way I did it in the fourier example was to simply round that to an integer, which I guess is what you were thinking of with your Perc(5.5, 9.4).

When it comes to syntax, you could specialize on the first argument so that Object(::UnitRange, ...) assumes those are frames while Object(::StepRange, ...) assumes those are frame percentages (exactly because it doesn't make sense to think of frames in non-integer terms).

An alternative could be to go even further and define your own FrameRange subtype of AbstractRange which can work with both frames and floats, specializes on relative vs. absolute, and can be passed to an object doing something like:

Object(1:10, ...) # assumes 1:10 are frames
Object(5.5:0.1:9.4, ...) # assumes 5.5:0.1:9.4 are frame percentages
Object(FrameRange(1:10, Relative()), ...) # assumes 1:10 are frame percentages

or maybe Percentage() rather than Relative()

[Wikunia]

Thanks for your thoughts. Yeah the problem I have with StepRange is that you actually need to define the step which doesn't make sense for frames because it should basically only define a begin and end. The FrameRange one is a bit verbose for me.

I'm actually currently thinking that it can be solved when using a macro I assume. Like
@Object(10%:15%, ...) or doesn't even pass this stage. I'll have to learn more about macros and stuff like that 😂

Okay it doesn't work with macros this way...

[TheCedarPrince]

I agree with what you are thinking about with the StepRange problem @Wikunia . One thing that I was thinking about was that the user never specifies a range smaller than one. Could we maybe provide a dispatch such that, for example, Object(0.32:0.5, ...) is understood to be a percentage range and that the default step is 0.01 (which somewhat takes from @ric-cioffi 's idea of providing a type of an AbstractRange type). What do you think?

[Wikunia]

The problem is that 0.1:0.2 doesn't seem to work but maybe I'm wrong. It creates a StepRangeLen not a StepRange

[ric-cioffi]

Doesn't it always create a StepRangeLen with Floats?

Also, one problem with doing 0.32:0.5 is that it always assumes the step size is 1.0 and automatically converts it:

julia> 0.32:0.5
0.32:1.0:0.32

I'm not sure how you could change that to have it a default step of 0.01

[Wikunia]

Oh yeah it's always StepRangeLen with Floats. Yeah the problem is the default size of 1.0. One can override Base maybe but that is not a good idea 😄

[ric-cioffi]

Yeah I don't like the idea of overriding Base, which is why I was suggesting a special type, but I can see your point about it being kinda verbose.
One option could be to still treat any StepRangeLen as percentages and direct the user to only use ranges in [0, 1] and to be specific about the step length (where you can error out if either both endpoints are identical or if one of the two endpoints is <0 or >1), i.e. saying something like this in the docs:

"You can access frames in relative terms by using ranges of Floats in between 0 and 1. Care needs to be taken about specifying the step length because julia's default step length is 1. Therefore Object(0.32:0.01:0.5, ...) is a valid syntax that will access all frames from 0.32*nframes to 0.5*nframes; while both Object(0.32:0.5, ...) and Object(5.5:0.5:9.0, ...) will both produce an error"

[Wikunia]

I'm actually thinking again about just using PFrames(32, 50) now as we have RFrames and GFrames now. The comma in my opinion is easier than forcing to define a weird step range. Maybe we can also support RFrames and GFrames to be defined that way if we want but keep the option of having them as a UnitRange.

[Wikunia]

I think we might find a compromise with #338 with something like

@Frames(0.5*global_end(), stop=0.75*global_end())

It's not the most fun to write but might be a way to not introduce too many other frame types.