From: Tim E. R. <ter...@ro...> - 2012-04-23 03:10:53
|
On April 22, 2012 5:36:58 PM Jeffrey Hubbard wrote: > > Verified. Somehow you closed the Arranger. > > > > Click View -> Arranger View to see it again. > > Ah, makes sense... I was closing the arrangement window > before closing the parent window, I must've saved the > project whenever the "project has unsaved changes..." dialog > popped up, therefore saving the closed arrangement window > to the project state. > > > And as you say you held shift. > > Back to the last email I sent, I think it's a combination of running a > fairly high display resolution makes the line so thin that it's very > difficult to actually get the mouse over the line so that the cursor will > appear. I have to make several passes over it very slowly while holding > shift to actually get a cursor, which was how I missed it on the first ~10 > attempts.. I think making the automation envelope ~4px thick instead of > 1px(?) thick would fix the problem. Yeah I've noticed that. A bit fussy sometimes. > > >OK this sounds weird. What theme and MusE Qt style (Appearance Settings) > >are you using? > > I was using the "Keep Qt System Style", but I tried a few others just now, > and all the same thing. Possible to get a snapshot of the open menu? > > >We've got a double note entry in the fifth part of Track 1, > >at bar 006.03.288. > > > > There are two notes there, one is small at len=36, the other is len=272. > > Tested OK with our Deicsonze and Calf Organ and my external KB's sounds. > > Definitely an LMS synth problem, I'd say. > > > >When I move the small note out of the way up or down, the stuck > >note does not occur. > >Your voice allocation or voice stealing code perhaps? > > Quite possibly... I think that's something I can probably fix then, but I > think that might allude to a problem elsewhere, or at least areas that > could possibly be improved for these reasons: > > 1. I recorded that loop on my M-Audio Oxygen 49 keyboard. The keyboard > itself or it's driver may have sent the notes like that(obviously I didn't > hit the same key twice simultaneously with 2 different releases), or that > could've even been a bug on Muse's end(but I would think it's probably > the MIDI keyboard or it's driver). It's possible the notes were in fact played at different times but somehow our quantization moved them together slightly. Check the menus there's a quantization dialog I think. > > Perhaps Muse could introduce some sort of duplicate note filtering into the > recording process? I can't imagine a situation where that could ever be a > desirable behavior. Someone added that on one of the menus I think. Remove Overlapping Notes I think. > > 2. I couldn't tell that the notes actually overlapped because there was no > visual indication. Maybe you could create a visual indictator, or maybe > just not allow overlapping notes at all? You're in luck. Look closely, all drawing has transparency. Overlapping parts and notes are see-through, including the black selection colour. You can adjust the transparency in the Appearance Settings -> Colors from 0 completely see-through, to 255 completely opaque. It's set at 190 or something by default. You may need to adjust it. The transparency for part and note /borders/ is fixed at 100% opaque. > > I think that a good strategy would be that when, for example D#-3 plays, and > another D#-3 plays again without a note-off event, that a note-off event > should be fired immediately before firing a 2nd note-on event on the same > key. It might also be good to track where Muse has sent a plugin a note-on > event, and not send a note-off event if a note-on was never sent, although > you have to be careful there because any bugs in the code might result in a > whole slew of random hung notes. > > Of course, if 2 note-on events fire simultaneously on the same key (or > within a very short time of each other), you probably just want to discard > the first note-on and the 2nd note-off. I say the 2nd note-off because it > should be apparent that somethings wrong when the same note fires twice at > the same time, and it's probably not a good idea to take for granted that a > 2nd note-off event will ever actually fire. > Mm, I'd have to say our note-on, note-off, and stuck notes handling is pretty solid now, I'd be surprised if there's still errors like that. Although, my last major work there was only months ago. So it just shows how bugs can pop up. Your file works with other synths, and ext. HW via midi. We have a 'notes to be played' list, and a 'stuck notes' list which is automatically maintained according to note length when the notes are cued up to play. The notes are pretty much guaranteed to be told to turn off when their time runs out or when stop is hit. And it should work when overlapping like this. Cheers. Tim. > > Thanks, > Jeff |