#63 tempo/signature map entries should stick to rightly to time or bar/beats

git_head
closed
nobody
None
2015-02-01
2013-07-15
Tuomas
No

If I change time signature, all tempo/signature markings after that point will go to wrong places.

So, in practice,

1) if tempo is changed at some point, tempo map enties after that point should stick to time signatures.
2) if time signature is changed at some point, tempo map enties after that point should stick to bars/beats.

Discussion

  • Rui Nuno Capela

    Rui Nuno Capela - 2013-07-15

    aha,

    tempo-map/time-signature nodes and location markers are stuck to bar/measure time points by design.

    for the time being there's no way for you to locate those freely on the timeline. this ticket seems to be one side-effect of breaking that rule, as an example :)

    you're probably referring to the side-effects of your [#62] patch, which i believe you're using the qtractorTimeScaleUpdateNodeCommand instead of the more appropriate qtractorTimeScaleMoveNodeCommand

    note that you should also apply for location markers with similar commands, otherwise your patch is non-complete, maybe not even acceptable ;).

    cheers

     

    Related

    Tickets: #62


    Last edit: Rui Nuno Capela 2013-07-15
  • Tuomas

    Tuomas - 2013-07-15

    Hmm. [#62] is altering only tempo (bpm) value in tempo map entries. Changing tempo is working at the moment OK, also with my patch. But changing time signature is what is causing the problems. I face this problem because the music I am (trying to) make, has many time signature changes. I am adding these signatures after recording the improvisational music, and sometimes I would not prefer to start from the beginning, but it would be a mess with tempo mappings then, because of this problem that I described here.

    The main function for [#62] at the moment is to temporarily slow down all of the project (I was thinking that there might very well be some nicer way to implement this, but I could not figure out myself any other than altering tempo map, so I implemented it that way, and it is working fine).

    Sorry, I don't understand why should I move any markings. (please explain more, if you think I am missing something). The patch is not about moving anything, but only changing tempo and it's working OK in [#62] with qtractorTimeScaleUpdateNodeCommand.

    So, in the above, case (1) is working perfectly already. Only case (2) is not.

     

    Related

    Tickets: #62


    Last edit: Tuomas 2013-07-15
    • Rui Nuno Capela

      Rui Nuno Capela - 2013-07-16

      maybe i've overreacted. yes, you're right. [#62] just changes tempo values, which anyway will affect the following tempo-map nodes nevertheless (in terms of their frame position or location)...

      now i don't really get what's wrong with 2). changing time-signatures here (say, from 4/4 to a waltz 3/4) do behave as it should: all following nodes get still to their bar/measure locations, although their absolute frame positions do change but thats exactly what is expected...

      maybe you should explain us in detail about some example on where and when all this doesn't happen or maybe gets it all wrong? i'm eagerly awaiting :)

      cheers

       

      Related

      Tickets: #62

      • Tuomas

        Tuomas - 2013-07-17

        That is expected, right. But in my case it is non-desired behavior. Let me again explain what I am doing. I believe it should help you understand my problem. ;)

        First, I am recording the stuff, it's improvisational and time signatures change in the playing, but it's all recorded in 4/4 in one session.
        (I set up metronome such that it gives same sound for each beat).

        Then, I remove some bad parts with brand new remove range -feature. (thanks for your great contributions after my initial patch!).

        Then, I set up correct time signatures and start working on the project in order to make music from the initial improvisation. Everything is fine, if I start from the beginning and go towards end. BUT if I decide to start from certain point (progressive music is sometimes lengthy) and work on it first, I will get into big trouble if I then go to change time signatures at the beginning of the project, because it would move all other time signatures / tempo map to wrong places. I could also want to add some new stuff in between already finished stuff with insert range -command, and then set up correct time signatures for the new parts.

        Maybe one solution would be to split the project to several smaller sub-projects and work there and then just finally merge all pieces. But I don't know of any simple way to do that, neither.

         
        Last edit: Tuomas 2013-07-17
        • Rui Nuno Capela

          Rui Nuno Capela - 2013-07-17

          maybe we're (i mostly) not in the same tune. tempo-map and time-signature nodes are and always have been stuck to bar or measure points, always. or at least they're supposed to at all times.

          also, markers "suffer" from this restriction as well.

          if you have some evidence that some of these nodes doesn't comply to that restriction, please expose that to the masses:)

          it might just be a nasty side-effect of editing the tempo-map in ways not coped at first glance

          if you know how to trigger that kind of bug, please try to isolate it and report back

          nb. again, tempo, time-signature and markers are not supposed to get located at anywhere else but bars or measure boundaries. if you've seen them once laying somewhere else around, then please file it as a bug--is this one it?

          cheers

           
  • Tuomas

    Tuomas - 2013-07-17

    So far I did not catch such bug, but I will report if I find one.
    It's ok if you are not agreeing with me on this. I admit that my workflow might be a bit uncommon.

    In any case, I think I must figure out some way to cope with my problem, a way or another. Ideas are welcome.. ;) Feel free to close this ticket.

     
  • Rui Nuno Capela

    Rui Nuno Capela - 2013-11-26
    • status: open --> pending
     
  • Rui Nuno Capela

    Rui Nuno Capela - 2013-12-11
    • status: pending --> closed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks