musewhirl

Just in case you missed it, I'll draw your attention to the following supplied by @tedfelix in [bugs:#1721], in particular the third bullet point. I knew I had seen something about rounding errors before in a bug I created, but could not find which one. I am not sure what the current status is though: Summary of Remaining Issues JACK transport feedback loop. When rg receives a JACK transport update, rg sends another JACK transport update back out. This needs to be fixed, but the fix is non-trivial...

Sorry...it was all my fault. I've had my default studio set to 70 bpm for so long, I even thought it was the RG default, which is why I never mention it :-) When it comes to jack, I think I will try to remember to add the bpm to the steps to reproduce, especially like you said, in the light of [bugs:#1795]. It's a long shot and probably will not change anything, but just in case, also use 70 bpm with [bugs:#1802], which is jack related and also proving difficult to reproduce. For that one, I'll also...

Normally, I would open a new bug called: MIDI snare heard from previous segment. Let me know if you want that or will handle it here. But I am mentioning this problem here as yet another artifact possibly related to [bugs:#1802], since that bug is proving difficult for you (@lman) to reproduce. I am hoping that consistently pointing out how the old logic differs unexpectedly from the new, will also reveal why bug #1802 only occurs for the new logic. Steps to reproduce: Check "Use Jack Logic" Uncheck...

And as for behavior, I said I was unsure of what should happen, but logic might suggest that if RG started the jack transport and exits, it should stop it, whereas if some other jack client started it, then it should not. Just an idea. As for: Also Rosegarden does not issue a jack stop on process start. However it does jump to the position in the loaded file - usually 0 for a new session. Out of curiosity, with jack on verbose logging, does jack mention a transport position change? I didn't test...

Forget all the hard setup work in the last post. This post is going to be full of intrigue which might provide clues for easier testing. I decided to focus on the question I've asked all along. Why state=Running? The jack transport cannot be running...all I did was launch RG?. Nothing is running! Then I thought, well what if jack thinks it is? What could I have done to cause that? There are no other jack clients around? Then I thought, perhaps it never stopped at some point? Now for the intrigue:...

as long as debug is switched off I did build from master: [2453de], and of course when released, folks will in general not have built their own. Is that what you mean? In any case, I would have thought that when I choose the preference to not use the new logic, nothing, including using debug or not, will reveal that the new logic even exists. The idea being that if a user runs into a problem with the new logic, they just want it gone...period...so they can "forget it ever existed" and continue until...

When you say the play is of the silent type - do you mean the track is muted ? No, this does not involve muting. I mean two things can happen as you do this rapid play-stop-play-stop etc. On the first play at note start, you hear audio both with and without the new logic On a later play in the same rapid sequence, you don't hear audio (the silent type of play), when using the new logic. With the old logic you always hear audio. It actually doesn't even have to be that rapid a play-stop-play, so long...

I only mention this artifact here because during [bugs:#1802], the play-stop-play sequence also causes the percussion to play well after the intended point, and for a snare and kick the delay really stands out like a crazy drummer who "lost it for a moment". So, it sounds like a bug to the uninitiated, but only occurs for the new logic, not the old. Or more precisely, I never noticed the problem with the old logic or its randomness in that case could have just been more rare.