musewhirl

I hesitate to add another post when you've probably got enough information, but the direction I am guessing in is the following: When RG specifically tells JACK that the transport has started and is rolling, and fails to notify JACK that it has stopped simply because it is the end of a composition, then on some occasions when a new session is started, JACK broadcasts that the transport is still rolling, RG picks that up when the the new session opens and immediately does what it should do i.e. plays...

I understand the logging limitations on your part, but your logging provides all of the necessary information based on my last post. If you have a reason for not letting JACK know of the composition end stop, then obviously nothing can be done about it. I must point out that my guess...a total guess...is that when JACK is not told of the transport stop at the end of composition, the SyncTimeout, fSyncTimeout, etc might be affected i.e. at some point the timeout will occur and perhaps that causes...

A long post, but can't be helped. Based on observation, I am guessing that this problem occurs when RG is allowed to play a composition to its end without user intervention. After that, no matter what session is opened, that RG instance's log entries are different from then on until it is restarted. In addition, I think it is also responsible for RG randomly starting or stopping by itself for any session after that point because the RG/JACK interaction is different. For this post: Normal means that...

So, finally RG can apparently start by itself after all, although the actual cause is still not clear. As mentioned earlier in this post, normally the "button pressed on the UI" message turns up when I hit the Enter key to start play: [RosegardenMainWindow] slotPlay(): bug1693 Starting or stopping playback [RosegardenMainWindow] bug1693 Play button pressed on the UI. [SoundDriver] SoundDriver::initialiseAudioQueue -- new queue has 0 files [AudioPlayQueue] dtor... [AudioPlayQueue] This tends to be...

Lengthen segments using "Allow editing during playback" feature

I thought RG stopped by itself immediately after I had hit the Enter key to play, but I could not be certain...NB the playback cursor was still at the start when I looked. I checked the logs and noticed that the logs did not mention anything about my stopping via the UI: [RosegardenMainWindow] slotPlay(): bug1693 Starting or stopping playback [RosegardenMainWindow] bug1693 Play button pressed on the UI. [SoundDriver] SoundDriver::initialiseAudioQueue -- new queue has 0 files [AudioPlayQueue] dtor......

I've not seen a single start/stop glitch since I moved first to the [bug1693] branch to look for the problem, and then back to [2f2c01]. It might have been related to a master branch I was using at that time. As a matter of fact, I should have added the problem master ID when I opened this bug...at least I could have gone back to it to check. I will work with the re-based bug1693. The logging alone did not cause any xruns as far I know. I only get those when I am actively opening and closing windows...

Something I forgot to mention, but doesn't change the fact this isn't a bug. Most of the time, my file manager is sorted by modification date with most recent being first. So, in a directory containing RG directories, the ones I am currently working on are at the top. Occasionally, I go back to a really old session just to look at something, and from then on that old session is among the top directories because it was modified by that lock file, although no other RG file in that director was modified....