From: D. M. M. <ros...@gm...> - 2009-06-27 03:01:05
|
On Wednesday 24 June 2009, D. Michael McIntyre wrote: > On Wednesday 24 June 2009, dmm...@us... wrote: > > * restore the clef inserter (tested, and works) > > Uhhhh... That's embarrassing. I tested the toolbar thing, but that > doesn't actually use the code I just committed, which is totally broken, > and crashes. I don't think my code is actually broken, but the dialog on the other end of the slot I restored is very trashed. I has proven more annoying to correct than many other dialogs whose layouts I tweaked, and I've spent two days on this little sub-project so far. I don't know if I'll have anything done today or not at this rate, and I'm not getting anything else done while I whittle away at this unexpectedly thorny problem. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-09-03 19:02:02
|
Dear Heikki, You last commit may cause a conflict with my pending merge. Since, I've altered a lot of code in NotationView.cpp related to notes and durations. But maybe not. Maybe we could find a more elegant way to not allow the very sort and very long notes you are trying to warn about then throwing up a message box that disrupts workflow? I just worked in notation_toolbar_2 branch to rid ourselves of the things. Sincerely, Julie S. --- On Thu, 9/3/09, hj...@us... <hj...@us...> wrote: > From: hj...@us... <hj...@us...> > Subject: [Rosegarden-bugs] SF.net SVN: rosegarden:[10809] trunk/rosegarden/src/gui/editors/notation/ NotationView.cpp > To: ros...@li... > Date: Thursday, September 3, 2009, 2:56 PM > Revision: 10809 > http://rosegarden.svn.sourceforge.net/rosegarden/?rev=10809&view=rev > Author: hjunes > Date: 2009-09-03 18:56:05 +0000 > (Thu, 03 Sep 2009) > > Log Message: > ----------- > Warn about too long and too short dotted notes. > > Modified Paths: > -------------- > > trunk/rosegarden/src/gui/editors/notation/NotationView.cpp > > Modified: > trunk/rosegarden/src/gui/editors/notation/NotationView.cpp > =================================================================== > --- > trunk/rosegarden/src/gui/editors/notation/NotationView.cpp > 2009-09-03 15:13:42 UTC (rev 10808) > +++ > trunk/rosegarden/src/gui/editors/notation/NotationView.cpp > 2009-09-03 18:56:05 UTC (rev 10809) > @@ -1893,6 +1893,14 @@ > QString > noteToolbarName; > > Note::Type noteType > = note.getNoteType(); > + if (noteType == Note::Breve) > { > + /* was sorry */ > QMessageBox::warning(this, "", tr("There is dotted version > of double whole note. Use ties for longer notes.")); > + return ; > + } > + if (noteType == > Note::Hemidemisemiquaver) { > + /* was sorry */ > QMessageBox::warning(this, "", tr("There is dotted version > of the shortest, sixty-fourth note.")); > + return ; > + } > int noteDots = > (note.getDots() ? 0 : 1); > > QString > actionName(NotationStrings::getReferenceName(Note(noteType,noteDots))); > > > This was sent by the SourceForge.net collaborative > development platform, the world's largest Open Source > development site. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Rosegarden-bugs mailing list > Ros...@li... > - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-bugs > |
From: Heikki J. J. <hj...@gm...> - 2009-09-03 19:18:16
|
2009/9/3 Julie S <msj...@ya...> > Dear Heikki, > > You last commit may cause a conflict with my pending merge. Since, I've > altered a lot of code in NotationView.cpp related to notes and durations. > > But maybe not. > > Maybe we could find a more elegant way to not allow the very sort and very > long notes you are trying to warn about then throwing up a message box that > disrupts workflow? I just worked in notation_toolbar_2 branch to rid > ourselves of the things. > > Sincerely, > Julie S. Oh, sorry. I was concentrating too much on learning git. Just merge from trunk, choose the way you prefer, and then merge back to trunk. -- Heikki |
From: D. M. M. <mic...@ro...> - 2009-09-09 07:23:53
|
On Wednesday 09 September 2009, ja...@us... wrote: > Integration of local cursor and playback pointer controls. I've been meaning to check out all kinds of your latest commits, Jani, but just haven't gotten there yet. How are you coming along with this in general? I have little sense of what still needs to be moved across, but after Ilan and I get through rewriting the project packager from scratch (finish line in sight), I'm looking in that direction. It's all coming together! -- D. Michael McIntyre |
From: Jani F. <j.f...@gm...> - 2009-09-09 15:12:35
|
2009/9/9 D. Michael McIntyre <mic...@ro...> > On Wednesday 09 September 2009, ja...@us... wrote: > > > Integration of local cursor and playback pointer controls. > > I've been meaning to check out all kinds of your latest commits, Jani, but > just haven't gotten there yet. > Please check them out and tell me do they make any sense although they seem to work. > How are you coming along with this in general? I have little sense of what > still needs to be moved across, but after Ilan and I get through rewriting > the > project packager from scratch (finish line in sight), I'm looking in that > direction. > Last week I wasn't so busy at work because I has 3 days sick leave caused by a flu, so had some time for development. Probably my work will slow a bit now. IMO there is work to do with menus. Local cursor submenu is obsolete and there is duplicate entries with transport. Should this be worked in a branch? -Jani |
From: D. M. M. <mic...@ro...> - 2009-09-09 16:19:27
|
On Wednesday 09 September 2009, Jani Frilander wrote: > Please check them out and tell me do they make any sense although they seem > to work. I need to go back commit by commit and check closely to make sure what I'm testing, but just playing with the notation editor, I don't notice any problems. > Last week I wasn't so busy at work because I has 3 days sick leave caused > by a flu, Great, so I have you to thank for why I'm sitting home with the flu? Thanks Jani. Thanks a lot. Next time wash your hands before doing a commit, so you don't transmit germs with your code. > IMO there is work to do with menus. Local cursor submenu is obsolete and > there is duplicate entries with transport. Should this be worked in a > branch? There is all kinds of garbage on there for sure, and all of the old ruler right click menu actions too. I'm not sure which of those will still serve a purpose in the new rulers, but one way or the other they don't need to be where they are now. It's probably safe to do this in trunk/ but let's have a look and come up with a plan first. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-09-13 15:55:14
|
Oops, I had meant to pull this discussion over to the devel list. On Sunday 13 September 2009, Jani Frilander wrote: > Basically I think step recording isn't difficult to reimplement, but there > is a comment in OldNotationView I'm worried about: I wouldn't worry about that posing any problems that shouldn't already have been solved acceptably for years. That comment goes back to revision 7610, which, by the looks of how many lines changed in that one, must have been from the Reorganization. I wouldn't expect problems beyond whatever is involved in adapting the code to the way things are hooked up now. > What I'd like is to have step forward and back also in transport toolbar > and window. > Like buttons having 3 small triangles in row point left or right. I don't think I'd put them on the main transport window. Step foward/back don't have any real meaning on the segment canvas, and these really aren't global transport actions. For that matter, anything on any transport, even one of the local toolbar versions, I would expect to have a global effect on the main window and any open edit views. If step forward/back were on a transport toolbar, then it would be inconsistent if the cursor moved in one window but not the rest, but I think it would be very obnoxious if it actually worked the way its position on the transport toolbar would suggest it should. So while there is only one cursor to do all jobs now, some of the cursor actions are still quite local and specific to the individual edit view you're working with at the time. This seems to suggest to me what we need is some kind of local cursor actions toolbar that stands by itself, not folding these orphaned actions into something else. What do you (or anyone else) think about that one? Leave all these Cursor to x actions where they are, and make a toolbar out of them, as an easy way to discover all the shortcuts. I think I'll work on that today. We can ultimately use the icons no matter where these actions wind up, and I think the concept feels like the right way to go, and will probably work out. -- D. Michael McIntyre |
From: Jani F. <j.f...@gm...> - 2009-09-13 17:18:07
|
2009/9/13 D. Michael McIntyre <mic...@ro...> > > I wouldn't worry about that posing any problems that shouldn't already have > been solved acceptably for years. That comment goes back to revision 7610, > which, by the looks of how many lines changed in that one, must have been > from > the Reorganization. I wouldn't expect problems beyond whatever is involved > in > adapting the code to the way things are hooked up now. > I dared to commit a quick hack to make step recording working. Just implemented 3 related slots, but no global signals are yet to be ported. So you must activate step recording in that notation window. > > What do you (or anyone else) think about that one? Leave all these Cursor > to > x actions where they are, and make a toolbar out of them, as an easy way to > discover all the shortcuts. > > I think I'll work on that today. We can ultimately use the icons no matter > where these actions wind up, and I think the concept feels like the right > way > to go, and will probably work out. > > Sounds logical. You're the expert! -Jani |
From: D. M. M. <mic...@ro...> - 2009-09-13 17:43:22
|
> So while there is only one cursor to do all jobs now, some of the cursor > actions are still quite local and specific to the individual edit view > you're working with at the time. > > This seems to suggest to me what we need is some kind of local cursor > actions toolbar that stands by itself, not folding these orphaned actions > into something else. Well that was all interesting. I've really got some catching up to do getting my head around the new model, don't I? My initial response to Jani's suggestion really demonstrates how little I thought thought about the ramifications of Chris trying to implement the often requested "one cursor" model. Everything I was thinking about these being "local actions" has traditionally been true, but you're quite right Jani that these all might as well be included with the transport controls now, because there is only one cursor for everything everywhere, and whatever you're doing with it in one edit view, it does the same thing in every other edit view too. So how is that even supposed to work with things like cursor up/down staff and previous/next segment? These concepts have no meaning in the global context, so I guess we just have to abandon these actions completely, and find some other mechanism for accomplishing the intended result? (These four in particular were mostly or entirely designed to facilitate working with overlapping segments on the same notation staff, where the only big problem is controlling which bit of what you're editing at the moment, not with actually drawing or laying anything out.) Then what about the transport. Indeed, these should go on the transport now if that's what they are, but who wants to see a transport with another... Well how many? "cursor_back" "cursor_forward" "cursor_back_bar" "cursor_forward_bar" "extend_selection_backward" "extend_selection_forward" "preview_selection" "clear_loop" "cursor_up_staff" "cursor_down_staff" "cursor_prior_segment" "cursor_next_segment" That would be 14 new icons! We can cut the list down by removing: "cursor_start" "cursor_end" Those are totally redundant in this scheme, and functionally identical to "rewind to beginning" and "fast-forward to end" That in of itself begs another question. Five edit views, five segments that all end at a different boundary. Fast-forward to end, the cursor out on the main window is at bar 100, but in any edit view, it only goes to the last visible bar. So if I try to insert something, where will it go? Where the edit view in front of me shows its cursor sitting, or somewhere else? So three views, they end at 33, 27 and 15. I'm in the one that ends at 15 and I'm going to insert something with the keyboard. And pow, now all edit views are at bar 15. OK, that functions whether I find I like it or not, so yes, the "cursor_start" and "cursor_end" actions are completely redundant now. Moving on from that, we've already talked about how these have no clear meaning now: "cursor_up_staff" "cursor_down_staff" "cursor_prior_segment" "cursor_next_segment" If the cursor is strictly attached to the transport, then it only has one axis, so there is no "up staff" or "down staff" to it at all. "Next segment" and "previous segment" could have meaning, but they'd almost never have a meaning that made any sense across multiple contexts at the same time. So these turn out to be a very large question mark. Then these ones too: "extend_selection_backward" "extend_selection_forward" "preview_selection" "clear_loop" A selection really is only meaningful at the local level, but the nature of this beast now implies that these actions, like everything else, will have to work globally. So we select to the left in every edit view, and every edit view makes a selection at the same time? If we copy, what are we supposed to be copying anyway? And then there's the matter that selections on the main window are a completely different animal, and there is no way to select less than an entire segment. The "range" mechanism, using the ruler, is the hack around that. It's arguably not a good design, but I feel pretty strongly that changing something like that around is way out of scope for Thorn. Ugh. This is just a great heaping mess, really. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-09-13 18:06:42
|
On Sunday 13 September 2009, D. Michael McIntyre wrote: > "cursor_up_staff" > "cursor_down_staff" > "cursor_prior_segment" > "cursor_next_segment" > So these turn out to be a very large question mark. Indeed. If there are multiple staffs, is it even possible to edit more than one of them in the same notation view now? Yes, but I find it difficult to control which one of them I'm going to insert anything into. Especially with the keyboard. And the select forward/back stuff has my head buzzing. This well and truly only has meaning in one edit view at a time, but that behavior is not at all consistent with one cursor, and it's a transport cursor. Not only just one edit view at a time, one segment at a time. You can't select across segments, even though it would be really convenient to be able to do that in a multi-staff edit view (especially where several overlapping segments are on the same staff). Those aren't problems we're going to sort out for Thorn, if ever, to be honest about it. So what to do about these indeed, and their parallels in the matrix now that you can edit multiple segments in the same matrix view. The matrix never had this ability before, but the main thing preventing it from being useful now is there is utterly no way to control this "up staff/down staff" kind of functionality, and only one segment can be presented for editing. Well I guess we had better get cracking on working out the answers to these many questions. Can we really work out solutions to everything that don't involve a local cursor, or do we need to put the local cursor back? I'm catching up late. Does anyone else actually have a plan for how this was all supposed to have worked out? A way to work around all of these limitations? If not, I feel the February deadline slipping away rapidly while we stall out trying to figure out how to solve these problems. I have the beginnings of some thoughts about several of these, but if the things I'm thinking are in any way actually required to get the job done, we're looking at months to get it all done and get it all right. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-09-13 18:33:42
|
Hello RG Team, Just coming off the heels of the notation_toolbar_branch, I had much first hand experience dealing with how the GUI is set up -- but did not look at the implementation of it. I think the global cursor a good idea, but the details are lacking. A general thought: * On playback, the cursor in should move smoothly in notation view, like it does in classic. Specially with multiple staffs on a page, the playback appears choppy and inconsistent. Specific thought about user interaction: * Since Matrix editor now shows multiple segments in one view just as notation editor does, we should have similar methods to navigating among the segments (keystrokes, buttons, and mouse actions). Two alternatives for cursor support in notation view * Take the leave from matrix view and gray out the "non-active" staffs. Then as the cursor up and down is moved, the active staff is restored to black. This is probably not the best method. * Create a Hybrid cursor, a dark colored cursor that spans the length of the notation view. On that cursor is the "purple cursor" overlaid on top of the dark cursor. This cursor will span the height of the active staff. So moving from staff. I like this idea better, and the purple cursor still has a life in Thorn, but in a more intuitive form. Well, those are my thoughts. Let me know what you think. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-09-13 18:54:27
|
On Sunday 13 September 2009, Julie S wrote: > * On playback, the cursor in should move smoothly in notation view, like it > does in classic. Specially with multiple staffs on a page, the playback > appears choppy and inconsistent. Chris did that on purpose. We have to have the cursor stop at meaningful points in notation if it is to serve as the insertion cursor. (Because that's what the old insertion cursor did, for good reason.) I don't like the choppiness either, but I'm afraid his reasoning is sound. > * Since Matrix editor now shows multiple segments in one view just as > notation editor does, we should have similar methods to navigating among > the segments (keystrokes, buttons, and mouse actions). I agree 100% on this. There are currently a lot of actions that appear only in notation, and whatever we yield in the end should be the same for both. > Two alternatives for cursor support in notation view > * Take the leave from matrix view and gray out the "non-active" staffs. > Then as the cursor up and down is moved, the active staff is restored to > black. > > This is probably not the best method. You think not? It would be involved to do, and also "graying" wouldn't work, because that already has a semantic meaning of "invisible." We'd have to change "invisible" to something else. Factoring into this are future plans for having fixed rests as opposed to calculated rests. That's after Thorn, but I want to have fixed rests appear solid black like notes, and calculated rests appear less permanent, but not "invisible." There are only so many color choices that look decent in our scheme, so all of this gets complicated. Especially if we try to avoid using opacity as a color property, because it's supposed to be expensive or even unreliable in situations where hardware graphics acceleration is not available. > * Create a Hybrid cursor, a dark colored cursor that spans the length of > the notation view. On that cursor is the "purple cursor" overlaid on top > of the dark cursor. This cursor will span the height of the active staff. > So moving from staff. > > I like this idea better, and the purple cursor still has a life in Thorn, > but in a more intuitive form. > > Well, those are my thoughts. Well that's an interesting idea, and probably a lot less expensive to draw. With the idea you were talking about above, which is basically the same as I was getting at in the last brainstorm I threw out there, one thing to consider is that if you click on the staff at the bottom and it becomes active and accepts a note (all of this is pretty easy to control clicking with the mouse to say where you want to do something; harder with the keyboard) then you've got all those redraw operations while everything on the screen has to figure out its new color and change how it presents itself when the active destination for events changes. I'm not sure how this already works. It may well be the redraws are already happening, and introducing some color changes would be extremely trivial with practically no new overhead. Or maybe not at all. So anyway, taking away from all that, I said "all of this is pretty easy to control clicking with the mouse to say where you want to do something." There is one big exception to that, and that is the case of overlapping segments on the same staff. It's still really hard to control that effectively, even in Classic, to the point where I usually wind up... Say I've got to split the bass notes in, oh, "Hey There Delilah" into a separate voice, what I usually wind up doing is putting the segments on different tracks so they wind up on different staffs for more sane and controllable editing, and then I put them together on one staff afterwards to get them to come out right. Expanding height tracks make it possible for me to pick out the "ringing bass notes" segment separately from the "melodic notes" segment, but since they're on the same track, if I want to edit them on discrete staffs, I have to do it with two separate edit views. I'm not even sure exactly where I'm going with that in terms of proposing a solution, but while we're in here getting ready to rip things up anyway, this is worth solving once and for all. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-09-13 19:29:27
|
Dear Michael, You wrote: > Chris did that on purpose. We have to have the cursor > stop at meaningful > points in notation if it is to serve as the insertion > cursor. (Because that's > what the old insertion cursor did, for good reason.) > I don't like the > choppiness either, but I'm afraid his reasoning is sound. But there is no good reason to do this on playback. Specially with multiple staffs (segments). The currently we just follow the notes on the active staff. Say the current staff has whole notes on it and the staff below has 16th notes on it. The cursor is only updated every 4 beats in this case, but clearly should have advanced on the 16th notes. So, on playback, the cursor at least needs to respect everything in the windows and update. Now for editing, moving in time like it does is good. But doing both creates a 'corner case.' But that is easy to solve. The cursor should just move back to the last active note or rest in the active segment. But tracking everything in every segment for cursor playback might get expensive. So a smooth scrolling solution may be easier to manage, plus we already have code for that. So, my thought is to have both. Coarse (duration based movement for editing), and smooth cursor flow for playback. This idea can be extended to matrix view, of smooth scrolling on playback, but snapping to last note (or grid) when payback stops. You wrote: > So anyway, taking away from all that, I said "all of this > is pretty easy to > control clicking with the mouse to say where you want to do > something." There > is one big exception to that, and that is the case of > overlapping segments on > the same staff. It's still really hard to control > that effectively, even in > Classic, to the point where I usually wind up... Right, multiple segments on staffs on a segment can be an issue. First of all moving between staffs has issues if there are no notes or rests. But here is my thought: Since the cursor is already at a known place (duration-wise) in the notation view when the cursor moves up and down the staff at the "known" position, interprolating if necessary to calculate where that would be on a staff that doesn't have an explicit note or rest there. That way as the cursor moves from say the top staff to the bottom staff (maybe 3 or 4 staffs) away, the position in the work is not lost. This could be very useful in chord mode so you could put a chord in one staff, move down a couple and add the Bass note in at the same location. Now about multiple segments on a single staff.... All thought I have on this seems expensive, including graying out notes or coloring the active segment differently. Another expensive solution is to implement a virtual breakout of the segments onto separate staffs for editing. This could be used to our advantage. We could have separate segments and then direct notation view to combine them or split them as we need it to, whether it is for editing purposes or for actual display reasons. Sort of like having a first and second violin on a condensed single staff versus, having them on separate staffs. Maybe we could toggle between options easily so editing them would be straight forward. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-09-13 20:27:47
|
On Sunday 13 September 2009, Julie S wrote: The biggest problem I can see with smooth scrolling where the cursor position represents something very significant is that when you stop, it could wind up anywhere. Moving it to a logical "snap point" does indeed make sense as a solution to that. So how complicated is it to implement? One problem is there is one cursor sweeping through time across 42 different edit views, and we have a global transport. User hits stop on the global transport, we have 42 different edit views that all could have a quite different idea about a logical place to go park the cursor afterwards. So what already happens here? Two segments, one full of whole notes, one full of 16th notes. Four edit views, two notation, two matrix. Hit play, hit stop. The two notation cursors are drawn in completely different places. Where does the cursor update happen, and why? The advantage of the current scheme is that wherever it is when you hit stop is a logical place for it to be in that edit view. No "transport stopped" update action has to be triggered, if one even exists to trigger. It's just there. Your idea would require some thinking. I have no idea how much, and no idea how any of this code works off the top of my head. I'm just looking and thinking with no opinions implied. > First of all moving between staffs has issues if there are no notes or > rests. Very true. I just experienced that first-hand. It's almost impossible to control, currently, because these up/down are missing. > But here is my thought: > Since the cursor is already at a known place (duration-wise) in the > notation view when the cursor moves up and down the staff at the "known" > position, interprolating if necessary to calculate where that would be on a > staff that doesn't have an explicit note or rest there. That way as the > cursor moves from say the top staff to the bottom staff (maybe 3 or 4 > staffs) away, the position in the work is not lost. Interesting thing about that is the way each staff seems to have its own cursor resolution ideas. You're on the seventh 16th note up here and you move down here where the half note is, and the cursor wants to move left. > Now about multiple segments on a single staff.... > > All thought I have on this seems expensive, including graying out notes or > coloring the active segment differently. > > Another expensive solution is to implement a virtual breakout of the > segments onto separate staffs for editing. I wonder how firm the staff/track relationship is, and how much rework would be required to get segments that belong to the same track to display on different staffs. I love the idea of doing a quick and easy breakout and collapse, but I find the implementation looks like a dark and dangerous forest. If we had it, I could definitely live with that myself. Expand the "layers" to edit them (otherwise you can only edit the "base" layer) and collapse them back up. One huge problem with that idea is there *is* no "base" layer at all. What segment is on the "bottom" of all this? This is also a problem on the main window with expanding height tracks. Depending on what you do in the way of making segments overlap, they change which "lane" they are in to minimize the use of space. It isn't a fixed relationship. I don't remember any of the details now, but at the time Chris implemented expanding height tracks, we talked about this, and just couldn't come up with a sensible way to give an individual segment a fixed position in this scheme. Letting them "float" was much more practical. It still is in this scheme too, but if there's no way to establish the "base" layer for editing, then you could only edit overlapping segments when the staff was exploded out. That might be workable. Noteworthy Composer required you to edit everything on completely discrete staffs, and then use some dialog to merge this with that. Our scheme would at least be quicker and less involved to use. Just a wild thought, since they're all on the same track, the track header should grow tall enough to encompass all of them. The track header itself would be a logical place to put the expand/contract control. Well, off to work now. Fun day of tossing ideas around. I hope we can get a plan together and figure this out soon. Unfortunately, we have to add another mountain to tunnel through to our list. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-09-13 20:58:40
|
Dear Michael, Everything I wrote was all talk and no real thoughts about what is involved. To me the easiest thing to do, is just put back the purple cursor and leave it all alone for now, or do the combined cursor like I mentions. Leave the rest for later and pretend we didn't talk about all of this. I think at this point it is best to do the "least" amount of work in this area and get RG out the door asap. Everything sounds like a rewrite to me at this point, and we've got enough of that as it is. I'd like to just get this out the door and into the hands of the users. We have enough new good stuff going that we don't "have" to resolve this in a best way. We just need it to do what it did before. So that mean we need to have it navigate staffs in a reasonable fashion. That should be enough. But I understand the urge to strike while the iron is hot -- to use an idiom. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-09-14 04:02:54
|
On Sunday 13 September 2009, Julie S wrote: > Everything I wrote was all talk and no real thoughts about what is > involved. Same here for the most part. > To me the easiest thing to do, is just put back the purple cursor and leave > it all alone for now, or do the combined cursor like I mentions. At this point I don't think it really is that simple at all. The purple cursor is completely gone now. It kind of reminds me of the time I tried to go through this railroad tunnel when I was a kid. Standing on this side of it, the light at the far end looked pretty big and bright, but after I got in there a really long way, it seemed to grow smaller and smaller, to the point where it was like a little desk lamp always just out of arm's reach. I thought about going back, and realized that the light in the direction I had come from was the same size. Boy was that a long tunnel. That was in my younger and more innocent days before I knew anything about railroad police officers and strict no trespassing laws. I just had NO CLUE what I was getting myself into that day. Turned out that damn tunnel was over a mile long! That's where we are now on all this cursor business. Bringing the purple cursor back to life is where we came from, and sorting out the big remaining issues with the one cursor approach is the other side of the tunnel we're curious to see. If we go back now, it will be twice as much of a journey to get to that other side, but if we go there and it doesn't work out, it will be twice as much of a journey to get back to where we started. At least this tunnel hopefully doesn't have trains. In my real tunnel, the desk lamp went out, to be replaced with a pen light, and we ran like hell back to the near side, narrowly escaping with our lives. (That, boys and girls, is why walking through railroad tunnels is not only illegal, it's just stupid.) > I think at this point it is best to do the "least" amount of work in this > area and get RG out the door asap. I agree there 100%. All of this just isn't really something I counted on having to deal with one way or the other. Very much like how the far side of that tunnel looks so very much closer when you're standing outside in the light, looking through it. (It does. Come down one day and I'll show you. It's a pretty cool perspective effect now that I know the truth of it.) > Everything sounds like a rewrite to me at this point, and we've got enough > of that as it is. Too much and then some seven times over, and I would be more than happy if the unavoidable rewrite I just finished, and the one Cris Fryer is working right now could be the last ones to deal with. But as I say, we're already in the middle of the tunnel at this point, and it's definitely worth thinking more about the far side. It would be very appropriate for Chris to show up and offer his own thoughts about all of this too, before I wind up making a decision on my own and running with it. The main thing is to figure out where we're going to go, and SOON, then GET THERE, so I'm not about to let this turn into a month of hand wringing. If I have to call it alone, I'll call it. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-09-14 06:50:24
|
On Monday 14 September 2009, D. Michael McIntyre wrote: > month of hand wringing. If I have to call it alone, I'll call it. OK, I called it. We'll continue toward the light in the same direction we started off in, and go for broke. Step forward/back are going to the Transport (but not the global floating one) as Jani suggested. Cursor to beginning/end, and forward/back bar were already cross-wired to parallel transport actions. Redundant and deleted. The big question mark actions are going from "Local Cursor" to "Navigation" and have yet to actually be implemented in any way. They may or may not be on a toolbar, or something else, as I work in that direction. Resolve conflicting meanings of Shift+Up and Shift+Down. Sort all of this out in the notation editor, then the whole chunk should apply in the matrix as well. Resolve these staff up/down big purple cursor questions a bit later. Let's just see how far it can get toward being usable and sensible without any new work, and do the smallest amount of new work practical. (Save expand/collapse staffs for after Thorn, but let's not lose that idea. I really like it.) Work commencing in trunk/, ahead full stop, except of course that I'm way past when I should have already quit for today. -- D. Michael McIntyre |
From: Julie S <msj...@ya...> - 2009-09-14 14:33:37
|
Dear Michael, Navigation and cursor thoughts: ------------------------------- The purple cursor is gone so you say, but it doesn't have to reappear as old code had it, we can just use it "metaphorically" and overlay it or something like it on the dark cursor. It's sole purpose it to mark the active staff. Basically we are just changing the color of our current cursor and then extending it in both direction with a dark color do the non-active staffs. But that still leaves some navigation issues to consider. But since we are now tied to a note or rest and all the cursors are unified, it is difficult to decide what to do. Without taking time to study how the current behavior is implemented, it is difficult to know how to proceed. I'm imagining the current cursor location is determined from the list of events in the segment, therefore only moving to starts of events in the segment. Maybe another way to approach this is to take from matrix view (which has a grid setting). Matrix as Cherrett mentioned should be updated that movement in time should follow the grid setting and not the beat setting, If this were so, we could implement a "grid" setting in notation view that would advance the ruler on the grid values when the keys are pressed to advance the notes. But maintain our current "advance to end of the duration" feature when inserting notes / rests. So this would be yet another feature with setting (that I know Michael hates): These option would include all the durations RG supports (using the duration toolbar as a guide) and an option to just honor the notation toolbar setting, and a final setting to honor events in the segment (which I think is the current implementation). This way you can have the current behavior; a sane way to navigate staffs and "interprolate postion" if there is no event on the new staff, and multiple ways to navigate the length of the staffs. Overlapping segments and other related thoughts: ------------------------------------------------ I know we don't have time to figure this out now, but I wanted to provide some more fuel to the idea--while I'm thinking about it. Maybe a new approach is in order, but maybe just some new thinking. We currently have overlapping segments that provide a variety of features for us, but leave us no way to suborder them in any meaningful fashion. We have tracks that are distinctly ordered and tied to outputs. We also have the ability to have multiple tracks point to the single output. Idea 1: ------- So, what if we implemented some kind of track binding or sub-ordering. This would all take place int the RG Main window. There are lots of variations on a theme here. A simple way would be just to allow the user to tell RG that track 1 is and track 2 are grouped. RG will understand this that track 1 is the highest priority track, and that track two is below it in priority, and that everything in track one is to appear on the same staff as track one. Therefore all clefs and keys are taken from the lowest (or highest priority track). But that leaves lots of cases to consider concerning accidentals and stuff like that. Hmm... But at least in this way, if all three segments are selected for editing then the "highest number track" gets the note or rest inserted into it. The idea being is that is probably the track that is currently being worked on and needs user input, the other tracks are already set. If the user wants to work on an existing track (lower numbered track), they just go to the RG main window and insert a new track below the others (a higher number track), group it, and move the segment they want to work with there. Then they open up notation view, and any new notes or rests or edits affect the that track. So the order is set in the RG main windows based on track numbers. So what would overlapping segments be good for. I don't know. But maybe if we took this further, we could "roll up" these subtracts and show them as overlapping segments on the canvas and use the track subordering as a guide as to where they get placed. Idea 2: ------- Well, with all of that said, we could just do it like lots of graphics programs we could set a subordering with the overlapping segments and do a bring to top, or set to bottom. Idea 3: ------- Another idea with tracks and overlapping segments is to allow a track height to increase explicitly, instead automatically when segments overlap. Lets call each of these a "lane". By default a track will have one "lane" for segments and this will be the default minimum for every track. Now, allow the user set a minimum number of lanes for each track. This will keep the track expanded at least this minimum at all times for the track. In this way the segment in the "bottom" lane is the one the received the note / rest insert events by default when multiples are selected for editing. If overlaps occur, due to segment creation on move, etc, then the new one bumps the other to the the nearest "free" lane or RG expands the lanes above the minimum to accommodate the bumped segment. But the Minimum number of lanes will be restored when any of the lanes become free of segments. This method would allow users a visual way to organize their overlapping segments and always know how RG will interpret them. Idea 4: ------- This could be used with any of the other ideas above or as a stand alone method. As far as switching in notation view, we could just all users to switch via a list of segment labels -- hoping the user chose to make good labels for the segments, or they could just toggle through them in some fashion. Maybe the currently edited segment label could be displayed in the status bar or listed in some other prominent location. Or if this was in a combo box, the user could select the segment they want to work with from the list, and the list could also serve as a reminder as to which segment was the receiver any new user input. So we wouldn't have to highlight anything. It would be the user's job to know what they were looking at on the page. ... Well, those are my brainstorming ideas. Sincerely, Julie S. |
From: D. M. M. <mic...@ro...> - 2009-09-14 16:31:07
|
On Monday 14 September 2009, Julie S wrote: > The purple cursor is gone so you say, but it doesn't have to reappear as > old code had it, we can just use it "metaphorically" and overlay it or > something like it on the dark cursor. It's sole purpose it to mark the > active staff. Well, taking the "get this done today" approach, the cursor already marks the active staff in the scheme we have today. The cursor jerks along to whatever the staff it's following contains, but we don't have cursors on different staffs in the same notation view moving at different speeds, or anything crazy like that. The biggest beef is if you have two staffs one above the other, and you're parked on the whole note staff, it will follow the whole notes, and appear not to be moving for big stretches of time, even though the staff right below has a bunch of 8th notes. This is even worse if the two segments overlap, and you're following the whole notes even though there are also a bunch of 8th notes on this same staff. What you were saying about the cursor this and the cursor that are ideas that I'd love to talk about if someone else was about to sit down and code it all, but I have the impression I'm pretty well on my own on this one. I'm inclined to do the least work possible from here, and that means trying to live with the snapping cursor if at all possible. (And if not, a sweep cursor that continues to be bound to the single active staff and the active segment on it, and snaps back to a logical place when playback stops.) I think the obnoxiousness of its behavior would be greatly mitigated by a convenient and accessible way to roll through which bit of what is active and being tracked. I think the mechanism I have in mind to try for that would probably be nice regardless of whether the cursor snaps or not, so I have in mind to try this approach first, and ignore how much I dislike the snapping cursor. (For one thing, I really despised it initially, but I've largely gotten used to it.) I don't know exactly where I'll put it and so on, but my plan of attack is: 1) Get the four navigation options to move up/down staff and next/prev segment to work via keyboard shortcuts that call functioning code 2) Stack two vertical thumb wheels on top of each other, one to roll through the active staff, and one to roll through which segment on which staff is "on top" (probably on a floatable vertical navigation toolbar) I think with the thumb wheels (from Sonic Visualiser. They're quite nice widgets) making it possible to roll through the permutations very quickly and accessibly, it would probably not be too confusing having the cursor behave as it currently does. If it's still a great bother, we would have wanted the thumb wheels anyway, so nothing is wasted. I really do want some nice way to navigate through all of this stuff, which in Classic always depended on keyboard shortcuts I could never remember properly. A horizontal toolbar would fit in better with the overall layout, but I feel vertical controls would be much more intuitive to use. Maybe I could just manage to stick them under the groups toolbar. > Overlapping segments and other related thoughts: I'm just glossing over this for now, having digested your brainstorms. We may have time to return to this question before Thorn, but probably won't. -- D. Michael McIntyre |
From: Chris C. <ca...@al...> - 2009-09-14 16:34:41
|
[sorry about the absence -- medical distractions] So, in the Classic notation editor we have two cursors. The blue one is the full height of the system and moves smoothly during playback (mostly!). The purple one is the height of a single staff and moves only when commanded to. It has two main functions: to be the editing point for operations like paste and keyboard inserts (for this purpose it always "snaps to event edges"); and to show which staff is current (not segment, it's inadequate for that). To make the single cursor behave as well as the two in Classic, presumably we need to handle both of these cases -- it needs to indicate the current staff (much as I'd like to do this with some fancy overlay, the cheapest way has got to be to use the cursor as Julie says), and it needs to "snap to edges". If the single cursor has the full height of the system, then it really does want to move smoothly during playback; snapping looks very strange in that situation (as noted already). I had intended to experiment with making it snap to the closest edge when playback stops, but I haven't done that yet. A full-height cursor could easily have a single-staff-height section in a different colour or style that made it (relatively) clear which was the current staff. If the single cursor has the height of only a single staff, as now, then smooth movement is less vital, though I agree that the current behaviour is still kind of irritating. Chris |
From: Shelagh M. <she...@gm...> - 2009-09-13 22:19:26
|
On Sun, 13 Sep 2009 16:26:45 -0400 "D. Michael McIntyre" <mic...@ro...> wrote: > On Sunday 13 September 2009, Julie S wrote: > > The biggest problem I can see with smooth scrolling where the cursor > position represents something very significant is that when you stop, > it could wind up anywhere. Moving it to a logical "snap point" does > indeed make sense as a solution to that. > > So how complicated is it to implement? > > One problem is there is one cursor sweeping through time across 42 > different edit views, and we have a global transport. User hits stop > on the global transport, we have 42 different edit views that all > could have a quite different idea about a logical place to go park > the cursor afterwards. > > So what already happens here? > > Two segments, one full of whole notes, one full of 16th notes. Four > edit views, two notation, two matrix. > > Hit play, hit stop. The two notation cursors are drawn in completely > different places. > > Where does the cursor update happen, and why? > > The advantage of the current scheme is that wherever it is when you > hit stop is a logical place for it to be in that edit view. No > "transport stopped" update action has to be triggered, if one even > exists to trigger. It's just there. > > Your idea would require some thinking. I have no idea how much, and > no idea how any of this code works off the top of my head. I'm just > looking and thinking with no opinions implied. > > > First of all moving between staffs has issues if there are no notes > > or rests. > > Very true. I just experienced that first-hand. It's almost > impossible to control, currently, because these up/down are missing. > > > But here is my thought: > > Since the cursor is already at a known place (duration-wise) in the > > notation view when the cursor moves up and down the staff at the > > "known" position, interprolating if necessary to calculate where > > that would be on a staff that doesn't have an explicit note or rest > > there. That way as the cursor moves from say the top staff to the > > bottom staff (maybe 3 or 4 staffs) away, the position in the work > > is not lost. > > Interesting thing about that is the way each staff seems to have its > own cursor resolution ideas. You're on the seventh 16th note up here > and you move down here where the half note is, and the cursor wants > to move left. > > > Now about multiple segments on a single staff.... > > > > All thought I have on this seems expensive, including graying out > > notes or coloring the active segment differently. > > > > Another expensive solution is to implement a virtual breakout of the > > segments onto separate staffs for editing. > > I wonder how firm the staff/track relationship is, and how much > rework would be required to get segments that belong to the same > track to display on different staffs. I love the idea of doing a > quick and easy breakout and collapse, but I find the implementation > looks like a dark and dangerous forest. > > If we had it, I could definitely live with that myself. Expand the > "layers" to edit them (otherwise you can only edit the "base" layer) > and collapse them back up. > > One huge problem with that idea is there *is* no "base" layer at > all. What segment is on the "bottom" of all this? This is also a > problem on the main window with expanding height tracks. Depending > on what you do in the way of making segments overlap, they change > which "lane" they are in to minimize the use of space. It isn't a > fixed relationship. > > I don't remember any of the details now, but at the time Chris > implemented expanding height tracks, we talked about this, and just > couldn't come up with a sensible way to give an individual segment a > fixed position in this scheme. Letting them "float" was much more > practical. > > It still is in this scheme too, but if there's no way to establish > the "base" layer for editing, then you could only edit overlapping > segments when the staff was exploded out. > > That might be workable. Noteworthy Composer required you to edit > everything on completely discrete staffs, and then use some dialog to > merge this with that. Our scheme would at least be quicker and less > involved to use. > > Just a wild thought, since they're all on the same track, the track > header should grow tall enough to encompass all of them. The track > header itself would be a logical place to put the expand/contract > control. Maybe you could borrow a paradigm from graphic drawing programs where there are layers, one *is* the base layer, the first created and others that you create are layers that you can edit separately and flatten (or merge) when you get ready to export. You move between layers to edit them. Might not be relevant at all, but that was the picture I got in my mind when reading this post. SOM > > Well, off to work now. Fun day of tossing ideas around. I hope we > can get a plan together and figure this out soon. Unfortunately, we > have to add another mountain to tunnel through to our list. -- ---------------------------------------------------------------- Jabber: she...@gm... Skype: shelagh2648 ---------------------------------------------------------------- |
From: D. M. M. <mic...@ro...> - 2009-09-14 03:35:53
|
On Sunday 13 September 2009, Shelagh Manton wrote: > Maybe you could borrow a paradigm from graphic drawing programs where > there are layers, one *is* the base layer The problem with doing that kind of scheme with Rosegarden is that it is something like a GIMP where all the images are open on the same big canvas, and you have multiple discrete chunks of "base layer" that you can move around all on that same canvas. As long as these discrete chunks only butt up against each other, but never overlap, there is no problem. The trouble comes when you overlap one chunk of base layer with another. A new layer is created spontaneously, and one segment or the other is promoted to that new layer. Both of these were "base layer" segments to begin with, so which one of them is promoted, and which one is retained on the base layer? Now what happens when you drag both of these over some third segment? I think the only way to solve those issues would be to give segments themselves the ability to possess layers, and stop allowing segments to overlap at all. The idea of segments possessing layers unto themselves has always been appealing to me, but we have a whole lot of existing infrastructure designed around a different concept, and it's much easier to continue working within that framework than it is to introduce such big changes and then sort out all the consequences. For one thing, when loading an old data file, which is something Rosegarden has always done exceedingly well, wherever segments overlap, they would have to be split off onto as many tracks as it took to contain them all without overlaps, and users would be left to convert them to layered segments manually, if desired. Importing something into this scheme would represent a pretty fundamental and permanent change to the original structure, and this fact in of itself would present sharing problems for users on either side of the file format version transition point. True, we've introduced changes before that would be lost when loading and saving the file with an old version of Rosegarden, but nothing that would alter the data this fundamentally. It's something to think about, although that in of itself is not the reason not to do layered segments at this time. It's just a question that such a large scale rewrite is out of scope for Thorn, and we've got to come up with some other solution in the interim, whether we should ever implement segment layers or not. As far as interim solutions go, Julie's "expand onto separate staffs" vs. "compress onto one staff" idea could not only be workable in the interim, but in the long term too, and could obviate the need for segments to possess layers at all. Sometimes it is difficult to decide whether it is best to keep working on the old clunky wiring or blow the buliding up and start from scratch with a better design. All of our decisions in this area so far have involved electrical tape and wire nuts. For instance, the reason we're using overlapping segments for notation layers at all is because one day someone overlapped some segments full of notes, and observed that the notation view could already make sense of the situation for free. Now we've got the same sort of thing going on in the matrix too, with the as yet incomplete but very plausible ability to overlap multiple segments on the same notation canvas. It seems far more likely as a practical matter that we will continue working with the overlapping segment paradigm, and layered segments will never happen, no matter how much I've always been fascinated with the concept. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2009-09-13 18:35:24
|
On Sunday 13 September 2009, D. Michael McIntyre wrote: > If not, I feel the February deadline slipping away rapidly while we stall > out trying to figure out how to solve these problems. I have the > beginnings of some thoughts about several of these, but if the things I'm > thinking are in any way actually required to get the job done, we're > looking at months to get it all done and get it all right. And carrying that thought along (even though by now I have so much out there nobody will read any of it, and I'm talking to myself) what about this up/down business indeed. If we did have a local cursor in the matrix, the "up/down" relationship would have no meaning in that context, because every matrix "staff" is hugely tall, and they all overlap identically. The matrix is, therefore, exactly the same kind of problem to resolve as the case of several overlapping segments displayed on the same notation staff. Up/down staff doesn't have any meaning at this level, because they're all on the same plane. What we need is "up/down" layer instead. Notation is a different and more complex problem, because there can be any number of staffs built up of any number of layers. So it seems like in the matrix we need some kind of way to say "this is the active layer" and some mechanism for controlling it. Perhaps one of those thumb wheel widgets from Sonic Visualiser we haven't used for anything yet. Roll up, roll down, change the "this is the active layer" and flip through what set of events is shown in real color, and available for editing. Notation is more evil, because we'd have to have one of these per staff, and one of these controlling which staff was active too. Or maybe not, maybe one widget to rule them all could just cycle through everything that's available from top to bottom, changing staffs when necessary. A [staff 1: guitar incidental voice overlap conflict resolution] B [staff 1: guitar picked short melody notes] C [staff 1: guitar picked long bass notes] D [staff 2: trumpet I] E [staff 2: trumpet II] Start on D, roll up to C, change the active staff in so doing. Roll up to B, stay on same staff, change which voice layer is active. I think we could make it easier in notation to see what's active by drawing inactive notes differently, as we do in the matrix now. Not the "invisible" gray color, but something else. (This all falls into some "after Thorn" ideas I have about fixed rests vs. calculated rests and so on that was I planning to defer until later, but maybe the color reform changes need to happen now after all.) This would make it crystal clear which "landing zone" is available for entry, except in the case of layers occupying the same staff, which gets rather more nebulous. All of this could work. Would it be usable? More importantly, can we avoid having to dive into something like this as a condition of release, or is it really inescapable as part of this "one cursor" plan? The more I chew on it, the more I fear I had better get started looking at the code to make it all work, but I'd love to be talked out of this. I'd just love it. -- D. Michael McIntyre |
From: Christopher C. <st...@tr...> - 2009-09-13 18:31:09
|
-------- Original Message -------- Subject: [Rosegarden-devel] Cursor Chaos From: D. Michael McIntyre <mic...@ro...> To: ros...@li... Date: 09/13/09 11:42 >> So while there is only one cursor to do all jobs now, some of the cursor >> actions are still quite local and specific to the individual edit view >> you're working with at the time. >> >> This seems to suggest to me what we need is some kind of local cursor >> actions toolbar that stands by itself, not folding these orphaned actions >> into something else. >> > > Well that was all interesting. I've really got some catching up to do getting > my head around the new model, don't I? My initial response to Jani's > suggestion really demonstrates how little I thought thought about the > ramifications of Chris trying to implement the often requested "one cursor" > model. > > Everything I was thinking about these being "local actions" has traditionally > been true, but you're quite right Jani that these all might as well be > included with the transport controls now, because there is only one cursor for > everything everywhere, and whatever you're doing with it in one edit view, it > does the same thing in every other edit view too. > > So how is that even supposed to work with things like cursor up/down staff and > previous/next segment? These concepts have no meaning in the global context, > so I guess we just have to abandon these actions completely, and find some > other mechanism for accomplishing the intended result? (These four in > particular were mostly or entirely designed to facilitate working with > overlapping segments on the same notation staff, where the only big problem is > controlling which bit of what you're editing at the moment, not with actually > drawing or laying anything out.) > > Then what about the transport. Indeed, these should go on the transport now > if that's what they are, but who wants to see a transport with another... > Well how many? > > "cursor_back" > "cursor_forward" > "cursor_back_bar" > "cursor_forward_bar" > > "extend_selection_backward" > "extend_selection_forward" > "preview_selection" > "clear_loop" > "cursor_up_staff" > "cursor_down_staff" > "cursor_prior_segment" > "cursor_next_segment" > > That would be 14 new icons! We can cut the list down by removing: > "cursor_start" > "cursor_end" > > Those are totally redundant in this scheme, and functionally identical to > "rewind to beginning" and "fast-forward to end" > > That in of itself begs another question. Five edit views, five segments that > all end at a different boundary. Fast-forward to end, the cursor out on the > main window is at bar 100, but in any edit view, it only goes to the last > visible bar. > > So if I try to insert something, where will it go? Where the edit view in > front of me shows its cursor sitting, or somewhere else? > > So three views, they end at 33, 27 and 15. I'm in the one that ends at 15 and > I'm going to insert something with the keyboard. And pow, now all edit views > are at bar 15. > > OK, that functions whether I find I like it or not, so yes, the "cursor_start" > and "cursor_end" actions are completely redundant now. > > Moving on from that, we've already talked about how these have no clear > meaning now: > > "cursor_up_staff" > "cursor_down_staff" > "cursor_prior_segment" > "cursor_next_segment" > > If the cursor is strictly attached to the transport, then it only has one > axis, so there is no "up staff" or "down staff" to it at all. "Next segment" > and "previous segment" could have meaning, but they'd almost never have a > meaning that made any sense across multiple contexts at the same time. > > So these turn out to be a very large question mark. > > Then these ones too: > > "extend_selection_backward" > "extend_selection_forward" > "preview_selection" > "clear_loop" > > A selection really is only meaningful at the local level, but the nature of > this beast now implies that these actions, like everything else, will have to > work globally. So we select to the left in every edit view, and every edit > view makes a selection at the same time? If we copy, what are we supposed to > be copying anyway? And then there's the matter that selections on the main > window are a completely different animal, and there is no way to select less > than an entire segment. The "range" mechanism, using the ruler, is the hack > around that. It's arguably not a good design, but I feel pretty strongly that > changing something like that around is way out of scope for Thorn. > > Ugh. This is just a great heaping mess, really. > > Just to throw another wrench into this. You should consider making the default action for arrows left and right to move the cursor left and right by gird designation in the matrix editor. That way you can move by 1/64 if selected and have precise control over editing. My 2 cents. |
From: D. M. M. <mic...@ro...> - 2009-09-13 19:09:30
|
On Sunday 13 September 2009, Christopher Cherrett wrote: > Just to throw another wrench into this. You should consider making the > default action for arrows left and right to move the cursor left and > right by gird designation in the matrix editor. That way you can move by > 1/64 if selected and have precise control over editing. > > My 2 cents. What do they do now? Nothing. Not hooked up yet, it seems. I agree, FWIW. Something like this is just going to have to change behavior based on what was active to receive the input, global cursor or no. In the matrix, going by grid designation is clearly the right thing to do. How that scales onto a parallel notation view or the main window is an ugly question though. -- D. Michael McIntyre |