| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
When Sekaiju cannot open a MIDI device; if you click OK on the dialog box, it
will just forget the device.
The new behavior is not great, but better: an Abort, Retry, Ignore
error dialog is shown instead. Abort will forget the nonworking MIDI
device (same as OK) before. Ignore will keep the device in the list.
Retry will try opening it again: very useful for plugging in a USB
MIDI adapter and trying again.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I discovered this when Sekaiju crashed when I tried to copy some
notes around within a track using cut and paste.
Steps to reproduce: Simply create a large amount
of musical material (say on the order of dozens or hundreds
of events). Then in the tracks view do "select all", and try
to cut or copy the material with the context popup menu,
or the shortcuts. Sekaiju will crash. If not, just increase the
amount of material and keep trying.
With this change i have repeatedly cut, copied and pasted
thousands of MIDI events, repeatedly, without any crash.
The bug is that the clipboard publishing function
CSekaijuDoc::SetClipboardTextPrivate9 calculates the clipboard size in
characters but then allocates that many bytes for the text rather than
characters! The 32 byte padding which was there doesn't help,
except when the data being put into the clipboard is very small.
All we need is to allocate the correct string size, in bytes,
which is (length + 1) * sizeof(TCHAR).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Steps to reproduce:
- rewind the position
- press record
Sometimes, the accented beat is not heard.
I suspected race conditions at first, so I restructured the order of operations
in CSekaijuApp::StartRecording so that the MIDI clock is not started until the
very end, when all the state variables have been assigned, like m_bPlaying and
m_bRecording. I'm keeping these changes.
But the real problem was in CSekaijuApp::PlayRecordProc, in the block of code
that plays the metronome. There, the check "pSekaijuDoc->m_lOldTime ==
pSekaijuDoc->m_lNewTime" was causing the issue. Although StartRecording sets up
this condition, there is no way for the truth of the condition to be maintained
through to that block of code. The clock runs freely, and is periodically
sampled by the thread whenever it wakes up from sleep. The condition is not
necessary.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
during recording when midi through is disabled in the binding array.
The problem is caused by the fact that the real-time events are inserted into
the tracks just at the start of the next clock period. When the next clock
period comes, those events are played back! (This also causes a delay:
since the looped notes will not play until the next clock advance!)
To solve this problem we do two things:
1. Rearrange the processing so that playback, metronome generation
et cetera are handled first in every processing period, and the real-time
input is handled afterward.
2. Now that real-time inputs are handled after playback, we can simply insert
them into the CURRENT time period. Since playback is already done
for the current time period before, they will not be played.
Referring new events into the current time period is done by subtracting
one from the clock value. Sekaiju's logic for handling time periods
is that each time period is an interval that excludes the current
time: [old_time, new_time). So when an new event is inserted at new_time,
it becomes part of the next period. By inserting an event at new_time - 1,
we make it part of the current period.
Hey, I wrote some comments in Japanese. :)
|
| | |
|
| |
|
|
|
|
| |
input ports to output ports which is user-configurable and
stored in the .ini file. Tracks no longer perform "MIDI thru",
but only capture and playback.
|
| | |
|
| |
|
|
|
|
| |
which must be preserved when we store such names in the .ini file.
The .ini API will strip whitespace; but we can add quotes around
a value to preserve it.
|
| |
|
