Michael's Post-It Notes

This is a place for me to jot down things I want to remember, in a place where I can remember where I put them.

I don't have any specific thoughts about how to tackle this, but we really need some way to print parts vs. printing the entire score. Tempo indications and other such directives are per segment, but many should be present in individual parts if they're printed separately. We can make nice looking scores complete with brackets now, but there isn't any simple, convenient way to produce a set of parts from there.

This along with thoughts about barlines and more reasonable handling of repeats all feels like a major construction project for Abraham Darby.

Pedro just asked me why we don't have variable speed control yet. It's an idea that's been floating around in my head somewhere that I could probably pull off at this stage of my development into a developer, and I had sort of half nibbled on the idea. Let's go from a nibble to a bite and put this on the agenda for Abraham Darby.

The matrix is really begging for some notification widgetry somewhere, perhaps the status bar, to indicate which segment is currently active. Similar in concept to the track/staff headers in notation, but it doesn't really need to be that fancy. The matrix status bar really needs a current hover note indicator too, but I don't think I'm going to get that done anytime soon.

The newly reworked NotePixmapFactory doesn't lack a whole lot to be capable of drawing notation with different sizes relative to a primary size. It takes some sizing cues from the primary size, and some cues from the “grace” size, and in this fashion ledger lines can be scaled horizontally while maintaining the same spacing as their full-sized neighbors. We have LilyPond Directives \tiny and \small and so forth that can be used to do notes at cue sized in an inconvenient half-assed way.

What we could do is rig something up so that we have grace notes that aren't really grace notes, maybe an alternative mode to the duration monobar to draw in cue size or something. Probably make these take a different size from grace notes, to avoid confusion. Maybe set the size up as an event property, has BASE PROPERTIES “CUE NOTE” or something for LilyPond export to switch on.

It's only the beginning of a skeleton of an idea, but I like where it's going. It would be nice to be able to do true cue sized parts through the front door and get rid of the stupid LilyPond hack version. Cue notes come up rather often when entering the kids' 40 year old beat up piece of crap scores from the band room in order to produce legible copies, and it would be quite nice to use this dual sized NotePixmapFactory gizmo for more purposes.

Something to think about for Abraham Darby as a pet project to do in between real jobs.

I never finished fixing that. I got sidetracked along the way. NotePixmapFactory. Follow the bread crumbs.

Did I already do one tutorial with Thorn? Maybe? I think so? Anyway, the next one I want to do is a little something for the “Rosegarden Notation Challenge” that deals with that passage from I think Debussy in my flute owner's guide book. The bit that talks about how to play harmonics.

I want to show how to do the written notes in one segment, with appropriate marks and 0 velocity so they don't sound, and the sounding notes in a parallel segment in small size notes sounding the actual pitches that should be heard when playing the written notes.

