playback of region on low bpm hangs at start of 2nd or 3rd loop

• Nov 25, 2018 - 21:53

Looping playback of a range hangs at start of the loop when speed is low.
The playback cursor hangs when it returns to the start of the loop range for the first or second time. Starting playback is normal. See the attached screenshot.
When I nudge the speed up a bit (e.g. +1 bpm) in the playback panel with the mouse wheel, playback continues the loop, until the next return.
Restarting the program won't help. When I let MS run in this situation, it dies silently after a minute or so. In the linux process monitor I see a constant i/o write rate.

Is not with all parts of the same song, but it is repeatable. Deleting measures before the problematic region won't help most time (i tried that a few months back in an other song).
It is related to the playback speed:
- happens each loop at bpm below 60,
- at bpm 60..65: each second loop, the first note does not sound correct (as in next point),
- 65..70 : the loop works normally, but some of the notes at the very start of the loop range are not played or sound staccato on each or each second loop.
- above 70: playback is normal
Having a (much) higher or lower default speed at the start of the songs has no influence.

In the attached song, it happens when using a play loop range for measures 17 .. 24. starting at 16, or 15+half, or 12, or ending at 22 or 21 won't help.
Playing loops with lines 1, 2, 1+2, 3, 4, 3+4 at low speeds were all normal.

The song contains a few hidden staves for bass, drums (also playing), claves (a click track, muted), and empty melody track (for a solo sax).

I encountered this problem for the first time when I upgraded from 1.(latest) to version 2.0 (Linux 64-bit appimage), Currently using v2.3.2 beta, (earlier v2.3 won' t run on my machine),
I enter my study songs myself using step mode input from a midi piano (hail to the new duration + repitch input modes), only the drum patterns are imported from a midi file (indirectly: patterns were once imported in a separate msc song, and copied from there to this song).

My system: Kubutu 18.04 linux 64-bit, kernel 4.15.0-39-lowlatency, using jack2 sound and midi backend, intel i7 cpu at 2.7 GHz, most times at fixed rate (having the cpu speed governor working has no influence)

I need these low speeds as I am using this as tool for my piano lessons. When I get to know the song better, I can use speeds above the problematic 65 bpm breakpoint.

Has someone a solution? Is this a bug?
Could it be left-over contents from an earlier-version MS song, as I tend to take a copy of a previous song with all the settings, clave/drum staves, and split piano staves as start for a new song after learing the piano contents.
In mean time I will export this song to a sequencer so that I can continue practicing this song.


Comments

In reply to by underquark

I removed all coda-type jumps: same,
removed all repeat/end bar lines (the one 2 measures before the end, and both around the first 2 lines: now get a soft tick in the left speaker when jumping from the loop end, but still hangs after 2nd loop.
Finally removed the last 2 measures, the ending, that have no meaning now: loop is normal now !

I introduced recently the to/coda keywords to make the song repreat twice with a turn-around before going to the ending measures, because couldn't get the repeat working using the repeat.1- and repreat.2 barlines (probably interfering with the repeat of the first 8 measures, or having 2 repeat-end bars and only 1 repeat-start). I never used looping the last 2 lines in that earlier version of the song.

Thanks for the feedback.
I can use the current layout for practicing.

Anyhow, for practicing purposes, I would like to loop (one of) the mid-section(s) of a song indefinately, until I press a midi/OSC (foot) controller, and then playback makes a fluent transition at the measure ending to the next section, bypassing the turn-around measures.

In reply to by FransK

update:
removing all capa/desgna jumps did not change anything; removing the last 2 bars did.
Now using repeat-barlines on measure 1 and last and repeat-1/repeat-2 lines on the last 4 bars, but the loop still hangs on the second pass.
But when switching on button "process repeats", the loop continues normaly (repeating the selected section) , with a minor tick in the speakers.

In reply to by FransK

You wrote:
Anyhow, for practicing purposes, I would like to loop (one of) the mid-section(s) of a song indefinately, until I press a midi/OSC (foot) controller, and then playback makes a fluent transition at the measure ending to the next section...

Well... this (foot controller) works:
1. Toggle the 'Loop Playback' toolbar icon with the mouse cursor, and leave it (cursor) hovering above said toolbar icon.
2. Place the mouse (or a suitable switch made from a 'broken' mouse) on the floor and, during loop playback, press with your foot whenever you wish to transition to the next section.

(The 'Toggle Loop Playback' icon remains active even as the score plays.)

Regards.

In reply to by Jm6stringer

Interesting approach, but my old mice have a broken wire.
I could try a bit of python, a midi and a gui test module, and simulate a mouse press on that button from a midi event.
Better even, if I get the osc command "/loop" working in MS (a short test with send_osc tool from a terminal window failed), the mididings tool could easily be used to convert a midi message from my foot controller to the osc command for MS.

b.t.w.
I started musescore.appimage in a terminal window, and when the cursor hung, the terminal line buffer got flushed immediately and completely by the repreated lines below :
"Process: playPosUTick = 47998, cs->loopInTick() = 48000, cs->loopOutTick() = 63360, getCurTick() = 47998, loopOutUTick = 63360, playFrame = 4799800
Process: playPosUTick = 47998, cs->loopInTick() = 48000, cs->loopOutTick() = 63360, getCurTick() = 47998, loopOutUTick = 63360, playFrame = 4799800
Process: playPosUTick = 47998, cs->loopInTick() = 48000, cs->loopOutTick() = 63360, getCurTick() = 47998, loopOutUTick = 63360, playFrame = 4799800
Process: playPosUTick = 47998, cs->loopInTick() = 48000, cs->loopOutTick() = 63360, getCurTick() = 47998, loopOutUTick = 63360, playFrame = 4799800
"

In reply to by FransK

One more update:
'hanging' now occurs more often, more locations.
But when forcing ALSA mode, PLAYBACK IS NORMAL AND STABLE !!
using "-a alsa" on the command line. in my normal settings use jack midi, and this option also makes MS to use alsa midi connections.

This again in jack midi mode:
Some more output from the console with a minute difference between first normal loop and when hanging, Look at the GetCurTick value:
- on the first return to the loop end, which plays normally :
playPosUTick = 9600, cs->loopInTick() = 1920, getCurTick() = 9600
- on the seconds return, playback hangs with :
playPosUTick = 1919, cs->loopInTick() = 1920, getCurTick() = 1919

Another strange messasge is 2x "Score::removeSpanner: Volta (0x3c27970) not found" ,
this appears always when oepnign the score, even when it was saved again.

frans@Slice5:~/Develop/mididings-filters$ /home/frans/.local/bin/MuseScore-2.3.2-x86_64.AppImage -a jack
Jack appears to be installed on this system, so we'll use it.
initScoreFonts 0x29b3350
JACK: sample rate changed: 44100
libpng warning: iCCP: known incorrect sRGB profile
JackAudio::connect
JackAudio::connect
Score::removeSpanner: Volta (0x3c27970) not found
Score::removeSpanner: Volta (0x350e8f0) not found

second loop, plays normal

Process: playPosUTick = 9600, cs->loopInTick() = 1920, cs->loopOutTick() = 9600, getCurTick() = 9600, loopOutUTick = 9600, playFrame = 882000

third loop, hangs, i.e. goes into endless loop printing message below, and cursor "trembles"

Process: playPosUTick = 1919, cs->loopInTick() = 1920, cs->loopOutTick() = 9600, getCurTick() = 1919, loopOutUTick = 9600, playFrame = 176280
... << repeated until crash after half a minute or so>>

Do you still have an unanswered question? Please log in first to post your question.