Same note playing on multiple different channels is output multiple times to one channel
h4yn0nnym0u5e opened this issue · 7 comments
Example file attached. Instruments start in unison, so I'd expect G4 (note #67) to be played on channels 1-3, but it's played three times on channel 1: then when 6 instruments are playing D4 (note #62), that's output 6 times!
// Playtune bytestream for file "..\brandenburg-3.mid" created by MIDITONES V2.2 on Wed May 5 19:36:14 2021
// command line: miditones -s2 -t=16 -v ..\brandenburg-3
const unsigned char PROGMEM score [] = {
// Brandenburg Concerto No.3
9,29,
0x90,67,81, 0x90,67,81, 0x90,67,81,
0x91,55,81, 0x91,55,81, 0x91,55,81,
0x92,43,81, 0x92,43,81, 0x92,43,81,
0x93,31,81,
0,166,
0x90,66,76, 0x90,66,76, 0x90,66,76,
0,167,
0x90,67,81, 0x90,67,81, 0x90,67,81,
0x91,59,83, 0x91,59,83, 0x91,59,83,
0x92,43,81, 0x92,43,81, 0x92,43,81,
0x93,31,81,
1,77,
0x90,62,70, 0x90,62,70, 0x90,62,70,
0x90,62,81, 0x90,62,81, 0x90,62,81,
0x92,55,86, 0x92,55,86, 0x92,55,86,
0x93,43,82,
0x81,
0,167,`
Wow, definitely a bug, thanks! I wasn't checking for the track and instrument to match before deciding that a note to be generated is the sustain phase of a previous note; that was code I added in January 2019 for version 2.0.
Would you mind checking that the attached version works for you, before I publish it to the repository?
miditones.zip
That was quick - thanks! I've given it a try and I'm pretty sure that's fixed the fundamental problem.
I'm not 100% sure of your note allocation intent, though. I think it may be struggling because the notes are jam-packed, so when it comes to allocating a channel it appears it's playing, when in fact it's just about to be freed up. This results in notes still (sometimes) getting shoved onto a different channel.
I've attached a version of the MIDI file with all the notes shortened by a tiny amount (13ms, it appears) which forces channels to be free when the next note starts. I think -releasetime ought to have the same effect, but suspect the channel has already been allocated before it gets the chance...
There's something odd about the original MIDI file: some "note off" commands seem to come 3 msec after they should, which requires the use of more tone generators temporarily. See the first page of the attachment. I tried -releasetime=5, and that seems to solve the problem, as the second page shows. For the file as a whole, the number of required tone generators decreases from 16 to 13.
If you think the MIDI file is actually ok and I'm parsing it wrong, let me know and I'll study the parsing log.
strange_midi_timing.pdf
You're quite right. I didn't create the MIDI file, and the extended notes don't show as such in the event list display of my DAW software (Reaper), though the slightly shortened ones do, so I'd assumed (always bad...) that everything was machine-generated to an exact length.
So, all is good, and a push to the master branch is indicated!
Ok, done.
But a bug can sometimes be a feature, so I added a proper -noduplicates option that eliminates identical notes coming from different tracks. That can be useful to reduce the number of simultaneously playing notes for synthesizers with limitations. Here's an unusual synthesizer playing the first minute of your MIDI file: https://youtu.be/vu4Q5NAvIVw.
Brilliant, thanks so much for your time. That certainly is an unusual synth - can I have one?!
Of course you can -- you just have to build it yourself.
https://github.com/LenShustek/TeslaCoil