(It would also be cool as hell to automate this with some “rewrite this passage as harmonics” function. It could either take existing notes that are supposed to be the written pitches and calculate the harmonics, or take the sounding pitches and calculate the written pitches from there. This is something that's probably too big a can of worms to ever actually get done though. I'm thinking flute here, but all kinds of instruments can play harmonics, and different harmonics, and then I think even in the flute world it might not be all that standardized, so it's probably something that would be rather ridiculous to try to write. Who knows.)

I've been promising that damn thing for years, and have never gotten it written. Although in this new and braver world, it makes me wonder if we couldn't revisit the whole topic of repeats and alternate endings and finally come up with a solution that isn't such a steaming pile of crap. This whole thing is in “not impossible” territory in the worst way. It is possible, but boy is it a mess.

It might be worth taking the hit and porting all the tutorials and even Rosegarden Companion and the Handbook to the wiki. A lot of up front work, but potentially better long-term maintainability.

I'd like to retire from being the primary doc writer and just serve as editor in chief, because I just can't do everything, and I've become too useful as a developer.

'Nuff said about that. I guess it's just too late for Thorn, but for after, we shall not do another release without sorting that mess out once and for all!

(I should dig out the old notes and post a copy here for easy access.)

On Thursday 03 September 2009, Heikki Johannes Junes wrote:

However, I would like to see “above” and “below” versions of all marks.
That would elevate the capabilities of the notation editor a lot.

I agree. These new more sensible defaults are better *defaults*, but LilyPond has the flexibility to allow the user to override the defaults when it's called for. Fermata on top makes sense most of the time, but look at the opening to Bach's “Toccata and Fugue in Dm” (too lazy to look up the BWV number) for a fermata that needs to go below.

If you would like to waste time in an interesting way, I would vote for
implement “above” and “below” versions of marks in Rosegarden.

It's good you spoke up, because I had considered this idea briefly, and then decided to set it back down. With you strongly in favor of the idea, that's probably the incentive I need to work through the problems it presents.

This isn't something to get done for Thorn, as interesting as that would be. We have real problems with the ability to export marks of an arbitrary direction, because stem direction isn't a persistent property that can be tested from the LilyPond export code. True, some marks can already flip, and we do the best we can with those, and it is possible to work around these limitations by manually flipping stem directions to set persistent properties.

However, I feel like there's too much danger of just wrapping more layers of duct tape around something that's probably so broken it really needs to be replaced with a mechanism that works properly, much as Chris wrote a new grace note mechanism, much as I'm in the process of replacing a useless kind of mark with a mark and indication combination that will work. I don't know exactly what the best overall solution is yet though, and this one is something we really do need to decide around a discussion table before embarking on the work.

So some first thoughts there:

I think we do an adequate job of getting the exported stem directions right just by using the same defaults Rosegarden does, and being able to detect when those defaults are overridden, so we probably don't technically have to fix the stem direction property issue in of itself.

It seems like it could well be interesting to make marks go above or below on command *regardless* of stem direction too. Have sensible defaults with the mark going opposite the stem, and the ability to change this as required by having the mark direction itself become an independent property.

That's some real bit of complex thinking there, that's just more than I want to consider at this time. How to give bits of text attached to an event an independent direction property, and how to edit that.

My first thoughts are replace the text with a std::pair where the second in the pair is an up/down property, and set this new property to a reasonable default where the property didn't previously exist (as when encountering old data).

Then once the properties exist, and it's possible to flip marks independently of stems, there has to be some way to control it all that isn't too much of a pain in the ass. See, a note can have up to n marks, and how do you change *this* one and *that* one, but not the rest?

I don't think we'd have to go so far as to invent something completely new and incompatible. It might suffice to have a second, inverted marks toolbar that flips like the notation toolbars flip, depending on whether you are in “insert stanard mark” or “insert inverted mark” mode. They'd mirror each other, and the “standard mark” toolbar would have the sensible defaults, with some up, and some down, and the other the opposite.

It would be nice to have independent control after the fact with some “advanced mark position editor”, but this is probably too much of a headache to implement, and could be dispensed with, leaving the user to hit the trash can button and start from scratch on the rare occasions they need to change one mark independently in a set that already exists. Or maybe that's too much of a hassle.

Anyway, put this on the list of things I am seriously interested in doing, which are too big to attempt before Thorn. Also, this comes after I sort out the barline problems, but probably before I try to do something a lot less horrible to use in the way of managing alternate endings and so forth.

Another thing in this same area: better vertical layout code. The way we draw these marks is too simplistic, and doesn't work well. We can get away with it in a world where LilyPond fixes the problem, but the closer we can get to making our on-screen output look like LilyPond output, the better. In short, don't draw marks in the middle of staff lines most of the time. Draw them where they're going to be legible. This one may just be more of a headache than I feel like taking on, but I'm going to give it a real look now that I've got my sleeves rolled up, and someone other than Chris finally has his hooks in the notation code well enough to understand and take on ambitious projects.

Another thing: grace note ledger lines are thinner than standard ledger lines, and there is a scaling problem.

I'm not suggesting I will or should do all of this alone, but I'm hoping to be the engine that drives momentum on all of this.

Of course it needs saying that even while I consider all of these dreams, I have to face the reality of my economic situation soon. If and when I get a real job again, I'm not going to have the kind of time I do now to poor down this well.

Hah. Funny Freudian typo. “poor down this well”