Clef and Transpose ------------------ Widgets in the GUI pass their changes to the appropriate track object.
Properties are loaded from and saved to XML, and used to populate widgets Properties affect the segment pencil, and new segments are created with the correct clef and transposition. TODO: apply these properties to segments that have been recorded too Color ----- Infrastructure in place to make the property real. TODO: put something useful on both ends of the property. I'm in the process of working the kinks out of code ported from segmentparameterbox.cpp to make the widget work. No action has been taken to make this property affect new segments yet. Highest/Lowest Playable ----------------------- Infrastructure in place to make these properties real at the track level. TODO: put something useful on both ends of the property. There's no GUI for this yet. These properties need to exist at the segment level before segments can be created with these properties. The notation editor needs to see this new property of segments, and make graphical changes accordingly. Notes outside the range will be drawn in red, probably with a toggle to turn that feature off. Presets for Real Instruments --------------------------------------- TODO: Everything. There's nothing to see here yet, except a button that doesn't do anything. The broad plan here is to make the button launch a new dialog. The dialog will populate some widgets from our extensive database of presets (thanks in advance to Magnus Johansson, who is assembling the raw data for this database for us) and inject them into the TPB widgets. The rough sketch for this is some dialog with Family [strings|brass|woodwinds|percussion] Instrument [...] Player [amateur|professional] I've decided to pick amateur vs. professional here, and have just one set of track highest/lowestPlayable, for a variety of practical reasons, but the database will include ranges for both, so the net result of the intention is the same. Along the way to implementing this final step, we need to decide how to store these presets, and what to do about making it possible for users to edit and store their own. We could start with hard coded presets with code automatically generated from the text file Magnus is creating, or we could just get all of this right from the beginning, and make the presets part of some user extensible database. One way or another, I don't want to handle this by having the user employ a File->Open dialog to dig through a huge pile of files on the disk. I want to assemble any files on disk (or hard code) into a list that's presented in similar fashion to programs and banks, so it's a wheel or a click away, and no boring rooting around in a directory is required. I could really use help figuring out how/and or writing the code to handle the back end of all of this in the most appropriate manner. If I have to do it all myself, we'll wind up with hard coded presets that can only be changed at compile time for sure. Timeline -------- I hope to get the color stuff working tonight and commit my work to date before I go back to my paying job. The work in its current state should be far enough along, with enough stuff at least stubbed out, for other people to see what's going to get in their way, and avoid an endless series of conflicts. I expect to get the highest/lowest stuff working in the next week or two, depending on how much hell there is to pay at work for this vacation. I think we should probably expect to defer the presets bit until after 1.3. There is probably too much to do to get that ready before the beginning of September, and the feature is going to be so huge, in my opinion, it pushes the next release into 2.0 territory. In the meantime, we don't need to be able to load presets from an extensive database in order to start putting together a template library. That is probably in scope for 1.3. Just .rg files with empty tracks that have track defaults pre-selected for sensible defaults that have been put in by hand. If we don't have time to set up a proper new template directory this go round, we can just add a few of them to the sample file library for now. This last would be even better with new LilyPond staff export options, such as described in a recent message by Pedro. I don't know if I will find time to get into that in the foreseeable future or not, so if we want it for 1.3, it would be nice if someone else could start working on that. Heikki? Are you listening? Are you interested? Though I'm really starting to feel like we might just want to push 1.3 back to next February, and call it 2.0. What's the point of going a year between releases, and then suddenly putting out two within a couple months of each other? And this is how *I* spend *my* vacation people. South of France my ass. -- D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
