#1756 Rosegarden JACK transport recently broken

[musewhirl]

The rosegarden JACK transport was broken somewhere between going from [dc152b] to [dea3d4]. It is currently unusable. I used ardour as a JACK client.

Steps to reproduce

1. Launch RG and ensure JACK transport is checked
2. Launch ardour and select its JACK transport
3. Press play (space bar) in ardour, and it's a full 10 seconds on my box before the transport moves in the applications
4. Its behavior appears OK after that while playing, although I didn't do much testing with it like this
5. In addition, it also takes a full 10 seconds to stop when done from ardour

On reverting back to [dc152b] everything worked normally again.

[Ted Felix]

Any chance you can test [70a992]? That's where @lman's CompositionPosition changes are complete. They seem like the most likely source of this.

[Ted Felix]

Issue confirmed in [90d2c0].

[Ted Felix]

Issue confirmed in [70a992]. I'll bisect further.

Launch ardour and select its JACK transport

In Ardour, to enable JACK transport, there's a little "Int." button under the panic button in the toolbar far left. Click it. If it does not say JACK, click it again to go back to "Int." then right click it and select JACK. Now click it and it should show "JACK".

[Philip Leishman]

It appears that the jack transport sync callback is hanging. The playback starts after a timeout.

[Ted Felix]

