MIDI events eaten up on loops about qtractor

[rncbc]

which notes in particular are not heard? the ones in the loop or the ones you play on the keyboard?
otoh. 4beats seem to be a very short a loop: does it span over 1bar only? what tempo (bpm)?
you must notice that notes in the loop clip that span across the loop-end/rewind point will hang (ie. the note-off event is lost): is that what's happening?

[schnitzeltony]

I was a bit unprecise - should not write issues after first beer...

To give a better picture, I attached an example session:

looptest.zip

To test:

• you might need to align path/name for FluidR3_GM.sf2
• Move to 'jam' track (auto-monitor enabled)
• Press 'play'
• Play 8th-notes on a MIDI keyboard: The notes played in the last beat of 4th bar are ignored (hope I used terms 'bar' and 'beat' correctly this time)

[rncbc]

aha. confirmed. incoming live notes from active input (via auto-monitor) seem to get dropped when playback is near about half-a-second before the loop-end turnaround/rewind point, then resuming as usual.

again, this only affects live input MIDI events being monitored, not the ones already on a MIDI clip.

now that i can replicate the phenomenon maybe i can look into and tame it (or not:)).

thanks for clarifying this: now sure we're on the same page :)
cheers

[rncbc]

ok. it is now clear that the so called phenomenon only seem to happen if (and only if) the loop-start point is set under the absolute first half-second of the session.

[schnitzeltony]

Cool I can confirm either. If finding a fix does not cause too many efforts for you - feel free. But I can live with that an am happy again!

[rncbc]

hi. a fix in the works... however i'm afraid it may break something else... or open a can of worms :/

[schnitzeltony]

Yeah - I think I know what you mean...

Two suggestions:

1. If you push the fix in a new branch, I could support you with testing.
2. If the fix is too dangerous: How about dropping a warning in log if a user sets loop mark at the beginning of the session - either by moving around or opening old session.

[rncbc]

the fix is now pushed into the midiex branch.

obviously, all MIDI capture related functions are affected: input monitoring, clip recording, punching and overdubbing; at first glance it seems to work right and better on this very issue regard.

however it needs more thorough testing and your offer is of course welcome.
the behavior of MIDI inserts and aux-sends should be also of concern. nevertheless.

cheers && thanks

[schnitzeltony]

FWIW: Up to now I jammed, recorded and punched in with different start-/end markers and did not find an issue.

[rncbc]

ok. thanks. the midiex branch have been updated with commit f728b7d.
please keep harnessing it... if all goes well a merge into master may happen later today. thanks.

[schnitzeltony]

Back to 'real-life' challenges - sigh. I will add changes to my build tonight and penetrate further. In case of issues I will let you know.

Thanks for taking care.

[rncbc]

fyi. the 'midiex' branch is now merged into 'master'. closing issue...
cheers