Remove PortMidi and use MidiEmu unconditionally and significantly improve beat and midi timings in turn#1335
Remove PortMidi and use MidiEmu unconditionally and significantly improve beat and midi timings in turn#1335dgruss wants to merge 4 commits into
Conversation
|
In my opinion the biggest drawback of our synthesizer is the inexact timing. This is far worse than the klicking sound due to the missing decay. |
|
I intentionally kept the piano style sound as a separate commit. the timing of this is much better than the actual midi before. |
|
The decay is what I don't like. In a percussive organ only the overtones decay. The fundamental frequency does not.
There is nothing in this PR to improve the timing. Midi events are still quantized to ReadData intervals. |
Based on testing in windows. Multiple systems where actual midi has audibly worse timing. |
|
i addressed the timing issues (organ + timing like beats) |
|
@s09bQ5 the quantization is now gone, it uses the same timing as the beat clicks. However, this is not perfect either. On my system many beat clicks (and now also midi notes) are skipped without #1109! With #1109 it works very fine. But then again #1109 is open since half a year despite bug reports from other users as well, and confirmation that #1109 fixes the issue for them and I don't know if or when it will be merged, but this might be a good time to consider that one again. |
|
Just a quick comment, I'll try to look more in-depth later: I hard agree with s09bQ5 here that I vastly prefer the current "monotone" sound on Linux over that of the sort-of piano on Windows (I tested it once at some point to verify Midi still worked on Windows). Main reason is absolutely the length, because people do still love to produce txts of 3 beats note - 1 beat gap - 3 beats note - etc. The other thing I immediately noticed is just how much easier the "monotone" sound is to hear. The piano becomes completely indistinguishable if the actual song happens to have beats (or worse: an actual piano) at the same time of the note starts, whereas the monotone doesn't care. And of course, some people will line up the midi piano with the music piano, which creates garbage txts for words that start with The monotone can act more like a bleep/censor filter, where you just don't want to hear the vowels. |
|
Agreed, and I think this is addressed in the latest version. I moved away from the piano-like envelope based on @s09bQ5 suggestion to use an organ-ish sound: Only some upper harmonics have a short percussive/organ-ish onset, which is great to hear when a note starts. The main part of the note stays stable for the entire note duration. So the goal is not to sound like a piano/instrument, but more like an editor cue/bleep that tells the user where the note starts while also sustaining the sound for the full note length. It should sound pretty monotone on longer tones now. |
paths Schedule editor click and note cues in the MidiEmu stream so they share one timing path. Replace the removed rimshot sample with a synthetic click, route sing beat/click assist through it, and clean up obsolete editor draw-loop timing state.
dgruss
changed the title
|
@s09bQ5 if you find the time, please take another look. The editor preview timing is now unified: beat clicks and MidiEmu notes are scheduled into the same audio stream, so they use the same sample clock instead of separate draw-loop timing paths. I also removed the old beat-click wav sample and replaced it with a synthetic MidiEmu click, so we no longer depend on the external rimshot asset + the beat click timing should be more precise with this as well (and the occasional skipping is resolved with this as well). If we merge this PR, I think these PRs are obsolete:
|
|
Didn't look at the code yet, but it sounds great! |
3 participants
This PR removes the PortMidi/MIDI backend selection path and makes the built-in MidiEmu output path unconditional.
UseMidiEmu,UsePortMidi,UseMIDIPort, and related MIDI backend conditionals.MidiFile,MidiCons, andmidiemu.