From: Julie S <msj...@ya...> - 2011-01-16 13:59:43
Attachments:
split-and-tie.png
|
Hello All, Issue 1 (Part 1): I've attached a screen shot illustrate the issue. I first pasted half notes in after the quarter rest. All half notes were blue (selected). Next I chose Adjust->Notes->Tie Notes at Barline That gave me the screen shot I've attached. The problem is that the split and tied notes are not part of the selection set any more. I believe they should be. Is this a bug. Issue 1 (Part 2): We have similar selection issues when we insert this notation in by hand. Enter a quarter rest at measure 1, beat 1 Enter the half notes. The split and tie works well, but they are not selected. Notes that are note split and tied remain selected. The problem is that if we want to add marks or do something with the note we just entered, we don't have a consistent selection process. * If the note did not get split and tied (it is already selected) * If the note did get split and ties, then we must first select it. I think this is a bug as well. ... What do you folks think? Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2011-01-16 22:45:34
|
On Sunday, January 16, 2011, Julie S wrote: > The problem is that the split and tied notes are not part of the selection > set any more. I believe they should be. > > Is this a bug. If you can figure out a good way to fix it, be my guest. The problem is that the split-and-tied notes are new events that were just created. They didn't exist before, while the notes that did exist and were part of the selection are gone now. There are probably a good dozen examples of the same kind of thing happening. Whenever you interpret notes, any notes whose durations changed are no longer selected. Whenever you do anything that causes rests to be recalculated, newly-generated rests are not part of the selection. The route to fixing all of this sort of thing is to add the newly created stuff into the selection, but I've always had a niggling feeling in the back of my mind that things would start to go wrong if we did that, and we probably never did that for some reason that was obvious at the time, years ago. And then at another extreme, it used to be that when you selected two notes and added a slur between them, the newly-created slur would be selected. I think it was the only thing selected. Because slurs are indications, which are a kind of event that spans some amount of time, this was causing me a lot of irritation when I was hand editing an imported MIDI file where I had to go and add several hundred slurs. The slur's start time was registering as the beginning point of new selections made by the keyboard, and this threw everything off. To cure all that, I modified Rosegarden to stop selecting the stupid slurs after creating them. > The split and tie works well, but they are not selected. > Notes that are note split and tied remain selected. Same root. Same discussion. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2011-01-17 03:32:22
|
Hello Michael, I just reworked the note insert split and tie stuff so that it is consistently selecting the note inserted. So that with your tie select features and the clean up of markings, ornaments, etc. It has shaped up quite a bit. You wrote: > There are probably a good dozen examples of the same kind > of thing happening. Agreed. > Whenever you interpret notes, any notes whose durations > changed are no longer > selected. Whenever you do anything that causes rests > to be recalculated, > newly-generated rests are not part of the selection. > > The route to fixing all of this sort of thing is to add the > newly created > stuff into the selection, but I've always had a niggling > feeling in the back > of my mind that things would start to go wrong if we did > that, and we probably > never did that for some reason that was obvious at the > time, years ago. It's true that this can get complicated. Even to get this one instance going took a bit of re-engineering. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2011-01-17 05:14:27
|
On Sunday, January 16, 2011, Julie S wrote: > It's true that this can get complicated. Even to get this one instance > going took a bit of re-engineering. When I was messing around earlier, it really struck me that having the selection evaporate after adding a mark was pretty irritating. It makes me think about what I did to stop the newly inserted slur from being selected. It was some eventsToInsert kind of thing like something I just saw in your commit, and I think I commented it out. It was a huge improvement for what I was doing at the time, but I suspect I didn't think it through thoroughly enough. Since you're of a mind to think about stuff like this, you might take a moment to survey the different ways we behave in this area, and get us started thinking about some plan for enforcing consistent behavior everywhere. I have a very solid and passionate sense that I did the right thing with the new selection behavior that makes tied groups behave as single units, but I don't have much of a sense of the rest of it at all. I could use some fresh eyes who aren't so used to and accepting of working around all these irritating quirks. On a related topic, it would be good to make undo remember what the selection was at the time. I have no earthly idea what I'm proposing in code terms, because I haven't thought about it at all. I'm just thinking of all the times I composed some carefully crafted selection, applied some effect, reverted the results, and then had to compose the entire selection again to try a different effect. I wonder what it would take to fix that. It's incredibly irritating. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2011-01-17 13:14:37
|
Hello Michael, > > It's true that this can get complicated. Even to > get this one instance > > going took a bit of re-engineering. > > When I was messing around earlier, it really struck me that > having the > selection evaporate after adding a mark was pretty > irritating. I'm not seeing that happen. I can make a selection and apply marks (in svn and Classic). > It makes me think about what I did to stop the newly > inserted slur from being > selected. It was some eventsToInsert kind of thing > like something I just saw > in your commit, and I think I commented it out. Now when I do things like add a slur to a selection set of a hairpin (crescendo / decrescendo). I get that annoying behavior you talk about. In Classic the newly inserted item is selected and the old selection is lost. In svn we just loose the selection entirely. > > It was a huge improvement for what I was doing at the time, > but I suspect I > didn't think it through thoroughly enough. Since > you're of a mind to think > about stuff like this, you might take a moment to survey > the different ways we > behave in this area, and get us started thinking about some > plan for enforcing > consistent behavior everywhere. Yes, making a list of these kinds of quicks along with a bit of background of current state of the related code could give everyone a chance to weigh in on how to proceed. From preliminary work on this little issue (which I'm not 100% satisfied with it solution) I do have some ideas about how to proceed. > > I have a very solid and passionate sense that I did the > right thing with the > new selection behavior that makes tied groups behave as > single units, Yes, it was the right things to do. They are indeed a single unit (musically), if people need to place articulations, fingerings, or ornaments on the other not or make a break to easily place a set of hairpins, etc. They can just slur the notes. I know its not technically the same, but will convey most of the real meaning. > but I > don't have much of a sense of the rest of it at all. > I could use some fresh > eyes who aren't so used to and accepting of working around > all these > irritating quirks. As long as slow is okay. I really don't want to get pressed by a hypothetical release date. (I still need to go back and clean up those progress bars that were barely half finished before the last release). > On a related topic, it would be good to make undo remember > what the selection > was at the time. I have no earthly idea what I'm > proposing in code terms, > because I haven't thought about it at all. I'm just > thinking of all the times > I composed some carefully crafted selection, applied some > effect, reverted the > results, and then had to compose the entire selection again > to try a different > effect. I wonder what it would take to fix > that. It's incredibly irritating. Hmmm....sorry, not gong to bite on that one. I think undoing and redoing selections is pretty tricky. Alternatively, It would be very handy to at least recall the last selection though...that might be an easier goal. That way you could at least get at the selection after an undo or if you accidentally started a new selection while building you that hand crafted selection set. But now we are getting into feature request territory. I'd prefer to stick with trying to get what we got working better and leave the fun new features to those with ambition for that thing. I'm still of the mindset that RG is a bit broken all around, and would prefer to stick with making what we have function instead of adding to it. It seem to be the work I do best and isn't the typical fodder for most -- except for you and I. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2011-01-17 23:33:28
|
On Monday, January 17, 2011, Julie S wrote: > I'm not seeing that happen. I can make a selection and apply marks (in svn > and Classic). I'm not sure what I was talking about either. Obviously this isn't really the problem I had in mind. > As long as slow is okay. Slow, or never. I'm not in any hurry either. > Hmmm....sorry, not gong to bite on that one. I think undoing and redoing > selections is pretty tricky. That makes two of us then. > I'd prefer to stick with trying to get what we got working better and leave > the fun new features to those with ambition for that thing. I'm still of > the mindset that RG is a bit broken all around, and would prefer to stick > with making what we have function instead of adding to it. Well, this kind of thing I'm talking about is in exactly that category. Our selection behavior is a bit broken all around. On the other hand, take the all-in-one duration toolbar thing we did for 10.x... It has at least two seriously ugly quirks I've never quite been able to track down far enough to even repeat consistently, let alone fix, and we spent forever *trying* to get that right on the money. When you have such a ragged army, you have to pick your battles carefully. -- D. Michael McIntyre |