[Rosegarden-devel] Re: [Rosegarden-user] Setting Instrument Names?

[Chris C. <ca...@al...>]

[transferring to rosegarden-devel]

On Friday 10 January 2003 04:51, Silvan wrote:
> [the Event View]
> isn't currently very useful.  You can't insert new events, and you
> can't change existing events into a different type.  All you can do
> is change the parameters for events you inserted some other way.

Gosh, this gives me an opportunity to bring together three different=20
threads in a single email.

The Event View is pretty basic at the moment.  You might expect it to=20
have been one of the first things we wrote, but actually it took us a=20
very long time to get around to it at all, and it can't do very much.=20
It ought to be a place where you can do interesting literal edits to=20
groups of related events, but you can't even do a multi-event copy or=20
cut from it yet (a feature I'd rather like).

But even despite its limited power you still have to be careful with=20
it, because it's actually possible to crash the whole outfit by=20
making certain sorts of edits.  For example, try deleting the pitch=20
property from a note while a notation editor is currently viewing it=20
-- blammo.  This is because somewhere in the notation code I'm=20
carelessly requesting the pitch property without testing whether it=20
exists, and then failing to catch the ensuing exception.  (So that's=20
two threads already-- this one and the exceptions thread.)

That's partly unforgivable laziness, and partly something I'd rather=20
fix another way: I'd like to change the NotationDisplayPitch class in=20
base/NotationTypes.h into a generic Pitch class (much like the=20
TimeSignature and the rest of them) that can be constructed from an=20
event, that stores the plain MIDI pitch and accidental only (see the=20
third thread coming in here?), and that can be queried for various=20
ways of displaying or describing that pitch depending on clef and key=20
etc.  That's going to take quite a bit of testing, if I ever get=20
around to it, and it'll probably take advantage of the hard work=20
already done by you and Hans and co in working out the correct=20
calculation of accidentals for things like Lilypond output.

> This needs to be fixed one day.  What you'll do eventually is
> insert a program change in the middle of a composition with the
> Event Editor.

I'm not sure about that.  I think that (as you hinted elsewhere)=20
requiring one program per track is actually a good discipline. =20
Currently we don't even do what you'd expect with program changes if=20
they occur in the middle of a track in an imported MIDI file (we read=20
the events but we throw away all but the last one, arbitrarily, from=20
which we set up the Instrument -- I guess we should do something a=20
bit more friendly, but that should probably consist of splitting into=20
several tracks in the same manner as we do when we encounter notes on=20
more than one MIDI channel in the same track).

In other words, as Rich seems to be suggesting in more colourful=20
terms, I don't think this would make a particularly good feature=20
request unless you strongly disapprove of this policy.

(Disclaimer: of course it's also not impossible that I'm=20
misunderstanding the situation myself.)

> You'll be able to insert other controllers this way too.

That's more likely.  Although ultimately the Event View is of course=20
unlikely to be the nicest way to do that.


Chris