From: Tim <ter...@us...> - 2008-03-26 23:38:43
|
Hello. Was sick for a week. I'm baaack. OK. Regarding this pesky hung notes issue... Is it possible this is an (old) sustain pedal problem? When I start Muse and begin playing my music keyboard, ALL notes I play are stuck on (sustained). I simply press my sustain pedal once and it goes away. It's never been a big problem for me so I never mentioned it, but I can see that if someone DOES NOT have a sustain pedal, well... I will look into fixing that particular problem. So Mathias, Geoff, others, do you have sustain pedals? Now, about that mysterious wavepart muting bug we've been talking about... I have identified the exact cause! I'm looking at the cure, making sure it will work. Bear with me... Once I fix that, and a few other things, I believe Muse 'One' will be ready for its long awaited 'coming out' party !!! Werner my friend, your hard work has not been in vain... Mister Jonsson, be ready for my signal ! Hopefully a few more weeks, including testing... **************************************************************** For you coders, here's what's up with that wavepart muting bug... **************************************************************** In WaveTrack::fetchData(), it is expecting the part list to be sorted by position. Now, class PartList is always sorted by 'tick', in part.cpp : iPart PartList::add(Part* part) { return insert(std::pair<const int, Part*> (part->tick(), part) ); } But I discovered that upon loading a song, the tempo map is not properly converting the wavepart's frame to the correct tick, hence the waveparts are not being added to the part list at the correct positions. The trouble occurs when you move a wavepart, then it is re-added to the part list, but now at the correct position. But with other waveparts still at wrong positions in the part list, fetchData() becomes confused and actually thinks a wavepart is AFTER another wavepart when really it is NOT, hence fetchData() ignores the wavepart but plays the others! I could simply correct the song loading, to make sure that a wavepart's frame is being converted to ticks correctly before being added to the part list, but this is not really the correct way (conversion from frames to ticks is inherently not accurate, and waveparts are naturally of type FRAMES). My solution is this: fetchData() would obviously really like the waveparts to be sorted by frame, not tick. So I would do this: iPart PartList::add(Part* part) { if(part->type() == FRAMES) return insert(std::pair<const int, Part*> (part->frame(), part) ); else return insert(std::pair<const int, Part*> (part->tick(), part) ); } However, I need to make sure that no area of Muse relies on ALL parts in a part list being sorted strictly by ticks. For example, if some area of Muse works with a part list which contains both MIDI parts (sorted by ticks) AND wave parts (to be sorted by frames) and relies on sorting strictly by ticks, then I will have a problem... Well, anyways, hopefully that's some insight. If you understood that, then why aren't you coding Muse? :-) Later. Tim. |
From: Tim <ter...@us...> - 2008-03-27 05:02:30
|
On Wednesday 26 March 2008 07:53:47 pm Tim wrote: > **************************************************************** > For you coders, here's what's up with that wavepart muting bug... > **************************************************************** > In WaveTrack::fetchData(), it is expecting the part list to be sorted > by position. Now, class PartList is always sorted by 'tick', in part.cpp : > > iPart PartList::add(Part* part) > { > return insert(std::pair<const int, Part*> (part->tick(), part) ); > } > > But I discovered that upon loading a song, the tempo map is not properly > converting the wavepart's frame to the correct tick, hence the waveparts > are not being added to the part list at the correct positions. > The trouble occurs when you move a wavepart, then it is re-added to the > part list, but now at the correct position. But with other waveparts still > at wrong positions in the part list, fetchData() becomes confused and > actually thinks a wavepart is AFTER another wavepart when really it is NOT, > hence fetchData() ignores the wavepart but plays the others! > > I could simply correct the song loading, to make sure that a wavepart's > frame is being converted to ticks correctly before being added to the > part list, but this is not really the correct way (conversion from frames > to ticks is inherently not accurate, and waveparts are naturally of > type FRAMES). OOOPS Sorry Mathias I meant to say you are right, the problem IS those 'serial numbers' you mentioned before (I somehow thought you were talking about reference counts - different thing). The waveparts have the correct frame, but the tempo map is returning the 'cached' incorrect tick value, not truly 'converting' the frame to the right tick via the tempo map. This concerns the serial number scheme. I now realize the order, in a part list, of two waveparts with very close frame values is not important! If they are THAT close together, then it doesn't really matter which part is 'first' - one of them will prevail when drawing or playing. And not to worry - an STL iterator will iterate through all of the parts - even parts in the list with identical frames... Also, I realize now that when you move a part, I think it is NOT being re-added to the part list with the correct tick, like I thought, and had mentioned above. So I have to find a way to get the part list to 'invalidate' those serial numbers so that the correct tick is returned. Easy, but not good way: I could simply force the part list to return the converted frame to tick : iPart PartList::add(Part* part) { if(part->type() == FRAMES) return insert(std::pair<const int, Part*> (part->frame2tick(), part)); else return insert(std::pair<const int, Part*> (part->tick(), part)); } Ignore this, I think it's wrong..... > My solution is this: fetchData() would obviously really like the waveparts > to be sorted by frame, not tick. So I would do this: > > iPart PartList::add(Part* part) > { > if(part->type() == FRAMES) > return insert(std::pair<const int, Part*> (part->frame(), part) ); > else > return insert(std::pair<const int, Part*> (part->tick(), part) ); > } > > However, I need to make sure that no area of Muse relies on ALL > parts in a part list being sorted strictly by ticks. > For example, if some area of Muse works with a part list which contains > both MIDI parts (sorted by ticks) AND wave parts (to be sorted by frames) > and relies on sorting strictly by ticks, then I will have a problem... |
From: Mathias L. <mat...@da...> - 2008-03-27 07:45:30
|
That's indeed wonderful! I was probably confused and said reference count - it was quite a while since I was looking into those things, but serial number is probably more correct (from what I recall, which is very vague). Perhaps it was used for some kind of reference count in some way somewhere else, I'm not quite sure. Anyway, you seem to have a very good idea the problem. I don't know how many of the bugs I fixed back in the days that was related to missing action upon tempo changes and missing to the the part offset in the song in consideration. It seems it's not over yet either. You're really doing amazing stuff for MusE. It's much appreciated! /Mathias Tim skrev: > On Wednesday 26 March 2008 07:53:47 pm Tim wrote: > >> **************************************************************** >> For you coders, here's what's up with that wavepart muting bug... >> **************************************************************** >> In WaveTrack::fetchData(), it is expecting the part list to be sorted >> by position. Now, class PartList is always sorted by 'tick', in part.cpp : >> >> iPart PartList::add(Part* part) >> { >> return insert(std::pair<const int, Part*> (part->tick(), part) ); >> } >> >> But I discovered that upon loading a song, the tempo map is not properly >> converting the wavepart's frame to the correct tick, hence the waveparts >> are not being added to the part list at the correct positions. >> The trouble occurs when you move a wavepart, then it is re-added to the >> part list, but now at the correct position. But with other waveparts still >> at wrong positions in the part list, fetchData() becomes confused and >> actually thinks a wavepart is AFTER another wavepart when really it is NOT, >> hence fetchData() ignores the wavepart but plays the others! >> >> I could simply correct the song loading, to make sure that a wavepart's >> frame is being converted to ticks correctly before being added to the >> part list, but this is not really the correct way (conversion from frames >> to ticks is inherently not accurate, and waveparts are naturally of >> type FRAMES). >> > OOOPS Sorry Mathias I meant to say you are right, the problem IS those > 'serial numbers' you mentioned before (I somehow thought you were > talking about reference counts - different thing). > The waveparts have the correct frame, but the tempo map is returning > the 'cached' incorrect tick value, not truly 'converting' the frame to the > right tick via the tempo map. This concerns the serial number scheme. > I now realize the order, in a part list, of two waveparts with very close > frame values is not important! If they are THAT close together, then it > doesn't really matter which part is 'first' - one of them will prevail when > drawing or playing. And not to worry - an STL iterator will iterate through > all of the parts - even parts in the list with identical frames... > > Also, I realize now that when you move a part, I think it is NOT > being re-added to the part list with the correct tick, like I thought, > and had mentioned above. > > So I have to find a way to get the part list to 'invalidate' those serial > numbers so that the correct tick is returned. > > Easy, but not good way: > I could simply force the part list to return the converted frame to tick : > iPart PartList::add(Part* part) > { > if(part->type() == FRAMES) > return insert(std::pair<const int, Part*> (part->frame2tick(), part)); > else > return insert(std::pair<const int, Part*> (part->tick(), part)); > } > > > Ignore this, I think it's wrong..... > >> My solution is this: fetchData() would obviously really like the waveparts >> to be sorted by frame, not tick. So I would do this: >> >> iPart PartList::add(Part* part) >> { >> if(part->type() == FRAMES) >> return insert(std::pair<const int, Part*> (part->frame(), part) ); >> else >> return insert(std::pair<const int, Part*> (part->tick(), part) ); >> } >> >> However, I need to make sure that no area of Muse relies on ALL >> parts in a part list being sorted strictly by ticks. >> For example, if some area of Muse works with a part list which contains >> both MIDI parts (sorted by ticks) AND wave parts (to be sorted by frames) >> and relies on sorting strictly by ticks, then I will have a problem... >> |
From: Mathias L. <mat...@da...> - 2008-03-27 07:57:03
|
Tim skrev: > Hello. Was sick for a week. I'm baaack. > > OK. Regarding this pesky hung notes issue... > Is it possible this is an (old) sustain pedal problem? > When I start Muse and begin playing my music keyboard, > ALL notes I play are stuck on (sustained). > I simply press my sustain pedal once and it goes away. > It's never been a big problem for me so I never mentioned it, > but I can see that if someone DOES NOT have a sustain pedal, well... > I will look into fixing that particular problem. > > So Mathias, Geoff, others, do you have sustain pedals? > > Now, about that mysterious wavepart muting bug we've been talking about... > I have identified the exact cause! > I'm looking at the cure, making sure it will work. Bear with me... > > Once I fix that, and a few other things, I believe Muse 'One' will be > ready for its long awaited 'coming out' party !!! > > Werner my friend, your hard work has not been in vain... > > Mister Jonsson, be ready for my signal ! Hopefully a few more weeks, > including testing... > > > **************************************************************** > For you coders, here's what's up with that wavepart muting bug... > **************************************************************** > In WaveTrack::fetchData(), it is expecting the part list to be sorted > by position. Now, class PartList is always sorted by 'tick', in part.cpp : > > iPart PartList::add(Part* part) > { > return insert(std::pair<const int, Part*> (part->tick(), part) ); > } > > But I discovered that upon loading a song, the tempo map is not properly > converting the wavepart's frame to the correct tick, hence the waveparts > are not being added to the part list at the correct positions. > The trouble occurs when you move a wavepart, then it is re-added to the > part list, but now at the correct position. But with other waveparts still at > wrong positions in the part list, fetchData() becomes confused and > actually thinks a wavepart is AFTER another wavepart when really it is NOT, > hence fetchData() ignores the wavepart but plays the others! > > I could simply correct the song loading, to make sure that a wavepart's > frame is being converted to ticks correctly before being added to the > part list, but this is not really the correct way (conversion from frames > to ticks is inherently not accurate, and waveparts are naturally of > type FRAMES). > > My solution is this: fetchData() would obviously really like the waveparts > to be sorted by frame, not tick. So I would do this: > > iPart PartList::add(Part* part) > { > if(part->type() == FRAMES) > return insert(std::pair<const int, Part*> (part->frame(), part) ); > else > return insert(std::pair<const int, Part*> (part->tick(), part) ); > } > > However, I need to make sure that no area of Muse relies on ALL > parts in a part list being sorted strictly by ticks. > For example, if some area of Muse works with a part list which contains > both MIDI parts (sorted by ticks) AND wave parts (to be sorted by frames) > and relies on sorting strictly by ticks, then I will have a problem... > > Well, anyways, hopefully that's some insight. > If you understood that, then why aren't you coding Muse? :-) > > BTW, the main reason for me not coding MusE is RSI. Not to mention I have too many other projects - but that's not an excuse - it merely says that my priorities are wrong heheh. I've been having problems with my arms & hands for two years now. It's becoming better, but it's far from good and I try to stay away from coding on off-work hours. But it's difficult. Anyway, an off-topic flame-baitish question (related to the above). I recently decided to try to learn VIM properly and have given it a go for a couple of weeks. I also installed 'Vimperator' - a VIM-like plugin for Firefox which lets you navigate the web the VIMish way. I've preferred Emacs over VIM previously but with my RSI I've felt that the ctrl-x ctrl-y ctrl-yadda sequences have not been the best thing to do. I don't love VIM yet - in many cases I still swear over it, but I can definitely feel that it's better for my RSI to work in VIM-like environments over the regular arrow-key-based Windowsish paradigm. Have anyone around here experienced the same thing? I've long felt that it would be wonderful to have a better way to navigate the gui in MusE with the keyboard, I did some stuff on keyboard shortcuts long ago, would be nice to look into that again.... Using MusE in VIM-mode would rule! (but I wouldn't be surprised if I'm the only one thinking that) ;D /Mathias |
From: Mathias L. <mat...@da...> - 2008-03-27 08:02:56
|
Tim skrev: > Hello. Was sick for a week. I'm baaack. > > OK. Regarding this pesky hung notes issue... > Is it possible this is an (old) sustain pedal problem? > When I start Muse and begin playing my music keyboard, > ALL notes I play are stuck on (sustained). > I simply press my sustain pedal once and it goes away. > It's never been a big problem for me so I never mentioned it, > but I can see that if someone DOES NOT have a sustain pedal, well... > I will look into fixing that particular problem. > > So Mathias, Geoff, others, do you have sustain pedals? > > Forgot this one! No - I don't have any sustain pedal and it sounds a bit like my problem - but it's definitely not ALL notes (then it would be much easier to locate) - it's randomly. Playing keyboard with CVS-MusE is really annoying. I remember a long time ago there was a bug related to the realtime memory pool which was using some advanced stl-stuff that simply didn't work on some versions of libstdc++. I'm not sure it behaved like this though, but it had to do with notes "disappearing" in one way or another. /Mathias |
From: Geoff B. <son...@bi...> - 2008-03-27 22:00:17
|
On Thursday 27 March 2008 10:53:47 Tim wrote: > So Mathias, Geoff, others, do you have sustain pedals? sure do (x2 in fact) ok. let's put this one to bed; the hung notes from sus pedal was fixed in cvs months ago by Werner and it's totally fixed :D I've spent dozens of hours in production doing Orchestral arrangements and never a hung note. Even o'dubs properly now. 100%. Werner even fixed the '3d' piano roll auditioner to send note-off when selecting another part, so no hung notes there either ;) I also do not see any hung notes in playback (midi) at all.the only hung notes i see is when using 'audition' in the piano roll when moving notes along the timeline; when you drag, the note is retriggered @ the snap denominator and sometimes that will hang.often, even clicking all-notes-off won't stop them. Mathias, dunno why you're having the hung note issue. I don't use audio in MusE, but i don't run without the audio engine either....for me, afaict, it ain't MusE. Whilst I have your ear Tim, the spin-box fix for the other windows (midi pane,pianoroll,master edit etc) are the last frontier of fixes for me to claim MusE no1 seq full stop :) best, g. |
From: Geoff B. <son...@bi...> - 2008-03-27 22:07:23
|
btw Tim, sorry to hear you were sick ! hope it was not serious and glad you are now well again, ;) best, g. |
From: Mathias L. <mat...@da...> - 2008-03-28 08:18:35
|
Geoff Beasley skrev: > On Thursday 27 March 2008 10:53:47 Tim wrote: > >> So Mathias, Geoff, others, do you have sustain pedals? >> > > sure do (x2 in fact) > > ok. let's put this one to bed; the hung notes from sus pedal was fixed in cvs > months ago by Werner and it's totally fixed :D I've spent dozens of hours in > production doing Orchestral arrangements and never a hung note. Even o'dubs > properly now. 100%. Werner even fixed the '3d' piano roll auditioner to send > note-off when selecting another part, so no hung notes there either ;) > > I also do not see any hung notes in playback (midi) at all.the only hung notes > i see is when using 'audition' in the piano roll when moving notes along the > timeline; when you drag, the note is retriggered @ the snap denominator and > sometimes that will hang.often, even clicking all-notes-off won't stop them. > > Mathias, dunno why you're having the hung note issue. I don't use audio in > MusE, but i don't run without the audio engine either....for me, afaict, it > ain't MusE. > > Whilst I have your ear Tim, the spin-box fix for the other windows (midi > pane,pianoroll,master edit etc) are the last frontier of fixes for me to > claim MusE no1 seq full stop :) > > best, > > g. Thanks for that - I'm doing everything on my laptop which I've never used for stuff like this extensively before - so it might be something completely different. I find it strange though that I don't have the problem with the repository package, but if it works that flawlessly for you it is probably something else... I'm beginning to think compiler version, lib version etc etc... I will try to investigate. /Mathias |
From: nilitonilito n. <nil...@ho...> - 2008-03-28 19:12:41
|
Hi there, hi Mathias, > Thanks for that - I'm doing everything on my laptop which I've never > used for stuff like this extensively before - so it might be something > completely different. I find it strange though that I don't have the > problem with the repository package, but if it works that flawlessly for > you it is probably something else... I'm beginning to think compiler > version, lib version etc etc... I will try to investigate. Sorry if this has already been mentioned, but is jack running in real-time or not on your laptop? I ask that because a year ago there was a similar problem on MusE 2 when running jack in non real-time. Welter fixed the problem, maybe that's the same bug still not fixed yet in MusE 1.0... Cheers Nil > > /Mathias > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer _________________________________________________________________ Découvrez les profils Messenger de vos amis ! http://home.services.spaces.live.com/ |