#1378 "late?" first note of segments
I'm new to RG, searched the docs and bugs and didn't find anything related
to this, so I'm sorry if I missed it.
Using 12.12.25 on FC17- keyboard and motif rack ES
The very first note of a segment is "late" and "fades in". I know.. this sounds strange... It seems like there may be some program change info or something that is sent right as the first note is sent - that causes the synth to need some "recovery time" - and that makes it late. This is not a latency issue, as the note ends on time, and the rest of the notes are fine.
I can get the problem by:
Start a new session
load up the banks and assign instrument to track 1.
record on track 1: 4 1/8 notes, whole rest, 4 more 1/8 notes
Then play it back.
The very first note is not crisp - it's late and weak. The remaining notes are fine. Then, split the segment into 2 during the whole rest.
Now play composition back, and the first note of EACH segment is weak.
I looked at the event editor, and there is nothing obvious in there.
[there were some key signature messages and clef messages and a few rests. I removed them - but they had no effect on this]
One more thing, possibly related:
The keyboard (that was used to record) is in the same midi loop with the synth during playback- (I just turn it down and ignore it because it's not my primary
output hw) The KB (and maybe this is standard - I don't know) if it gets a command for a bank/program it doesn't have - it just disables all of it's outputs and takes nap. I can tell that it got a program change it can't handle because the sound selection light all go out. Now... At the exact moment that the first note is supposed to sound in each segment - the lights go out. If I quickly press a button an place the kb into a valid patch, then the notes play.
Don't think this is another problem that needs fixed - I only mention this as an indication that I can tell there are program change messages being passed at the same time as the first note.... maybe more of a clue as to root cause.
From a SW perspective, it makes sense that a program change should be send at the beginning of playback, and the beginning of each segment on a track... but some hardware needs some time to shift to that new program - even if it isn't changing... Is that what's happening here?
Thanks very much. If there is anything that I can provide to help, please do ask.
Lee
PS... Just before I hit "save" on this I went and tried 2 more things that make me even more convinced that the root cause is the "program change recovery time" of the synth.
First I tried putting the synth in slave timing mode, and RG in master... made no difference at all.
Then, if I disable the bank and program change in the instrument parameters window and play the track - all the notes sound as they should. So I am assuming that RG must, by default, send the Bank and Program change messages very near the time of the first note of each segment. One fix would be to have a parameter that a user could set as "instrument program settling time in milliseconds" and RG would back-up that many milliseconds from the first note to send the program change info. I don't know ... you all probably know better ways to fix this since you know the code.
This must have caught me at a bad time, and it's taken until now for me to just go hunting for things I might have overlooked.
There's something to your hypothesis, Lee.
The example file Djer-Fire.rg is a good one to test with, because it has a very large number of segments.
I looked at the raw XML, and it has 1 and exactly 1 "programchange" event in it.
Start KMidiMon
Filters -> MIDI Channel -> None (unchecks everything)
Filters -> MIDI Channel -> [x] Program change
Direct Rosegarden to send the data to KMidiMon
Hit play
See attached file. (It turns out it has the entire dump, and it's hard to read directly. Well, repeat the experiment for yourself or load the file into KMidiMon and use it to filter the output.)
Analysis of program change messages:
ch 1, 24 is in here 7 times
ch 10, 0 is in here 35 times
And so on and so forth. 1 is always 24, 5 is always 33, 7 is always 34, and so on and so forth.
It looks like it could be the round robin channel allocation thing grabbing and clearing new channels as needed, but if they're so needed why are the program changes on every channel always the same each time?
Taking a shot in the dark and assigning to Tom to have a look see. He might recognize a pattern.
In the meantime, I suspect setting channels to 'fixed' would cure this.
He says before looking to discover they are set to fixed already.
What the hell?
Just wanted to chime in with a "me too" on this bug, and provide some more infomration about the circumstances under which it occurs.
Similar to Lee, I'm using Rosegarden with an external MIDI box, also a Yamaha Motif Rack (but mine is an XS). I get the exact behavior he does (messed up audio on every segment start).
This bug did not exist with Rosegarden 11.11.42 packaged with Ubuntu 12.04. This bug does exist with Rosegarden 12.12.25 packaged with Ubuntu 13.04 and whatever is packaged with Ubuntu 13.10. So, something broke between 11.11.42 and 12.12.25.
Another manifestation of this bug (I'm guessing) is that dynamic changes of instrument parameters while audio is being played results in similar stutters and interruptions of the audio.
Because of this bug, I've had to dedicate a laptop to running the older Ubuntu 12.04 just so I can use the older Rosegarden on it. A sad state of affairs indeed. I wish I knew enough about Rosegarden to try to help fix this. Alas, I'm pretty busy with my own open source project at the moment.
Much thanks to everyone who has worked on Rosegarden. It's a great tool, and I hope that this bug can be fixed soon so that people don't get turned off because of it.
Doug
Thanks. That sounds like my fault, and somehow I missed Lee's bug report.
Setup commands are usually sent just-in-time, and it sounds like that
isn't soon enough for some hardware.
I can make it so that setup is sent slightly ahead of time, say, half a
second. After I do that, I won't have a way to verify that it works - my
setup doesn't exhibit the problem - so if you can tell me whether it
works, I'd appreciate it.
I'll let you know when I have made the changes.
Much thanks, Tom, for looking into this.
Your hypothesis, that the MIDI notes are happening too soon after the control messages is plausible, but there's one fact that make me wonder... If this is true, then why did the bug not happen in 11.11.42 and previous versions? I assume there was no such delay code in those versions.
In any case, I gratefully await your results and will be happy to test any changes.
Doug
I committed the (hopefully) fix to trunk yesterday. This sends setup
(program change and initial controller settings) half a second before they
are used. At least when that's possible - can't do it for beat 1 of
measure 1.
As I mentioned, I have no way of verifying it, so I'd appreciate hearing
whether this fixes it.
Ah, what glories my ears now behold!
Yes, it is beautifully fixed. Much appreciated.
No worries about notes in measure 1 beat 1. No version of rosegarden could ever deal with that. I've gotten used to starting all my compositions at measure 2.
Gratefully,
Doug
You're quite welcome.
Fixed in r13657