Bisected it down to either [c8bbbf] which does not build or [70a992]. So this is related to work done for [#1721].

[Lorenzo]

One important thing to note is that AFAIK - and has always been like that for me - Rosegarden always only works as JACK transport 'master', at least when interacting with Ardour. In practical terms it means that starting, stopping, moving from Rosegarden will work and Ardour will follow, not the reverse.
But that doesn't come as new to me, as said, it's always been the JACK transport behaviour

[Ted Felix]

Rosegarden always only works as JACK transport 'master', at least when interacting with Ardour.

Fixing [#1721] should let Ardour control Rosegarden.

starting, stopping, moving from Rosegarden will work

That does indeed appear to be the case. And once Rosegarden has started the transport, things appear to be more stable. Ardour seems to be able to start/stop/move Rosegarden just fine.

For me the 10 second delay only happens when Rosegarden is first launched and Ardour playback begins at time 0. If you do anything else (e.g. Ardour playback at time 1), Ardour start/stop/move works perfectly fine from that point onward.

[musewhirl]

With Rosegarden and JACK alone i.e. no Ardour:

If RG is opened and the cursor moved to a new time location and saved, Rosegarden appears to remember that location as in previous versions. However, a CTRL-R briefly shows the playhead at the new location before it automatically returns to time zero. In the mean time, JACK logs show that previously saved location too, but does not register the return to New pos = 0. JACK does acknowledge the return to time zero if the user puts the playhead there manually.

I guess that RG is remembering the old location, telling JACK that location then sneaking back to position zero leading to the playhead being out of sync with JACK? After that, perhaps confusion occurs between applications?

[Philip Leishman]

OK - I have fixed this.
See merge request (for bug-1721-composition-position)
And Merry Christmas everyone !!!!

[Ted Felix]

Pushed Philip's fix as [7aa198]. Please test latest git.

[musewhirl]

I built from the bug-1721-composition-position branch. A quick glance indicates that the JACK 10 second delay is gone. However, the other problem I mentioned remains i.e. Rosegarden no longer remembers it playhead position when closed. More correctly, it actually does remember it, and on opening briefly places it at that location before the user visually sees it dragged off to time zero.

This can be reproduced by simply saving any session with the playhead not at time zero then opening with the previous working master that I mentioned [dc152b] and then opening the same session with the merge branch.

If you wish I can open a separate ticket for it, but since it occurred during the same changes and is also related to composition position I think it should be fixed as part of this bug.

I was writing this when the last push occurred...so please comment if the new problem is gone. Otherwise I remain on my working master for now.

Thanks.

[Philip Leishman]

I have pushed an additional fix on the bug-1721-composition-position branch

[musewhirl]

The saved playhead location is now remembered correctly. But there is still one slight odd behavior which did not occur prior to the changes. It's harmless, but should still be mentioned.

The oddity is only seen when RG is first launched and then a session is opened. As before this latest fix, the playhead still turns up in the wrong location briefly, but now it is whisked off to the last saved location. If another session is opened without closing RG, that one opens with the playhead correct first time.

Before any changes had occurred, on opening a session in any way, the playhead never appeared anywhere but in the correct place it was saved. I'll also add that this mysterious first location actually depends on the session being opened after launch i.e. it feels like stale data is being accessed, and that data does not cleared even when the playhead is saved to a new location. What happens then is that the same mysterious location is first visited before returning to the new saved location.

The branch can probably be merged to master since without the current fix, folks will notice if they can't return to where they left off. This remnant issue appears to only be a visual oddity, but who knows how it might manifest itself as code is developed further. At present I cannot tell if JACK clients are aware of the switcheroo.

On the bright side, the branch already looks good enough to continue working in until it's merged, and it's up to you whether the visual playhead move is addressed.

[Philip Leishman]

OK - the last change was a bit hasty. See newest version.

[musewhirl]

The first part of this post is easy:

The bug-1721-composition-position branch has now restored all of the JACK behavior to the way it was prior to the changes. So, this bug can definitely be closed.

For the second part, I can open a separate bug if you agree with the following:

Prior to the final fix just committed i.e. yesterday, I noticed a behavior that I have seen in Rosegarden before. But that was months, maybe years ago and quite common back then...however it had disappeared. Now I saw it a number of times while testing this branch...even though it is not truly reproducible on demand.

It involves playing MID in RG using JACK transport, sending that via USB interface to an external keyboard, and routing the audio (again via USB) from the keyboard to Ardour:

1. Activate JACK transport in both Rosegarden and Ardour
2. Ensure that both Rosegarden and Ardour have the same bpm, time signature etc
3. Place one segment down the time line on a track with a MIDI note at its start
4. Place the playhead one measure before that segment using RG and Ardour will automatically move to that location and JACK locations should match exactly
5. Arm Ardour for record and hit play in RG
6. Latency should cause the audio to appear at a later time in Ardour relative to the position of the start note of the segment in RG
7. Instead, the audio in Ardour can appear before the location of the first MIDI note sent in RG, although I don't see how?
8. NB, I had to zoom all the way in to see it in Ardour, because it's not a large discrepancy...just not in the direction I expected
9. Furthermore, only RG was upgraded recently, although I've learned in the past, that proves nothing
10. And it did happen...a number of times, but not every time.

We're not sending tachyon MIDI messages, so the above should not occur even once, unless something is wrong. And because I only upgraded RG, I guess it's appropriate to start questions there.

Like I said, it's been around before, so I can't claim it related to any changes in this bug (or recently on master) in particular, but I've not seen it for ages. In fact, it may have nothing to do with RG. I'll be using the new fix for a while longer and should be able to determine whether this issue has gone because of the final fix just committed, or is now just around again. In fact, I can even revert to the previous master I was using, check there and then report back.

In the mean time, provide some feedback here if there is agreement with the analysis above. There is no urgency for this one, but I would be interested in if you can reproduce this at all. Then it's just a matter of whether it's worth opening a new bug with just this issue, which can then double as a reasonable test case.

[Ted Felix]

Instead, the audio in Ardour can appear before the location of the first MIDI note sent in RG, although I don't see how?

RG shifts things forward and backward based on an estimate of latency. I'm assuming Ardour does the same. I'm guessing the estimate is a bit off. This sounds related to [#1682]. Might want to just add the info there.

It's probably something we should work on getting right once Philip has the JACK transport stuff simplified and working like it should. JACK is supposed to support sample level sync. We should take advantage of that.

[musewhirl]

I know you are going to hate me for noticing this, so bang on the table and get it over and done with :-) And yes, I missed it myself first time around.

1. Create a session
2. Scatter a few segments around..anywhere on any track within say the first 10 measures
3. Move the playhead to e.g. measure 3
4. Change the zoom setting of the session to 20%
5. Save the session
6. Close RG
7. Launch RG
8. I use CTRL-R to open the last session, but just open it any way you wish
9. The playhead appears on the screen in one location with no segments in sight
10. A moment later it changes location relative to that screen location and the segments appear

Fortunately, it's still at measure 3 as saved and the movement is indeed because of the zoom must be 100% on opening before changing to 20% which was saved.. The main point is that in [dc152b] it did not do that. The playhead and segments appeared all at the same time in their correct places i.e. no apparent playhead movement or any movement for that matter.

This time, I'm sure this could never be noticed via JACK, but there you have it...a difference in regression testing. Again, it's up to you whether you chase it.

Also, don't spend cycles on the other audio recording start mentioned in my last post, because I'm probably in a better position to check it. But I should add, although always using via record in Ardour, the test should involve hitting play in Ardour and checking the result, as well as hitting play in RG and checking. In both cases though, I can't see how the audio would appear before the first MIDI note location unless there is something going on with JACK positions...but I'll check both anyway.

[Ted Felix]

I can't reproduce this with latest master [ddf51c] so I'm hoping it is fixed.

I know you are going to hate me for noticing this

We'll just ignore you if we are overwhelmed. 🤣 Keep it coming...

[Ted Felix]

Philip's latest pushed as [3e4efb]. Please test latest git.

[musewhirl]

I just tested [ddf51c]...it's there alright...unless it's one of those GTK vs Qt vs OS deals. But I don't think so this time since it does not occur in the master I mentioned. I'll try and exaggerate the problem:

1. Launch RG and set its window size to fill your screen
2. Even get rid of the Transport window to avoid any distractions
3. Even collapse the parameters panels to see more of the measures
4. Create a session with no segments at all
5. I hope your default studio is the usual 100% zoom
6. Set the zoom to 20%
7. Place the playhead about one inch from the right side of the computer screen itself, and close enough to the start of a measure there
8. Make a note of the measure location
9. Save the session and Quit RG
10. Now launch RG, and unless your wm prevents it, it should open still filling your screen with the default studio
11. My default studio has 100% zoom
12. Now nothing but RG and it's empty tracks are sitting there
13. CTRL-R to open the saved session watching the screen
14. You should see the cursor appear at mid-screen, then jump to one inch from the right of the screen

It's the right measure though. But that mid-point appearance didn't happen before. Furthermore, that mid-point moves around depending on where you last saved the playhead. I didn't bother to find a pattern. As a result it's different for different sessions, but I do believe for any given session it's the same i.e. it must be related to something stored i.e. stale data?

As silly, trivial and apparently harmless as it seems, it simply did not occur in the previously mentioned master. There the playhead showed up in only once and at the right measure. Before the last fix, the last saved measure was actually lost resulting in always time zero. That's fixed. Now however, nothing is lost except the regression test behavior...and a mystery that the famous Sherlock Holmes wouldn't pass up :-)

But it is indeed very low priority, although seeing it now before more code is shuffled might make it easier to fix via diffs.

[Ted Felix]

You should see the cursor appear at mid-screen, then jump to one inch from the right of the screen

Ok, I'm able to reproduce this. I'll add it to the test plan and keep an eye on it to see if it blossoms into something serious, or hopefully just goes away in response to redesign and review.

[musewhirl]

Just as an afterthought, I should mention that prior to the test in the last post, I did a similar, but completely separate test where I did save the playhead mid-screen...but it didn't move much and was harder to see. I threw that session out though, and started with a fresh one. I'm not sure if that is why the playhead in the last test is associated with mid-screen before moving way out to an inch from the right. It could just be a coincidence, but it's worth saving the playhead at different locations while zoomed or using different already existing sessions where you temporarily adjust the zoom and save before opening with CTRL-R...it's all probably related to that zoom function. But in the unlikely event that this includes the position of the playhead in a previous session, that certainly could be a problem.