View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001368||ardour||bugs||public||2006-12-18 02:35||2006-12-18 05:32|
|Summary||0001368: Ending up at 12:25:35:07 while jack synced to rosegarden on x86_64|
|Description||Ardour2 is the time master, linuxsampler running, rosegarden running, jack sync on. |
Apparently, rosegarden does two bars of lead-in, before recording.
Hit record on rosegarden.
This flips ardour2 back to 12:25:36:09
This wouldn't bother me so much: but, then, once rosegarden finishes it's leadin, IT jumps forward in time to the same point, and then both programs attempt to continue forward from there. That's with jack sync on, and rosegarden configured as a mtc slave....
With just jack sync on, all midi control of rosegarden off, the resulting jump gets locked up at bar 22368 beat 3 (120BPM project) 12:25:35:07 on ardour
Doesn't happen on play.
It resets the end markers on both programs.
With rosegarden configured to send midi start and clock, and ardour2 no longer the time master, the same thing happens.
|Additional Information||I do end up 12 hours in the future sometimes while fiddling with the tranzport, as well. (I'm not using the tranzport right now). Otherwise I'd argue this was a rosegarden specific problem.|
This sort of problem has been occurring for a while.
I have a repeatable test case for a change, if you want a 300+MB project to play with. I'll try and cut it down. (and also get a normal x86 box running)
(The same project also crashes on export, also repeatable, different bug I think)
|Tags||No tags attached.|
In the latter case, it freezes at 4294587869 samples (96k project),
Zillions of these...
RosegardenSequencerApp::isTransportSyncComplete: token 2149, current token 2148
I have now got this to occur with fresh rosegarden and ardour2 projects.
Also bug reported to rosegardenmusic as
||I got ardour2 svn built on x86. With mostly the same settings (I have to tear apart the studio to move the x86_64 box out of the way), hitting record on rosegarden "does the right thing" - so it does look like an x86_64 prob at the moment.|