Philip Leishman

I believe "state=Running" does not mean that jack is rolling (the term jack uses when started). Running only means the jack process is running. Rosegarden does not issue a jack stop on exit - and it should probably not do it. 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. So the behaviour described above is exactly what I would expect. As for the xruns - I have no idea how to simplify the sync callback...

I still can't reproduce this. Difficult to explain how it could happen. Can anyone else reproduce it ? Any suggestions ?

I thought I would do this - seems easy enough. But while testing I ran into a nasty bug in the notation editor. Open the matrix-track-label.rg file. Select the three segments starting at the first bar in the first three tracks. Open the notation editor. Press Alt-DownArrow followed by Alt-PageUp. Bad things happen. I have a fix for this and the matrix, notation and event editors should now show the same text as the track editor. See Codeberg pull request.

I believe the duration of a percussion note is irrelevant. Certainly with General Midi I believe the note on causes the percussive effect and the sound decays independently of the note off. Indeed MatrixPercussionInsertionCommand adjusts the length of the previous note. Creating two notes at the same pitch at the same time seems rather an odd idea so I suppose the matrix editor discourages it. But it is not forbidden. Is there a bug here ? I am not sure.

I cannot reproduce this. When you say the play is of the silent type - do you mean the track is muted ? Is the track talking to an external midi instrument or is it using a plugin to create the sound ?

The sync callback now has no calls to the sequencer so there should be nothing to cause an xrun now (as long as debug is switched off). Are the xruns really with "client = RosegardenTransportClient" ?

I found a new problem with record and jumping. Fits with this bug report If you start recording at time 0 there is normally a count in of 2 bars. Sometimes however the recording starts immediately from time 0. The problem is with a race condition between the jack thread and the sequencer thread. See my bug-1798-jack-transport-record branch.

jack transport - move sequencer call from sync plugin to fix xruns