|
|
I think this is the same bug I reported, it has effect on meters and tempos.. I tried to solve it by my self, but after several hours I didn't find anything.. See http://tracker.ardour.org/view.php?id=2370 |
|
2008-09-16 15:40
|
ardour.patch (406 bytes) |
|
|
Hey, this is the same bug I was going to report, too. Note that I have attached a patch which seems to fix the basic problem. My description follows: I am recording a lot of music with very long, elaborate click tracks. There is a bug that has been plaguing me for a long time in using ardour, for at least a few years, but I could never figure out what was going on, and so my band just resorted to using a separate audio track as a click. Still, the advantages of being able to edit in a beat and bar oriented way caused me to always try, every ardour release, and see if things would work better. Finally, with 2.5, I decided to try and track down the bug for myself. Here are some steps to reproduce it: (the numbers chosen are largely arbitrary; I'm not sure if it can be made more minimal) * Start a new project. Displaying BBT will make the problem clearer. * Change the tempo at bar 1 to 130 bpm. * Add a meter change (5/4) at bar 2. * Add a meter change (4/4) at bar 8. * Move the 5/4 meter around, noting that the bar display as you drag it will say some bizarre combinations of beats and bars. Once you drop it, the positions of the 4/4 meter will have changed to be something like 10 bars further than it should be. This behavior really sucks when you have a ten minute long song with time changes every few bars... I didn't have a lot of time to take a look at it, and it was late last night, but the patch I came up with is attached. I don't know enough about the ardour internals to know if it's correct, but it seems to work for me. Comments appreciated. The way things are calculated in bbt_time_with_metric seem pretty iffy to me, but at least with the attached change, the meters don't fly off into infinity. |
|
2008-09-17 19:44
|
ardour-tempo.patch (3,677 bytes) |
|
|
Attached another patch which seems to correct the aforementioned bbt_time_with_metric behavior. Heed the warnings therein, though. |
|
|
I just ran into what seems like the same problem. I'm using version 2.4.1. If I move a meter marker with the mouse, then it pretty much corrupts most of the meter markers I've already placed. It also renumbers the measures quite strangely. When zoomed in so that I have several horizontal screens worth of song, when I scroll left or right the measure numbers aren't continuous. When I leave one "page" with a measure number of 30-something, I enter the next "page" and the measure number jumps into the hundreds, e.g. 451. I can place, edit, and remove meter markers just fine and all is well if I don't move one with the mouse. I hope this helps. |
|
|
kevinc, can you try my second patch above and let me know if it works for you? |
|
|
tokenrove ... shall i check out both patches or just the second one? |
|
|
The second one supercedes the first. I've been using it since I posted it, and it's been working quite well for me. Thanks. |
|
|
I've been plagued by this too so I'm glad someone's had a chance to look at it. I've tried this patch briefly and I think things are better but there's still odd behaviour (I can't really nail it down right now) when you move between meter changes that aren't at the start of bars. That seems like a nonsensical situation but ardour allows it and then is confused by it. I'd imagine that to handle meter changes that aren't aligned with bars we should probably have some sort of "reset" event on the timeline which marks the time between the end of the last real bar and the start of the new one as completely freeform time. I'll continue working with a patched version and note anything concrete I can figure out. |
|
|
Assigning to Paul to take a look at the patch. Seablade |
|
|
Spent another couple of hours being messed around by this again. I decided to put the meter changes in by hand and noticed this: <Meter start="1|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="no"/> <Meter start="11|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="12|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="49737|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="49738|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="49756|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="49757|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="49810|1|623" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> Wiping out the > 49000 bar elements and then using 2.7.1 seemed to function correctly, but the default location for the inserted meter is bizarre -- not where you click. Also, can we set the Beats Per Bar to an integer? Perhaps some avant garde stuff uses fractional fractions(!) but surely having it as int/int rather than real/real is a) sufficient and b) what 99% of people actually want? |
|
|
There is quite a bit of interesting non-western music that can only be properly represented in traditional tempo/meter notation with non-integer beats per bar. The bad location of the inserted marker is likely caused by a zoom bug that someone filed separately. I don't understand what it was that you noticed in the above XML ... |
|
|
Sorry. Bug-report in haste, clarify at leisure. I revisited an old session with 2.7.1 and spent a while trying to massage the meter changes into it but things kept going wrong. Inserting a single 3/4 change at around bar 17 resulted in a scatter of 3/4 and 4/4 meter changes seemingly appearing. Deleting and moving as appropriate sometimes worked but often caused other mutations. In the end I looked at the file and saw that there were spurious meter changes at e.g. 49373 -- way after the end of the track. Removing them by hand in the XML and reloading the session caused it to work perfectly (though I treated it rather gently). |
|
|
I've just have another session (new, from scratch in 2.7.1, currently rev 4422) get totally spaced out by this bug. Three hours of carefully measured and placed time changes suddenly gone AWOL. :( I've had a look for the "zoom bug" but can't find the one you mean. I'm seeing a problem that if you're not zoomed (and perhaps anchored to the start of the session) then right clicking on the mark or meter bar registers the click somewhere off to the left. Is that what you're referring to? As for the time signature related stuff, it seems like something loses the plot and gets very confused about the meter. Bar numbers rocket (by a factor of about four at least sometimes) and the changes get scattered throughout the session. This: <Meter start="1|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="no"/> <Meter start="17|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="19|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="20|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="21|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="22|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> Became this: movable="no"/> <Meter start="1|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="no"/> <Meter start="17|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="41|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="60|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> <Meter start="86|1|0" note-type="4.000000" beats-per-bar="4.000000" movable="yes"/> <Meter start="107|1|0" note-type="4.000000" beats-per-bar="3.000000" movable="yes"/> Unfortunately I don't have a back up of any of the changes beyond that point. I'm attaching a screenshot attached showing a point in the session where things go weird (zooming to different levels affected this). And further to my comment about meter changes in the middle of a bar, they still seem more likely to cause the problem but even with snap-to-bar on I've managed to scramble the session a second time whilst writing this. Interestingly, the shifting of the meter changes is exactly the same so it's unlikely that it's related to anything like where I click or which meter change I'm moving and to where. This is really crippling my recording at the moment :( |
|
2009-01-21 17:03
|
meterweirdness.png (53,259 bytes) |
|
|
OK, I've reconstructed the session and am attaching the diff for the lines related to the meter changes. Note that there are seemingly many things I can do which trigger the corruption but it's always exactly the same as this within this session. |
|
2009-01-21 17:35
|
meter-changes.txt (5,950 bytes) |
|
|
Strange, I'm using 2.7.1 from 4297 and it seems to be working fine for me (meter changes every few bars, 10-15 minute long songs), although these days I'm not doing much rearrangement of the meters, usually just adding them sequentially. Can you reduce it to a more trivial case where a single repeatable action demonstrates the fault? I see you have some 7s; it might be worth testing with those, as it was a bar of 5 that broke the original code consistently, and I think I tested the patch mostly on combinations of 3, 4, 5, and 9. |
|
|
Just an addendum; does this have anything to do with removing meters or tempos in the middle of a project? Just toying with it now, that seems to be the only case for me where things get strange -- I think there's (at least) a display bug where the bars:beats line gets really messed up when you do that. |
|
|
I haven't found an exact reproducible case, but try this: Create a new session. Put a 7/4 change at bar 5. Put a 4/4 change at bar 7. Zoom out to about 0m00s - 3m00s. Turn off snapping. Drag 7/4 marker backwards and forwards between the two 4/4 markers. For me eventually something happens to the right hand 4/4 marker. If I move the 7/4 marker to the right of the 4/4 and continue fiddling eventually I also get the 4/4 to the left of the 7/4 jumping when I move the 7/4 right -- i.e. in a way that can't possibly be expected to influence it. I think part of the problem I'm getting with making something perfectly reproducible is that the corruption happens in memory and a later redraw shows it. So whatever causes it is an operation or two before the one where I notice it. Let me know whether you get anything. |
|
|
The stripped down case above is just moving things. I'd guess that things are more complicated behind the scenes than one would first expect and I'm seeing a combination of unexpected but by-design behaviour and genuine bugs. What does it mean to move a time signature change a bar later. How should later meter changes react? What if you move the meter change 10 bars to the right. Does the user mean 10 bars, or 20 seconds, or To The Start Of This Region? And what does it mean to have a meter change halfway through a bar? To me that's nonsensical (what you mean is a meter change in the previous bar and a different one here) but perhaps the code treats it one way and aligned-to-bar meter changes another, for the purposes of realigning any subsequent chances? But to remphasise -- I've had this happen even when I've got snap-to-bar on so it's possible to blow things up even without intra-bar meter changes. |
|
|
I see what you mean (I find the 4/4 at bar 7 inevitably gets pushed to bar 8 once I put the 7/4 in the middle of a bar and then move it out), although it's part of the behavior that I decided I wasn't going to try and figure out, since, like you, I don't use (non-trivial) fractional meters, and figured that whoever does can have a long, hard think about it when they come to it. I think one treads down a dangerous path as soon as you're placing a meter change anywhere but the first beat of a bar. I've never had the snapped meters behave badly, but I know that the snap to bar can behave strangely; it might be worth taking a closer look at how bbt_time_with_metric() interacts with TempoMap::round_to_type() in your cases; I seem to recall I thought there might be a problem there when I was originally patching it, but I decided to keep my changes as minimal as possible (as the current behavior has worked for me so far). Uncommenting the diagnostic messages on stderr in bbt_time_with_metric() is pretty much essential for debugging any of these problems. Also check out timestamp_metrics(), and its diagnostic cerrs, which is where the meters are probably getting "pushed". That's probably what you should do next if you want to figure out exactly what's happening, or you can wait until it bites me (probably in the middle of a long, desperate recording session) and I'm forced to fix it. ;-) Hope this helps. |
|
|
I'm hoping someone familiar with the code base will look at this. I haven't used C++ in ten years and though I keep meaning to get involved with ardour dev work I also keep finding I don't have the time to work my way through the code and do anything useful. Maybe this the time to dive in and start working on it. But then again, right now I'm trying to record a great big chunk of stuff against a tight deadline so perhaps it can wait :-) Thanks for your help so far though. |
|
2009-03-17 17:12
|
move-meter-snap-to-bar.patch (761 bytes) |
|
|
Investigating this in libs/ardour/tempo.cc I noticed that add_meter snaps to bar but move_meter doesn't. Discussions of Bartok notwithstanding I've added snap-to-bar behaviour to move_meter and so far on light testing I haven't had any further instances of tempo map corruption. It's fixing a trigger rather than the underlying cause but I've also found that 3.0 seems not to suffer from the bug anyway. Perhaps someone else can confirm this patch works for them and it can be used as workaround for the 2.0 series? (See brief discussion on #ardour, 17 March, 2009, 17:15pm GMT) |
|
|
Tried your patch. Moving meter markers still moves tempo markers in an unwanted way. But maybe the behavior is better than before...? |
|
|
I tried tokenrove's and heiko's cases and both seemed fine. My testing also seems fine so far, but it hasn't been exhaustive. I can't reproduce any strange effects on tempo changes from moving time signatures around. **bigstumpi** Can you give me a specific example so I can confirm this? What I /can/ trigger is the corruption on moving tempo markers around (again, triggered when they land mid-bar). As tempo changes mid-bar are really not an unheard of thing this is still something that needs fixing, ideally. It points to the bug being in the code that adjusts the timeline after moving things around. I note that mid-bar tempo changes seem to trigger the code to start a new bar anyway, so even if it's a feature we want, it's broken. Checking in 3.0 I see that this behaviour still exists and, unfortunately, I have now managed to trigger the tempo map corruption there too. I will spend a little time looking into this this morning, but the code is new to me and this stuff is a lot more subtle than you'd first think, particularly the relationship between the parallel but not tightly locked time measures of bars and beats vs seconds. What the user means when they move a marker is not necessarily obvious. We seem (from observation) to treat meters and tempos as anchored to bar/beat time iff they fall exactly on bars/beats. Pragmatically I'd suggest that even though we want mid-bar changes they are currently broken and ought to be disabled (much like my previous patch) until we can fix the logic. |
|
|
I can't give you a specific example, because it seems to appear randomly. What I did is: 1.) create a blank Project 2.) activate "Snap to" 2.) add a meter marker [3/4 at 65,1,00] 3.) add a tempo marker [150 at 59,1,00] 4.) move the tempo marker somewhere behind the meter change 5.) move it back in front of the meter change 6.) repeat steps 4 and 5 until something strange happens (about 20 times?) There it is. No definite behavior - sometimes both markers move somewhere else, sometimes only one. An interesting effect can be seen by "undo"ing the last two or three changes - the error has multiple steps. Perhaps this helps to find a possible reason? |
|
|
Ah, moving tempo markers is something my patch didn't address. I've applied virtually the same patch to the move_tempo method and in my version I can't reproduce your bug despite spending about 5 minutes throwing the markers around. Can you try that? |
|
|
Works fine for me! Thanks! Like you said, tempo and meter mid-bar changes are no longer realizable. At this point I can say that in my case all bugs related with markers are solved - see http://tracker.ardour.org/view.php?id=2496 - Adding a patch which combines the "move-meter" and the new "move-tempo" patch -> "move-all-snap-to-bar.patch" |
|
2009-03-19 12:38
|
move-all-snap-to-bar.patch (1,293 bytes) |
|
|
problem persists in current 2.0 (r5445). which of these patches is actually in svn? moving meter markers f$ยง&s up the time line - after dragging, bar numbers are way off. workaround is to always remove/create instead of dragging. this bug should be upped to "MAJOR" imho - tempo maps are very hard to use as it is now. |
|
|
Yes, this should be marked as "major". It is still present with 2.8.7 (r6630) on Snow Leopard. What seems to be going on is that the tempo start points are adding to each other. In other words, if I try to put tempo changes at bar x|1|0 and y|1|0, what I will get instead is x|1|0 and (x+y-1)|1|0 or something like that. For example, from a file where I intended to have a tempo marker at the beginning of each measure: <TempoMap> <Tempo start="1|1|0" beats-per-minute="112.500000" note-type="4.000000" movable="no"/> <Meter start="1|1|0" note-type="4.000000" beats-per-bar="1.000000" movable="no"/> <Tempo start="2|1|0" beats-per-minute="109.956782" note-type="4.000000" movable="yes"/> <Tempo start="4|1|0" beats-per-minute="117.453835" note-type="4.000000" movable="yes"/> <Tempo start="7|1|0" beats-per-minute="117.453835" note-type="4.000000" movable="yes"/> <Tempo start="11|1|0" beats-per-minute="117.453835" note-type="4.000000" movable="yes"/> <Tempo start="16|1|0" beats-per-minute="112.347147" note-type="4.000000" movable="yes"/> <Tempo start="22|1|0" beats-per-minute="93.963068" note-type="4.000000" movable="yes"/> <Tempo start="28|1|0" beats-per-minute="83.354335" note-type="4.000000" movable="yes"/> <Tempo start="34|1|0" beats-per-minute="120.190779" note-type="4.000000" movable="yes"/> <Tempo start="44|1|0" beats-per-minute="132.898041" note-type="4.000000" movable="yes"/> <Tempo start="56|1|0" beats-per-minute="120.185320" note-type="4.000000" movable="yes"/> .... This makes the tempo feature *completely useless*. The bug should be fixed. Now. |
|
|
i've just committed the move_all patch to SVN for 2.X, so if marnen and nettings would like to try it out from SVN and confirm that this does indeed fix the issue, that would be helpful. bartok is overrated, anyway. |
|
|
I tested the behaviour with svn-7847 and it seems as the issue is fixed now! Why did the commit take so much time? The patch was uploaded over a year ago... I think the two related issues could be closed, too. |
|
|
the commit took time because i still don't believe that its the correct answer, but i'd rather see the clearly incorrect behaviour go away. also, you might not have noticed but there are thousands of bug reports here, and most development work has shifted to 3.X, which also makes it more likely that a patch for 2.X will sit around for too long. |
|
|
see notes. |
|
|
Hi Paul! Thanks for committing this. I have discovered this patch not long ago and applied it to 2.8.11 where it seemed to fix the issue (at least I have not encountered it since). I did not try the latest svn yet. Hope this helps. |
|
|
Issue has been closed automatically, by Trigger Close Plugin. Feel free to re-open with additional information if you think the issue is not resolved. |
- Anonymous
