Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MIKMIDISequencer stops recording almost immediately after starting if its sequence is empty. #45

Closed
armadsen opened this issue Feb 20, 2015 · 5 comments
Assignees
Labels
Milestone

Comments

@armadsen
Copy link
Member

See the MIDI Files Testbed project in the 1.1 branch to reproduce this. Maybe I've screwed something up...

@armadsen
Copy link
Member Author

It also plays a single piano note when you start recording. I haven't investigated at all, but perhaps that's a pre-roll problem?

@armadsen
Copy link
Member Author

I pushed a fix for this. I'll let you close this if you think the fix looks OK. It's simple enough that I worry I overlooked something. I made a new issue #46 for the piano note at the beginning problem.

@armadsen
Copy link
Member Author

We discussed adding a property to make this configurable. The thinking is that some apps may want recording a new track in an existing sequence to stop when the end of the sequence (ie. longest track) is reached. The default for this property would be NO (ie. doesn't stop).

I think we should also extend the length of an empty sequence to something reasonable.

@armadsen armadsen modified the milestone: 1.2 Jul 6, 2015
@armadsen
Copy link
Member Author

armadsen commented Mar 3, 2016

I hit into an issue related to this change today:

  • Create an MIKMIDISequencer
  • Add a track to its sequence with 20 notes, one on each beat.
  • Set the sequence length to 16.
  • Start recording
  • When the 17th beat is played (at timestamp 16), rapid clicking is heard.

During recording, the sequencer continues processing without stopping when it hits the end of its sequence's length. The issue is that if there's a note right on the timestamp for the end of the sequence (16 in this case) it is repeatedly scheduled every time through the processing loop.

armadsen pushed a commit that referenced this issue Mar 3, 2016
…s last note in a sequence while recording.
armadsen pushed a commit that referenced this issue Jun 1, 2016
@armadsen armadsen modified the milestones: 1.7, 1.6 Jun 1, 2016
@armadsen armadsen modified the milestones: 1.7, 1.8 Mar 21, 2018
@armadsen
Copy link
Member Author

armadsen commented May 10, 2020

Closing because I can no longer reproduce this. I believe it was fixed by
0e287cc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants