On Sunday 10 June 2007, Arnout Engelen wrote:   

> Indeed for now I planned to just leave it up to the user to fix clefs
> and move octaves up/down as needed.

> >I wonder if this could incorporate the instrument preset database somehow.

> That sounds really good, I haven't looked into that at all yet. Maybe it
> could even add converting to the most suitable clef as an extra bonus.

It's in there, but getting it from here to there isn't such an easy thing.  
The database is read into widgets in a dialog, and the widgets are used to 
set track parameters, which are, in turn, used to set segment parameters when 
a new segment is created on the track.  The inside of a notation view is 
pretty far removed from those widgets in that dialog, so it doesn't really 
have access to the entire database at once.

It would take some thinking to work out a way to use the information for this 
new purpose.  The code does a really clean and efficient job of doing what it 
was originally conceived to do, but it seems a bit awkward to adapt it to 
this new purpose.

That might be enough of a hook to lure me back into coding though, so let's 
keep talking about this.  (I have to write SOME new code to justify releasing 
a new version with my new splash picture.  It's tradition.  :)  I think last 
year's contribution was hijacking Pedro's new track parameter box, and 
bending it to this new purpose, spurred on by Magnus stepping up to do up the 
instrument database, which is far more spectacular than my wildest 
imagination at time of conception.)

(And hey, there's another project we really should do.  We have percussion key 
maps now.  We have possibly hundreds of unused percussion instruments in 
Magnus's database that are just waiting on a percussion clef.  We have 
numerous feature requests to implement percussion notation.  All the building 
blocks are there, and it just needs someone to create a little spark, and get 
the fire going.  Percussion notation would put us that much closer to being a 
legitimate notation editor.)

> Rosegarden mainly for notation myself, most of the time I live in the
> NotationView, so for me it made sense to have it right there.

I can see that too.  In fact, in the land of wishful daydreams I will never 
get motivated to even think about implementing myself, I'd like to see a lot 
more capability to manipulate things at the track level from inside the 
notation view, even to the point of having an alternative UI that's 
notation-driven, and puts the MIDI sequencer aspects of Rosegarden out of 
sight.

Basically, if you take all of the things I would like to see far enough, it 
winds up being a fork of Rosegarden, using much of Rosegarden's guts, but 
doing away with the MIDI-driven paradigm, and focusing on notation the way 
real notation editors do.  I just can't see getting enough gumption to do the 
fork, and every time I think about that, I wind up coming to some new 
compromise.  It's really possible to do quite a lot with Rosegarden the way 
it is, although its fundamental nature makes many things ridiculously 
challenging to conceive of, let alone actually implement.  I think we have a 
vague idea how to do a couple dozen things that haven't ever actually been 
done, due to the convoluted spaghetti bowl nature of getting a thing done 
within this MIDI-driven framework.

> That said, my area of expertise certainly isn't UI design, as might
> sometimes be painfully evident :).

Join the club.  I think Chris and I would both agree that we really don't like 
a number of things about our interface, but we aren't quite sure what to do 
to make them right.  Most particularly the menus.  I revamped the menus a few 
years ago, but I still feel uneasy about the whole thing.  The closest we've 
had to a makeover suggestion, though, was from someone wanting to pare away 
something like 75% of our infrequently-used features.  That doesn't work, 
because every obscure, little-used menu item is somebody's pet project.

Rosegarden has grown quite organically.  For example, we have an event filter 
in the event list view, and a selection event filter that works in all views.  
Why two event filters?  Mostly because I wanted an event filter like Cakewalk 
had, and when I embarked on that quest, I didn't even realize the event view 
already *had* a filter.  I had no idea.  (In the early days, the event view 
was mostly broken, so I didn't use it often.)  We have a lot of overlap like 
this, where it might be possible to reduce several different features into 
one new one that does all the same jobs, but I don't think we're remotely 
well enough organized to ever get any kind of housecleaning like that done.  
Every time somebody makes a suggestion to this effect, we wind up arguing 
endlessly until everyone is bored, and decides to leave it all alone.

(For all that, now that I've played with Sibelius and Finale first hand, I 
think it may well be true that all notation editors suffer from similar 
interface problems.  Their interfaces are a little cleaner than ours, but not 
as much as you'd think for $600 or whatever.)

> Ah, right, indeed I didn't look at it like that ;).

It's hard for us to see this from the other side.  I know plenty of people 
like you, who see things as intervals plain as day, and I know how 
frustrating it is for you to deal with someone like me, who only barely 
understands any of this stuff, and mostly makes decisions by ear.

> So how did you know you had to set the segment transpose from -2 to -9?
> Personally, my 'base knowledge' for this problem would be that a trumpet
> is a Bb instrument and an alto horn an Eb instrument.

I already knew trumpet was -2.  I learned Eb horn was -9 from Magnus's 
instrument database, to be honeset.  Punch up "Alto horn in Eb" and hit OK, 
and it injects a -9 into the track parameter transpose widget.  Now I know 
it's -9, although I'd have to sit here a good half an hour explaining why 
it's -9 using music terminology.

(My ignorance makes it hard for me to work here, but it also helps to improve 
the chances of Rosegarden being useful to people who take a less formal 
approach to music.)
-- 
D. Michael McIntyre 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

Reply via email to