• Support

  • TIMECODE ENTERING frustration.

Hi Peter, i have mentioned this ages ago and il do it again as it is a real frustration when entering timecode.
When i hit a timestamp in sync with the music i expect the highlighted line to be completed at that time point, not for it to begin its movement at that point, this throws everything out of sync.
Try this, pick a song with a solid beat enter numbers from 1 to 16 in the text editor one number per line.
Play the song and on the beat time stamp the 16 beats on the beat, then play it back and see the end result , you will see the text 1 to 16 is out of time visually to the music and thats because you have the movement lag, the lag should not be there the movement should happen before hand so the end of the movement is on the beat, this will then allow us to enter timecode on the beat, not like now we have to preempt the timestamp to allow for the movement lag.
This has frustrated me since day one and it really slows down time consuming lyrics auto sync process.
Can you somehow offset the movement of line to be completed at the actual timestamp point entered, so we are always in sync when entering timecodes?
Hope you had a good easter,
Cheers Damir

The timecode is the time at which a certain action (in this case scrolling & highlighting) is triggered. No way I can do the scrolling before the highlighting.

    peter so how can we fix the out of sync visual end result?
    It’s the end result that counts not the fact the programming appears correct.
    The end result should be on the beat the line should be in place and a highlight should appear, on that perfect place at that perfect time.
    I use a little trick when I have a very lengthy break in music example song CONGA, it has a long percussion section of 32 bars. I use - to represent a beat and at the end the last bar I put in 1 2 3 4 to count me in, because of this problem of out of time time code entering it’s impossible to quickly enter the timecode on the beat and for the highlights of every - line break to highlight on the beat.
    This is very important, the movement has to start earlier and the highlight has to trigger on the exact timecode it was entered on, otherwise you have a visually incorrect end result, we expect the lyrics in place and steady to read at the time we have time stamped them so we can easily read the lyrics and the highlight to appear when we have time stamped it in sync with the music beat , if this can’t be achieved than it’s a sloppy end result that sort of works which is not ideal when you are trying to enter a perfect result.
    I enter line time syncing for all my songs and I bet most serious users will end up on it once they get comfortable with ST3 as it gives us a lot of power to make life easier on stage I have just mentioned one example of smart use of this feature, but right now it is very sloppy as I said years ago and have put up with it ,
    Perhaps Apple geniuses can figure it out as it’s not a ridiculous ask.
    Feedback
    I am perfectly happy with ST3 on stage, but it’s about time to tidy up the text edit section as we spend a lot of time in this section and it really needs fine tuning to speed up the auto sync process. Entering complicated computer language commands to achieve an end result is really not acceptable to a musician, a colour change should be as simple as highlight a section and choose a colour on the screen the text should represent the visual effect, none of this C + -([#%^*+£€¥ stuff that’s fine for computer people not for musicians.
    You get my drift I won’t go on.
    Love your videos, you’ll be a Utube king soon.
    New OnSong sucks even more now it’s way over complicated for what it does.
    Cheers Damir

      Do you really need beat synchronous scrolling just to tell you that percussion port is about finished? Why not just display a 4 bars, 3 bars, ... warning. That is way less work and you have more time to prepare for the end of the section.

      I have never tried to implement lyrics highlighting on a beat to beat basis where single words are highlighted. That's
      the domain of Karaoke players and I never wanted to develop a karaoke player. If you stick to line by line highlighting, the timecode precision is more then fine.

      I might maybe take a look at it if there is nothing else to implement but as things are right now, I have much bigger fish to catch on my plate.

        peter you miss my point, i dont want word sync i just want on the beat line sync, not off the beat line sync.
        I will attempt to show you a problem that has always existed due to line movement, this problem is visual, one where lyrics are moving while you need them to be in place sooner as you start singing.
        This does not happen if you time code chords only all in one line because there is no movement untill you get to the end of the line and need to jump to the next line then the problem occurs.
        To fix this you need to timecode OFF THE BEAT, i usually time code on the AND this corrects this problem.
        If you dont do this your lyrics will be moving just as you need them and we all know its the first word that we usually forget once we see it we normally remember the rest of the line , but the first word is usually moving up as you need it the most.
        If this does not get fixed my suggestion to all users is time stamp on the AND and not on the ONE and you will see a great improvement in your visual lyrics sync experiance, but i am pretty sure most heavy users have already sussed this problem and are using this work around that should not be needed if the move activated early and the highlight stayed on the beat.

        EXAMPLE


        To me this is a TUNA
        CHEERS DAMIR

            Damir I personally try to not let my audience know that I'm referring to my lyrics so wouldn't need to follow them so precisely, as my eyes aren't glued to the screen. I therefore often depend on having lyrics or chord lines coming up early. To each his own; maybe a useful forum feature would be to have a poll at the end of each topic 😆 eg. How many people want to see this implemented?

                MasterAnt I too keep my iPad well away from me on a stand angled in such a way the audience does not notice it greatly, for that exact reason I want very accurate movement of lyrics so when I do quickly glimpse at the screen specially at beginning of lines I want that line ready and not in a middle of a move.
                Plus when I am entering timecode it is a lot easier to use the music to enter timecode on the beat than off the beat , I should not be compensating for something that could be created to work perfectly in the first place.
                It’s time consuming when presented with awkward songs to timecode , yes its not that bad for simple ones and a rough end result, but my view is if a job is going to be done then it should be done well.

                  Suggestions:

                  a) If you don't mind highlighting being a bit early, just add an offset of -0.3 seconds (that's the scrolling duration). This will ensure that the screen has stopped scrolling when it is time to read the line.

                  b) If you mind about the highlighting, just add another timecode to the beginning of the line followed by a whitespace. That timecode should be 0.3 seconds earlier, than the following highlight. Example:

                  [00:29.7] [00:30.00][A7]Specially...

                  That way scrolling will be finished at the time your highlight starts.

                  c) I could make the scrolling time configurable. So each user can choose how smooth (and time consuming) the scrolling should be. You could set it to 0 and that would ensure that the movement would be finished but the screen would jump instead of scroll.

                    From my point of view the current system works fine - personally I can’t see the point of adding further complication. But of course other users may see things differently

                      peter

                      DickyDutch it depends on how users use ST3.
                      Whatever I use, I use to a full degree.
                      What’s the point of buying a Ferrari and never flooring it, like my mate hired one in Italy and took off in it like an old fart we still laugh about it cause we have a video.

                          peter a) If you don't mind highlighting being a bit early, just add an offset of -0.3 seconds (that's the scrolling duration). This will ensure that the screen has stopped scrolling when it is time to read the line.

                          b) If you mind about the highlighting, just add another timecode to the beginning of the line followed by a whitespace. That timecode should be 0.3 seconds earlier, than the following highlight. Example:

                          [00:29.7] [00:30.00][A7]Specially...

                          That way scrolling will be finished at the time your highlight starts.

                          So if that’s the solution to the problem , why isn’t that the default setting ? So we don’t have to bother with it every time we time stamp a song.

                          Is a global offset of these features an answer?
                          To save us unnecessary tweaking as we have so much to tweak already to perfect an end result.

                          And I really like the adjustment of scroll speed idea as some people might want a quick jump and others a smoother transition.

                          My view on these issues is fix it where it needs to be fixed and don’t give us more things to have to tweak, there is definitely an issue with the late scroll and highlight timing, just fix that and if you gave us a scrolling time global adjustment that’s all that’s required.

                          I know this will effect previous songs but it’s well worth doing as it will be correct from then on, it should have been picked up much earlier but I did mention it a fair way back in development but it was not fixed then.

                          Here’s a thought!
                          Why can’t you attach an invisible extra timecode offset to every timecode that acts as a scroll trigger and a global scroll adjustment that allows us to tweak the scroll speed, this way all new songs will have this new way of control while the old songs remain as they were.
                          I can guarantee once users get to use the new method the end visual result will be a lot more pleasing.

                          The truth is I never really liked the scroll method in ST3 as it appeared jerky it’s only now I realised to why it appeared that way , because the scroll started at the point when it should have stopped.

                          Perhaps someone has a better fix idea, as long as it’s not another workaround.

                            2 years later

                            DickyDutch I agree. I always enter the timecode, just before the line begins, so that I see the next line that I'm about to sing. I wouldn't want the line or words to be highlited exactly on the beat.

                                tommybluenote I agree. I always enter the timecode, just before the line begins, so that I see the next line that I'm about to sing. I wouldn't want the line or words to be highlited exactly on the beat.

                                Thats why i enter all my timecodes on the AND before the 1 2 3 or 4, this then creates a more perfect visual display on stage and thats why i suggested that the software does the work for us where we do enter the timecodes on the beat as it would be a lot easier but the software actually moves the lyrics ahead of time automatically for us so we dont have to enter off beat to make it usable , it should set an offset depending on the tempo set time related to length of song so it perfectly compensates the early change to suit each song , the timecodes should be left as programmed but the movement of lyrics should be doing the work behind the scene for us , this should be able to be programmed, and it would make life a lot easier and usable for the end user.
                                At the moment it works in a rough way and its not pleasing , users with knowhow can work around it but those that dont understand the issue just have to put up with it without realizing they can improve the on stage experience.