I sat down to tweak up exercise-notation.rg, to fix the problems we discussed 
in a bug report.  The experience really got me thinking about how multiple 
voice stuff could be better, in a practical way.

Take, for example, the weird hack with the 8th notes in two separate groups.  
It should be rewritten as two voices with 8th rests in between.

So step 1, create a new overlapping segment.  This is kind of annoying to do.  
I wound up creating a scratch track*, copying the original segment, then 
dragging it back.  Some kind of "add new voice" feature that created the 
segment for me would be splendid.

Step 2,  delete bits from both segments so they contain different information.  
I'm looking at two identical overlapping segments, and it's impossible to 
tell what belongs to what when I start deleting things.  What am I doing?  
The "up/down one voice" or whatever keyboard shortcuts are potentially 
useful, but without any indication which segment is what, it's really not 
practical to keep good track, and I'd be better off working with the segments 
on different staffs.

Toward that problem, it occurs to me to put some kind of fast toolbar toggle 
in the GUI to switch between "black mode" and "voice mode" or whatever better 
nomenclature we might come up with.  In "voice mode," the notes from each 
segment would get drawn in a different color.  Perhaps the simplest way to 
handle what color would be to use the segment color.  If I want three voices 
in three colors, then I can pick the colors for the three segments.  Sort of.  
If they're overlapping, how can I change them independently?  Problem.  So 
perhaps that's not the simplest way after all.

Anyway, some kind of color coding definitely seems necessary.  I can see one 
model where the current segment is in the "active" color, and everything else 
is in the "passive" color, but I think it would make about as much sense as 
anything just to draw everything from this segment in green, everything from 
this segment in brown, everything from this segment in purple, etc., and have 
some kind of GUI indicator showing what color you're actively working on.  
You're editing the purple notes, and you "up one voice" and now it shows 
you're editing the brown notes, etc.  Something like that seems rather 
reasonable, and not horribly difficult to implement.  Perhaps it also solves 
the problem of not being able to give a segment an ID, to say which one is 
voice I, voice II, etc.  Don't go by hard voice numbers, but by colors.

Finally, a huge missing piece of this is we need smarter rests.  I don't see 
any way to avoid jumbling up the rests when working on overlapping segments 
in the same staff like this.  I never got far enough to actually begin to 
implement the aforementioned changes to the file in question, but if I had, 
there would have been a rest problem for sure.  This sounds like layout GUI 
hacking hell to me, and I don't think I'm clever enough to even daydream 
about fixing this one.

After sitting here and thinking all of this out, it almost seems like the most 
sensible thing is to continue to require people to edit multiple voices on 
multiple tracks, and keep everything separate until time to combine it.  
That's quite a departure from something like Sibelius or Finale, or even 
NoteEdit, but Noteworthy Composer worked that way, so it's not completely 
unprecedented.  I would have been able to accomplish my own little task there 
if I had resorted to that, instead of torturing myself with my struggle to 
try to accomplish it in one combined view of both overlapping segments.

* My working copy of exercise-notation.rg has the extra tracks removed from 
the bottom, so that's why I had to create a scratch track.
-- 
D. Michael McIntyre 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to