Guest
home
beatmaps
rankings
community
store
help
forum
  1. Forums
  2. osu!
  3. Development
  4. Feature Requests

Address SB Timing by Beats instead of Offset

posted
Total Posts
11
This is a feature request. Feature requests can be voted up by supporters.
Current Priority: +0
vytalibus
osu! Alumni
870 posts
Joined May 2008
Topic Starter
vytalibus
As it stands, storyboard elements rely on offset for their timing. It would be easier if they follow something like "3:3.1/4" (Third stanza, third beat, first tick in the 1/4 divisor).

Why change the timing from offset into beats?
  1. It makes fixing SB timing easier. Especially in complicated storyboards, it's such a hassle if a timing issue is found. At worst, it can ruin the whole storyboard. With this kind of addressing, fixing SB timing won't be such a burden.
  2. It makes loops more functional. Loops are SB elements that follow a rhythmic pattern of repetition. While handy in case of flashes and such, the way they are constantly timed via offsets actually makes them less useful. What I'm talking here is how maps follow the BPM in "running" the notes.
    Here's a detailed explanation:
    SPOILER
    The coding used here is:
    Sprite,Fail,Centre,"<filepath>",320,240
     L,3189,207
      F,0,0,261,1,0
      F,0,261,522,0
    The map runs at 115.00 BPM and has an offset of 3,190 ms. To really see the result, replicate these information on a blank map, and use an image to replace <filepath>.

    This is the start of the loop:


    This is near the end of the loop:


    As offset is used to "replicate" how long a repetition of the event is, it is only added to the runtime offset of the map. It is evident in the second image, however, that the constant addition of this offset does not match with the ticks on the timeline, resulting in an off-sync loop.

    I must tell you that "261" and "522" are the offset length of the events, and are the CLOSEST I can get. Even a minor fix such as +/-1 on either/both values makes the loop even wonkier. Try it out and see.
  3. It basically makes storyboarding easier by itself. Mappers who code storyboards will find it easier to add elements using this kind of addressing. No more trying to figure out how much offset constitute a beat.
Hopefully I am understood.
Fuuko
486 posts
Joined June 2009
Fuuko
+1 support, really.

It's hard to change offset at complicated SBs, when I find out that the timing wrong. ;_; The same goes to loops.
Derekku
COOL DUDE
7,270 posts
Joined March 2009
Derekku
inb4osq
awp
osu! Alumni
11,869 posts
Here since the beginning
awp
I can see why you'd want this, and it makes sense, but I would rather it not replace milliseconds, and instead be an alternative (similar to "0" instead of "Background" for example).

If you're really jonesing for this and don't want to wait for it to be implemented client-side, you can achieve this via osq macro'ing.

header stuff:
#let BPM 60
#let offset 51
#let comp 4 //if using compound timing, set to 3
#def settime (st, bt) //stanza, beat number
#let result {60000*(st*comp + bt)/BPM} // I have no idea if this equation is correct
#end def

usage:
${settime(4:1)} //fourth stanza, second beat
F,0,100,${result},1,0

Couple notes:
1 - this is a bad example because it does not allow doing this multiple times in one line of code
2 - the above limitation can easily be resolved by wrapping the settime function in one of multiple wrapper functions that allow the use of variables such as ${starttime} and ${endtime}
3 - I do not know if you can pass-by-reference in osq. If you could, that would be pretty cool for something like this.
anonymous_old
0 posts
Here since the beginning
anonymous_old
Um...

#let BPM 60
#let offset 51
#let comp 4
#def o(stanza, beat, fraction) 1000 * (((stanza - 1) * comp) + (beat - 1) + fraction) / BPM + offset

_F,0,100,${o(4, 1, 1/2)},1,0    // Fade at the second 1/2 beat of the fourth stanza
(If you're using an old osq, you need to wrap ${} around the value of #def.)

As for loops, yes, it's an issue. I split loops into multiple loops when it becomes too much of an issue. If decimal offsets were supported, it'd work out almost perfectly, though.

I could MAYBE add a 3:3.1/4 syntax to osq. I think maybe a slightly different notation would be less confusing, though (is 3:3.1/4 = (03:03:100) / 4 ?). I'll think about it. For now, you can use the o definition above, if you use osq.
vytalibus
osu! Alumni
870 posts
Joined May 2008
Topic Starter
vytalibus

strager wrote:

I think maybe a slightly different notation would be less confusing, though (is 3:3.1/4 = (03:03:100) / 4 ?). I'll think about it.
"3:3.1/4" would be "Third stanza, third beat, first tick in the 1/4 divisor". To see what I'm talking about when I say "stanza" and "beat", check the Timing section in Edit mode. See how the whole timeline is separated into stanzas and beats?

This might pose some redundancy when referring to the ones on an exact beat or stanza. Hopefully there's a workaround to this.
anonymous_old
0 posts
Here since the beginning
anonymous_old

vytalibus wrote:

strager wrote:

I think maybe a slightly different notation would be less confusing, though (is 3:3.1/4 = (03:03:100) / 4 ?). I'll think about it.
"3:3.1/4" would be "Third stanza, third beat, first tick in the 1/4 divisor". To see what I'm talking about when I say "stanza" and "beat", check the Timing section in Edit mode. See how the whole timeline is separated into stanzas and beats?

This might pose some redundancy when referring to the ones on an exact beat or stanza. Hopefully there's a workaround to this.
I completely understand how your syntax works. However, there may (will) be confusion in the parser itself, due to existing constructs.
Zekira
9,233 posts
Joined September 2008
Zekira
Maybe not change it completely, but rather have an alternate editor for it instead? Having both the millisecond version and the beats version completes a lot of insufficiencies of each other E.G. beats version can work out the copy-paste SB elements that almost everyone has been wanting to have, while the milliseconds version can obviously put elements and their marks at beats that aren't in any of the beat snaps (more than 1/8, 1/5, 2/5, etc)
peppy
19,301 posts
Here since the beginning
peppy
Isn't there already an option to move all SB elements by x milliseconds?
LuigiHann
Resident Skinner
4,432 posts
Here since the beginning
LuigiHann

peppy wrote:

Isn't there already an option to move all SB elements by x milliseconds?
Yeah but not to resnap to X bpm, I suppose

It'd be pretty awesome if, in general, events in the timeline in design mode were handled more like sliders in the timeline in compose mode
vytalibus
osu! Alumni
870 posts
Joined May 2008
Topic Starter
vytalibus

LuigiHann wrote:

peppy wrote:

Isn't there already an option to move all SB elements by x milliseconds?
Yeah but not to resnap to X bpm, I suppose

It'd be pretty awesome if, in general, events in the timeline in design mode were handled more like sliders in the timeline in compose mode
Wouldn't that be a bit of a clutter, considering how many transformations we can do in a single image?

Though it does sound like a good idea as well, just need to figure out how to design the timeline so that it'll show the transformations correctly.
Please sign in to reply.

New reply

0
1 / 11