Menu
▾
▴
[Rosegarden-bugs] SF.net SVN: rosegarden:[10947] website/wiki/data
|
From: <ca...@us...> - 2009-09-23 15:02:47
|
Revision: 10947
http://rosegarden.svn.sourceforge.net/rosegarden/?rev=10947&view=rev
Author: cannam
Date: 2009-09-23 15:02:36 +0000 (Wed, 23 Sep 2009)
Log Message:
-----------
* update svn from live wiki
Modified Paths:
--------------
website/wiki/data/pages/dev/9.x.txt
website/wiki/data/pages/dev/branching.txt
website/wiki/data/pages/dev/coding_style.txt
website/wiki/data/pages/dev/contributing.txt
website/wiki/data/pages/dev/development.txt
website/wiki/data/pages/dev/future_plans.txt
website/wiki/data/pages/dev/overall_code_structure.txt
website/wiki/data/pages/dev/qt4_bug_tracker.txt
website/wiki/data/pages/playground/playground.txt
website/wiki/data/pages/projects.txt
website/wiki/data/pages/start.txt
website/wiki/data/pages/wiki/dokuwiki.txt
website/wiki/data/pages/wiki/syntax.txt
Added Paths:
-----------
website/wiki/data/media/dev/kompare.jpeg
website/wiki/data/pages/dev/after_thorn.txt
website/wiki/data/pages/dev/candidates_for_future_symbols.txt
website/wiki/data/pages/dev/config_groups_config_groups.txt
website/wiki/data/pages/dev/creating_events.txt.txt
website/wiki/data/pages/dev/device_management_and_replacing_auto-connect.txt
website/wiki/data/pages/dev/michael.txt
website/wiki/data/pages/dev/missing_slots.txt
website/wiki/data/pages/dev/new_developers.txt
website/wiki/data/pages/dev/notation_toolbar_2.txt
website/wiki/data/pages/dev/units.txt.txt
website/wiki/data/pages/dev/using_git.txt
website/wiki/data/pages/development_from_svn.txt
Added: website/wiki/data/media/dev/kompare.jpeg
===================================================================
(Binary files differ)
Property changes on: website/wiki/data/media/dev/kompare.jpeg
___________________________________________________________________
Added: svn:mime-type
+ application/octet-stream
Modified: website/wiki/data/pages/dev/9.x.txt
===================================================================
--- website/wiki/data/pages/dev/9.x.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/9.x.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -1,16 +1,64 @@
-====== ROSEGARDEN 09.10, codename "Abraham Darby" (to be) RELEASED ======
+====== ROSEGARDEN 10.02, codename "Thorn" (to be) RELEASED ======
**IMPORTANT: THIS HAS NOT HAPPENED YET**
-**This page is only a working area for making notes about what is being done for the 09.10 release, so that we don't forget anything when the code is finally ready to be released -- which will not be for some time yet.**
+**This page is only a working area for making notes about what is being done for the 10.02 release, so that we don't forget anything when the code is finally ready to be released -- which will not be for some time yet.**
-The Rosegarden team is proud to announce the release of version 09.x of Rosegarden, an audio and MIDI sequencer and musical notation editor for Linux.
+The Rosegarden team is proud to announce the release of version 10.02 of Rosegarden, an audio and MIDI sequencer and musical notation editor for Linux.
http://www.rosegardenmusic.com/
-With this release, Rosegarden has become a modern Qt4 application that no longer uses the KDE libraries, which we hope will facilitate future maintenance. The primary focus of this release has been the effort to port from Qt3 and KDE3 to Qt4, which was a very difficult, time-consuming job that involved a great deal of rewriting. There should be as little difference as possible between this version and 1.7.3, and this is one release where no news is good news. We will be able to take full advantage of Qt4 in future releases to offer a number of planned improvements.
+With this release, we finally bring an end to the long and difficult job of transforming Rosegarden from an obsolete KDE 3 application into a modern Qt 4 application. We had aimed to defer the largest rewriting jobs until after an initial release of the new code, but so many things broke along the way that we were forced to dive into many refactoring projects ahead of schedule. The result is a leaner, cleaner Rosegarden with less cruft, and some exciting new features.
+===== Usability Enhancements =====
+ * With its bold new custom look, including hundreds of new icons, Rosegarden ensures all of its interface elements are usable, freeing you to configure the rest of your system any way you like
+ * With its more compact, netbook-friendly interface, Rosegarden gets more done with less screen real estate
+ * Rosegarden has a low installation footprint, and creates local, user-editable copies of all example and library files
+ * Expanded translations (varies by language) put more of Rosegarden in your native language than has ever been possible before
+ * You may now run as many instances of Rosegarden as you like, in parallel, and can even install and run different versions simultaneously
+ * Enhanced device management support, including an all-new MIDI device manager, finally addresses a number of long-standing usability issues and bugs
+ * Control rulers (notation and matrix) completely redesigned from the ground up to use primary editing tools (eg. pencil) and present controller data as a series of connected points that may be manipulated very fluidly and easily
+ * A number of non-critical warning dialogs about system configuration issues have been moved out of your way, and onto a compact health indicator at the bottom right of the main window
+ * You can add, display and access what we hope will prove to be an effectively unlimited number of MIDI controllers in the instrument parameters box, eliminating the need for an alternative tabbed layout mode
+ * New streamlined interface merges the insertion cursor functions into the playback cursor, so Rosegarden has only one cursor at long last
+ * All new integrated project packager provides built-in, native support for Rosegarden project packages, eliminates a number of obscure dependencies, and provides a cleaner user experience
+ * Document modified status is indicated in the title bar
+
+===== New Features =====
+
+==== General ====
+ * Most windows have special function-related icons associated with them, so it is easier to use your desktop task manager to find the window you seek
+ * Improved flashing metronome mode and more realistic looking LEDs for the transport
+ * Rosegarden comes bundled with a library of composition templates (.rgt files), and any file can be saved as a template with the new File => Save As Template option
+ * New support for Frontier Design Group’s TranzPort™ contributed by Immanuel Litzroth
+
+==== Notation ====
+ * Higher quality on-screen rendering removes the annoying chromatic artifacts that have afflicted all previous versions, and provides crisp, clear rendering
+ * New pan and zoom allows you to move around quickly, and zoom the window contents as far in or out as you like
+ * Print and Print Preview are both performed through LilyPond, which provides extremely high-quality output
+ * Expanded range of point sizes (from 6 to 30) available for LilyPond export
+ * New interactive LilyPond Print/Preview allows you to configure your preferences for which applications you prefer to use for printing files and viewing PDFs, and compares the result of the LilyPond conversion operation against your LilyPond export options in order to offer intelligent suggestions for what steps to take when things go wrong
+ * New support for notation symbols, giving Rosegarden the ability to display (non-operative) segno, coda and breath mark symbols
+ * New marks for open, stopped/muted, and harmonic/flageolet
+ * All marks are exported to LilyPond now, and mark placement has been aligned with LilyPond's placement rules, following the philosophy that they have spent vastly more time studying best notation practices than we have, and where we disagreed, we were wrong
+ * Add Trill With Line moves from Note ==> Marks... and the marks toolbar to Phrase and the group toolbar, reflecting an internal change that transforms this from a mark attached to a single note into a more flexible indication that can span any number of (usually tied) notes. The mark version still exists internally to preserve compatibility with existing compositions
+ * Even quicker and improved keyboard access to inserting notes and rests, with the default duration determined by the denominator of the current time signature
+ * More compact notation toolbar layout combines note and rest entry in one place, freeing up space, and improving efficiency
+
+==== Matrix ====
+ * Translucent event bars make it easier to see and work with overlapping notes
+ * New pan and zoom allows you to move around quickly, and zoom the window contents as far in or out as you like
+
+
+
+ * Markers text entry fields have been renamed to make it more clear which of the two editable texts is the functional one
+ * The simple event editor now handles notation-quantized notes more intelligently
+ * Improved controller manager dialog now opens the editor automatically after creating a new controller
+
+
+
+
=====The Porting Team=====
We'd like to give special thanks to the following members and contributors, some old, some new, for their outstanding work on the long and difficult port. These brave few are the authors of a new chapter in our history.
@@ -23,42 +71,26 @@
* Chris "CJ" Fryer
* Heikki Junes
* Shelagh Manton
+ * Jani Frilander
+ * Mikko Vepsäläinen
+ * Ilan Tal
===== Thanks To =====
* Luis Garrido
* David Willis
-======New Features======
- * Ported to Qt4
- * Removed all ties to KDE for a lower dependency footprint
- * Stunning new look that is equally at home on KDE, GNOME, or any other Linux desktop
- * Add translation support for more than 1000 strings that have never been translated before, allowing a much more highly localized user experience
- * Most application resources are now bundled inside the application itself, reducing its installation footprint
- * From here forward, each new release will install its data files to a unique location, allowing you to run different versions (eg. a stable production version and a release candidate) in parallel without data file version conflicts
- * It is finally possible to run more than one instance of Rosegarden at the same time!
- * All new MIDI device manager rewritten from scratch, with an innovative mechanism for making and breaking connections
- * New "Save As Template" option saves files with a special new .rgt extension, which discourages you from overwriting your template for a string quartet with your newest composition for string quartet. (As time goes on, we will be putting together a collection of useful templates in much the same way as we have been accumulating MIDI device library files over the years.)
- * New support for Frontier Design Group’s TranzPort™ contributed by Immanuel Litzroth
-
- * Expanded range of point sizes (from 6 to 30) available for LilyPond export
- * A complete set of crisp new icons for the notation editor
- * Most windows have special function-related icons associated with them, so it is easier to use your desktop task manager to find the window you seek
- * Improved flashing metronome mode and more realistic looking LEDs for the transport
- * Markers text entry fields have been renamed to make it more clear which of the two editable texts is the functional one
- * The simple event editor now handles notation-quantized notes more intelligently
- * Improved controller manager dialog now opens the editor automatically after creating a new controller
-
-====Significant Bug Fixes====
+==== Bug Fixes ====
- * Exporting project files to paths that have spaces no longer fails
+ * The project packager can now handle spaces in paths and filenames
* Faders can now be moved in both directions with the mouse scroll wheel
* Corrected LilyPond export of double octave clefs
* Corrected rendering problem when moving expanded-height tracks
-
-====Minor Bug Fixes====
* Controller editor dialog now keeps track of the color index properly
* Newly created knobs of color "default" now display the correct color, rather than black
+ * Rosegarden no longer creates useless, confusing extra devices, which solves many related problems
+ * Percussion tracks now sound when importing broken MIDI files that use zero-length notes for percussion
+ * The forward and back tab navigation buttons on the MIDI mixer work properly now
@@ -67,6 +99,10 @@
* Heikki Junes
* D. Michael McIntyre
* Thorsten Alteholz
+ * Yves Guillemot
+ * Alexandre Prokoudine
+ * Jani Frilander
+
===Other people who contributed to Rosegarden development:===
* Immanuel Litzroth
@@ -77,3 +113,5 @@
* Theo Smit
* ADR
* Sezer Dursun
+ * Julie Swango
+ * Geoff King
Added: website/wiki/data/pages/dev/after_thorn.txt
===================================================================
--- website/wiki/data/pages/dev/after_thorn.txt (rev 0)
+++ website/wiki/data/pages/dev/after_thorn.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,25 @@
+====== Post-Thorn Refactoring Jobs ======
+
+We're leaving a lot of messy things behind in the interest of getting the job done. These items (at least the items I have in mind as I'm creating this list) are pretty ugly in code terms, but don't affect end users much, if at all, and they require more fiddling than clean code justifies in the short term.
+
+===== Deprecated Parameter Area Layout Modes =====
+
+An astronomer once went to Chile, never to be heard from again. Before he left his country of origin (America, I think), he submitted a patch to give RosegardenParameterArea the ability to switch between Classic and Tabbed layout modes. The tabbed mode put each of the SPB, TPB and IPB on different tabs, rather than stacking them vertically. This allowed each parameter box to have more vertical space without resorting to the use of scrollbars.
+
+The underlying purpose of this alternate arrangement was to make it possible to show more than n controllers at the same time in the IPB. This astronomer had need of a large number of MIDI controllers, and had no way to make them all available at the same time.
+
+This alternate arrangement was never popular, but it was necessary for a few. In Thorn, it is no longer necessary at all, because:
+
+ * Users can add controllers to up to 1024 different slots in the IPB
+ * All controllers are displayed
+ * The whole shebang sits inside scrollbars now, so it can grow as tall as it needs
+
+The Tabbed arrangement has never been re-implemented, and the guts of making it work again are commented out. It is time to remove all of that cruft and simplify all of this code back to something similar to what it was before all of this layout fiddling began. However, the layout switching code is deeply entrenched in a cascade of errors originating in RosegardenParameterArea. Going in to just remove all of this cruft is going to be a touchy job that requires some real thought to avoid subtle breakage.
+
+The "classic" layout mode that is currently the only functional mode is intact and working in spite of all this unused cruft, and I think it is wise to ignore this dusty closet full of junk until after Thorn. After that, I'd really like to see it cleaned up, and all the bugs hunted out of patching code across this empty cavity.
+
+===== And? =====
+
+I lost my train of thought for the other one I was going to throw in here. Oh well.
+
+
Modified: website/wiki/data/pages/dev/branching.txt
===================================================================
--- website/wiki/data/pages/dev/branching.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/branching.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -1,40 +1,133 @@
======Working with branches======
+To branch or not to branch?
-If you would like to play in developing something new, which may potentially break the software, create a new branch to play with.
+The decision whether to branch or not is not really something that follows a strict formula, but you should consider doing your work in a branch if it:
-=====1 Creating a new branch=====
+ * involves disabling a lot of code in order to work through a problem step by step until it is finally solved
+ * is an experimental idea that might not be an improvement, or might not be workable after all
+ * is something big and new that might require design modification before everyone can agree on including it in trunk/
+ * is anything likely to interfere with another developer's work while you tinker with it
+ * if you ever plan to commit code in a broken, non-working state during your development process
-Create a new branch by copying the trunk. For example, for a branch called my_branch, do the following (as a single one-line command):
+Of these, the only really critical and absolute rule is that you must always exercise all possible caution to try to avoid breaking trunk/, and if you ever anticipate committing half-working code, you should almost certainly do this in a branch.
+=====Moving existing code into a branch=====
+
+The best practice is to think everything out before you begin, realize that you will need to work in a branch, create that branch, and do all your work in there from the beginning.
+
+In reality, it is very common for a developer to begin some project without thinking all of this through for one reason or another. Perhaps what was supposed to be simple has turned out to be much more complicated than expected. Maybe a quick hour of code to knock something out is going to turn into a week or more before all the unexpected problems can be sorted out. Sometimes, you will even begin working from and committing to trunk/ without realizing that your work really should have been done in a branch first, and someone will ask you to branch and complete your work there; merging it after whatever controversy is resolved to everyone's satisfaction.
+
+This is simple to deal with, if this every happens to you. Simply take a patch of your current working copy before you proceed with creating a branch and checking it out.
+
<code>
+svn diff > <patch_my_branch>
+</code>
+
+//Note:// Replace <patch_my_branch> with a real filename of your choosing
+
+To avoid causing yourself problems down the line, now that you have taken this patch to use later, you should revert these changes from your working copy of trunk/ before continuing.
+
+<code>
+patch -R -p0 < <patch_my_branch>
+</code>
+
+You can double check that everything worked properly by running
+
+<code>
+svn diff
+</code>
+
+This should produce no output.
+
+//Note// This technique works very well if all of your modifications were to files that were already under version control. If you have already started adding new files, but have not yet put any of them under version control, they will not be included in your patch, and you will need to keep up with them and move them into your working copy of your new branch later on. Unfortunately, svn diff is of no help in this situation.
+=====Creating a new branch=====
+
+Whether you are beginning completely from scratch, or you are creating a branch out of existing work you began in trunk/, the next step in this process is to create the branch itself in the Subversion repository.
+
+Create a new branch by copying trunk/. For example, for a branch called <my_branch>, do the following (as a single one-line command):
+<code>
svn copy https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/trunk/rosegarden \
- https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/my_branch
+ https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/<my_branch>
</code>
You can see what branches already exist (so as to get ideas for a new name, perhaps) using
<code>
svn ls https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/
</code>
-=====2 Checking out a branch=====
-Replace <user> with your sforge username and lilypond_everywhere with the branch you are working.
+(Or you can browse the the online Subversion repository at http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/branches/)
+
+//Note//: Replace <user> with your SourceForge username and <my_branch> with your branch name.
+
+=====Checking out a branch=====
+
<code>
-svn co my_branch
+svn co <my_branch>
</code>
-The full command to checkout my_branch using username is
+The full command to checkout my_branch using username is:
<code>
-svn checkout https://use...@ro.../svnroot/rosegarden/branches/my_branch my_branch
+svn checkout https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/<my_branch> <my_branch>
</code>
+//Note//: Replace <user> with your SourceForge username and <my_branch> with your branch name.
-=====3 Committing changes to the branch=====
+After the checkout completes, take note of the revision number for later, so you don't have to dig it back up when it comes time to merge. The last message from Subversion will tell you this piece of information, for example:
+<code>
+Checked out revision 10745.
+</code>
+=====Applying your patch=====
+
+If you took a patch of the work you began in trunk/ then now is the time to apply that patch to your new working copy of your new branch. Simply use
+
+<code>
+patch -p0 < <patch_my_branch>
+</code>
+
+//Note:// Be sure not to use the **-R** option in the patch command this time. Replace <patch_my_branch> with the real filename you selected earlier.
+
+If you created any files that were not yet under version control, and were not included in that patch, now is the time to move them across into this directory.
+
+Now you are ready to commit the beginning of your new branch, and get to work in here!
+
+=====Committing changes to the branch=====
+
Working with branches is as easy as working with the trunk. Commit the changes from the root directory of the branch.
<code>
-cd my_branch
+cd <my_branch>
svn commit -m "Text which describes the updates."
</code>
-=====4 Merging changes from trunk to the branch=====
+=====Merging changes from a branch to trunk=====
+
+For most branches, you want to keep the merge as simple as possible, and only do this once. Chris Cannam recommends ignoring trunk/ until you are ready to merge, and then doing the merge starting by taking a temporary working copy of trunk/ to get started:
+<code>
+$ svn co https://rosegarden.svn.sourceforge.net:/svnroot/rosegarden/trunk/rosegarden \
+ tmp-working-copy
+</code>
+
+Then change into tmp-working-copy/, and using the revision at which you branched (which you took note of earlier) and the name of your branch, do something like:
+<code>
+$ cd tmp-working-copy
+$ svn merge -r<10208>:HEAD
+https://rosegarden.svn.sourceforge.net:/svnroot/rosegarden/branches/<my_branch>
+</code>
+
+//Note//: Replace <my_branch> with your branch and and <10208> with revision number of the branch noted earlier.
+Resolve conflicts, build, test... Then run
+
+<code>
+svn diff
+</code>
+
+to make sure what you're about to commit looks sane. Then fire away with
+<code>
+svn commit
+</code>
+
+=====Merging changes from trunk to the branch=====
+
+If you are going to be working on the branch for a long time, you may wish to reduce the number of conflicts you may eventually have to resolve by periodically merging from trunk/ into your branch, and then merging the branch back at the end of its life cycle.
+
You may check the Last Changed revision of the branch with command
<code>
svn info
@@ -50,34 +143,82 @@
</code>
Note that such a committing does not work if you had conflicts, therefore, resolve conflicts before committing changes.
-=====5 Resolving conflicts=====
+=====Resolving conflicts=====
-In the case of a conflict, there will be 'C' in the place of the file which contained conflicts.
+A conflict occurs when you try to update your working copy from a repository that has conflicting changes in it. This can happen during the normal course of development, when two different people happen to work in the same place. (One common circumstance is that developer C commits broken changes, and both developers A and B rush in with two slightly different, conflicting fixes.)
+
+During a merge, this happens when your branch changes some part of the code that also changed in trunk/, and Subversion cannot decide how to put all the pieces together.
+
+When you experience a conflict (such as the real conflict upon which I'm basing this example), recent versions of Subversion will prompt you what to do:
+
<code>
-C foo.c
+Conflict discovered in 'data/rc/rosegardenui.rc'.
+Select: (p) postpone, (df) diff-full, (e) edit,
+ (h) help for more options:
</code>
-Such a file will be splitted to several parts.
+
+Chris recommends that you just choose **p** to postpone conflict resolution. (For binary conflicts, you will also get **tf** and **mf** for "theirs full" and "mine full" respectively. Which to choose will depend entirely on the circumstances.)
+
<code>
-foo.c
-foo.c.r8115
-foo.c.r8119
-foo.c.working
+ (h) help for more options: p
+--- Merging r10774 through r10874 into 'data/rc':
+C data/rc/rosegardenui.rc
</code>
-After you have resolved conflicts, remove the extra files and commit the changes.
+
+After the conflict, you wind up with several files, similar to these:
+
+| file | description |
+|rosegardenui.rc | original file with alternatives written in |
+|rosegardenui.rc.merge-left.r10773 | changes from the left revision (-r[left]:[right]) |
+|rosegardenui.rc.merge-right.r10874 | changes from the right revision (-r[left]:[right]) |
+|rosegardenui.rc.working | your previous working copy |
+
+Chris works with the plain .c file, which is the original file with the conflicts given in an "alternatives" diff-like form, such as this excerpt:
+
<code>
-rm foo.c.*
-svn commit -m "merge from trunk"
+ <Action name="file_revert"/>
+ </enable>
+</State>
+
+<<<<<<< .working
+<State name="have_project_packager">
+ <enable>
+ <Action name="file_import_project"/>
+ <Action name="file_export_project"/>
+ </enable>
+</State>
+
+=======
+>>>>>>> .merge-right.r10874
+<State name="have_segments">
+ <enable>
+ <Action name="move"/>
</code>
-=====6 Merging changes from a branch to trunk=====
-Merging from branch to trunk is similar to merging trunk to branch, see **4 Merging changes from trunk to the branch.**
+In this case, I apparently removed some code from part of the file that simultaneously changed in trunk/ and Subversion got confused. I can't remember what I did where, or who did what, so while Chris recommends working only with the plain .c file, I have found I can't figure out what I'm looking at in this case.
+I decided to have a look with Kompare.
+<code>
+kompare rosegardenui.rc.merge-left.r10773 rosegardenui.rc.merge-right.r10874
+</code>
-However, when committing the merge from the branch, **make a verbose changelog on the changes**.
+{{:dev:kompare.jpeg|}}
-=====7 Closing a branch=====
+I find the visual presentation easier for getting a real sense of what's going on, although the particular example I happened to have chosen to present here (because it was the first one I had at hand) is not particularly good. This conflict is easy to resolve.
+In any case, once you have discovered what is going on to your satisfaction, edit the file until you're happy with it, then run
+
+<code>
+svn resolved <filename>
+</code>
+
+to tell Subversion that you have resolved the conflict.
+
+Test and commit.
+
+=====Closing a branch=====
+
When a branch is finished with, we usually either delete it if it was very short-lived and uninteresting,
<code>
svn rm https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/uninteresting
@@ -86,5 +227,4 @@
<code>
svn mv https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/my_branch \
https://<user>@rosegarden.svn.sourceforge.net/svnroot/rosegarden/branches/obsolete/
-</code>
-
+</code>
\ No newline at end of file
Added: website/wiki/data/pages/dev/candidates_for_future_symbols.txt
===================================================================
--- website/wiki/data/pages/dev/candidates_for_future_symbols.txt (rev 0)
+++ website/wiki/data/pages/dev/candidates_for_future_symbols.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,18 @@
+====== This is a scratchpad for ideas about the new Symbol class ======
+
+Symbols are a new thing that have subordering and duration like text events, for example performance directions, tempo indications, and other such that are no-ops from a sequencer perspective, but will display suitable glyphs on the staff instead of arbitrary or canned texts. The first three of these are the segno, coda, and breath mark, which aim to be a 1:1 replacement for the LilyPond directive Text tool based hacks that have been working and exportable for some time.
+
+I expect that's about as far as I will take the new concept for Thorn's release, lest I get too sidetracked with fun and entertaining projects instead of the backbreaking but mandatory work of repairing critical infrastructure and readying everything for release.
+
+So these are random thoughts I have looking through note fonts for glyphs I might want to do as Symbols one day:
+
+ * the "repeat last measure" thing '/. (and what are / and '//. for anyway? I'm not sure, but they may be worth including)
+ * arpeggio wave thingies
+
+ * replace the whole horrible NextBarIsAlt1 garbage with what? And draw it properly. (This one seems pretty hard, because this was implemented as a flag to exist in the bar before it would take effect for processing reasons. In the near term, it might be all we could realistically manage would be a pretty indicator instead of the lame green text thing. That might be workable if it spanned a barline, and looked like Alt 1 ----> |1.---------- as one big wide thing where the active bit would be in the right bar, and the inactive visual bit would or could at least sit in the correct place to make some musical sense, instead of leaving everything to the user's imagination as is currently the case with this hideous mechanism I've never properly explained to anyone, which is almost unusable, but just barely not.)
+
+ * some suitable hackery for barlines that might needs out of practicality resemble the above. Put the active bit just ahead of the affected barline, and then show what it's going to do visually. Or maybe just make barlines real entities in the process of sorting out the whole "raising the bar" discussion that never was, which is apparently all on you.
+
+These might ought to be indications instead, actually:
+
+ * glisando lines
\ No newline at end of file
Modified: website/wiki/data/pages/dev/coding_style.txt
===================================================================
--- website/wiki/data/pages/dev/coding_style.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/coding_style.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -133,3 +133,4 @@
===== See also: =====
* [[layout_code|Qt Layouts]]
+ * [[[config_groups]Config Groups]]
Added: website/wiki/data/pages/dev/config_groups_config_groups.txt
===================================================================
--- website/wiki/data/pages/dev/config_groups_config_groups.txt (rev 0)
+++ website/wiki/data/pages/dev/config_groups_config_groups.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,25 @@
+====== QSettings Config Groups ======
+Rosegarden currently uses a mixture of idioms after the conversion to use QSettings for storing user preferences. The first type of code looks like:
+
+<code c++>
+ QSettings.settings;
+ settings.beginGroup("Lazy Options Directly in a String");
+ ...
+</code>
+
+The second type of code looks like:
+
+<code c++>
+ #include "misc/ConfigGroups.h"
+ ...
+ QSettings settings;
+ settings.beginGroup(SomeOptionsConfigGroup);
+</code>
+
+It is always preferable to use the second idiom whenever you have some new need of a new settings category. Take the time to edit and include misc/ConfigGroups.h, and use the constant defined there throughout the code. This does mean some extra work and compile time, but in the long run having the discipline to use ConfigGroups.h throughout lowers our chances of having stupid settings-related bugs where one piece of code reads from "Lazy Options Directly in a String" and another piece writes to "LazyOptionsDirectlyinaString" or what have you.
+
+I would go so far as to say that whenever you encounter the lazy type, it would be good to take a moment to go fix it. There aren't too many of the lazy type left, and we could make them go away pretty quickly, and avoid future "settings amnesia" bugs.
+
+Whether you take it upon yourself to do these cleanups or not, please use ConfigGroups.h in any new code. Also, please feel free to create new ConfigGroups as seems appropriate. For example, when I did the work to make windows remember their positions, I put all window positions into the same ConfigGroup for consistency across the application, and easy block copying of the code snippet to make the save/restore work. You certainly don't need to feel limited to the ConfigGroups that already exist.
+
+**NOTE**: Oh, and you should avoid using spaces in the ConfigGroup strings. Either use underscores (Collapsing_Frame) or run the words together (CollapsingFrame). It is legal to use spaces, but Qt escapes them out, and this makes the config file difficult to read when it becomes necessary to debug it. "Collapsing Frame" becomes "Collapsing%20Frame" and I find that extremely irritating, so I would prefer to avoid the problem by leaving spaces (and any other characters which would need to be escaped) out of these strings. Thanks everyone.
Modified: website/wiki/data/pages/dev/contributing.txt
===================================================================
--- website/wiki/data/pages/dev/contributing.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/contributing.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -22,10 +22,8 @@
====1. Check out the current Subversion trunk====
-<code bash>svn co https://svn.sourceforge.net/svnroot/rosegarden/trunk/rosegarden</code>
+<code bash>svn co https://rosegarden.svn.sourceforge.net/svnroot/rosegarden/trunk/rosegarden</code>
-//NOTE: you may get an error about a failed certificate. SourceForge is in the process of transitioning from a URL scheme like ''https://rosegarden.svn.sourceforge.net'' to ''https://svn.sourceforge.net'' and I have used the latter format above. If you encounter a failed certificate, please use ''https://rosegarden.svn.sourceforge.net'' instead.//
-
====2. Prepare the build environment====
Rosegarden has many dependencies. It should be possible to satisfy the build requirements using stock packages from any recent distro at least as far back as Ubuntu 8.04, although we strongly recommend building with Qt 4.5 or later if possible, due to its very significant improvement in graphics rendering speed.
@@ -36,8 +34,9 @@
^ Command/Library ^ Min. Version ^ From (.deb-based) ^ From (.rpm-based) ^
| gcc | 4.1 | gcc-4.1 | |
+| g++ | 4.1 | g++-4.1 | |
| automake | 1.10 | automake | |
-| make | 3.81 | make | |
+| GNU make | 3.81 | make | |
| makedepend | 1.0.1 | xutils-dev | |
| pkg-config | 0.22 | pkg-config | |
| qt | 4.4.1 | libqt4-dev | |
@@ -46,7 +45,11 @@
| ladspa | 1.1 | ladspa-sdk | |
| dssi | 0.9 | dssi-dev | |
| lo | 0.23 | liblo0-dev | |
-| lilypond | | | |
+| lirc | 0.8 | liblircclient-dev | |
+| liblrdf-dev | | | |
+| libfftw3-dev | | | |
+| libflac++-dev | 1.2.1 | libflac++-dev | |
+| lilypond | 2.6.0 | | |
| libxml-twig-perl| | | |
| sox | | | |
| sndfile-convert | | sndfile-programs | |
@@ -59,6 +62,7 @@
(an attempt should be made to get this list to be completely exhaustive if possible, but that's all I've got for now, using Ubuntu LTS as a reasonable baseline for the oldest distro we should be supporting, even if we'd really work with even older versions of some of these things) (also at this writing the future of the project packager still has yet to be determined, so it's a bit hard to be totally exhaustive yet)
+
====2. Compile source (be prepared to install missing dependencies in first compile)====
$ sh ./bootstrap.sh
@@ -123,5 +127,4 @@
* [[coding_style|Coding Style]]
- * [[layout_code|Qt Layouts]]
-
+ * [[layout_code|Qt Layouts]]
\ No newline at end of file
Added: website/wiki/data/pages/dev/creating_events.txt.txt
===================================================================
--- website/wiki/data/pages/dev/creating_events.txt.txt (rev 0)
+++ website/wiki/data/pages/dev/creating_events.txt.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,117 @@
+//From email, 2002 01 04//
+
+====== Events ======
+
+To create a new sort of event, you just create an Event with
+a type name that hasn't been used before, and to add properties,
+you just use a new property name.
+
+(We have a big potential problem with namespacing property
+names, as there's no central registry of names that have been
+used. I've been considering adding something that might help,
+because we do actually intern PropertyName strings, we just
+don't yet complain about duplicates definitions -- but it won't
+prevent people from using literal strings that collide. And
+property names are global, they aren't local to a particular
+event type. Sorry, I digress.)
+
+So, for example, let's say you want a new "cow" event and you
+want to give it a couple of properties, say a string property
+for moo type (Moo, Low or Croak -- cows with colds sound
+terrible) and a bool to indicate whether it is in fact a bull.
+(There are three property types; the other's int, and they're
+defined in Property.h.)
+
+Aside from the properties, an Event also has an absolute time
+(the time in Rosegarden units -- see ../data_struct/units.txt --
+at which the event begins), a duration (the "performance"
+duration of the event in the same units, so currently always
+zero for anything but note or rest events) and a sub-ordering
+value, which is used to order events that have the same
+absolute time (it defaults to, and most usually is, zero; but
+for some things like clef events it's a small negative number
+so as to ensure they get processed and displayed before any
+notes that appear at the same time). Unlike properties, the
+time and subordering values can only be set once, when you
+create the event -- to modify them you must copy the event and
+pass new values into the copy constructor (see the header file
+for details, and see iterators.txt for discussion of how this
+affects Segment iterators that may be pointing at those events).
+
+All you have to do to create a cow and insert it in a segment is
+
+ Event *e = new Event("cow", 1000, 0); // abs time, duration
+ e->set<String>("MooType", "Low");
+ e->set<Bool>("isBull", true);
+ segment->insert(e);
+
+The strings are fairly arbitrary -- you just have to ensure
+that nobody else has already used an event called cow or
+properties called MooType and isBull. Of course, you don't
+see much real code using literal strings; the event types are
+generally just declared as string constants in various places
+(actually almost all in NotationTypes.h), but the property
+names are usually declared as constant PropertyName objects
+(in NotationTypes, BaseProperties or notationproperties, most
+usually) which is a class that's constructed from a string
+constant but interns to an integer for faster lookup, not
+that you need to deal with that at all.
+
+As another example, say you want to add a property to note
+events that indicates the usual fret number. To do that, you
+could declare a FRET_NUMBER property name in BaseProperties
+or notationproperties (with a value of, say, "FretNumber")
+and then do stuff like
+
+ Segment::iterator i = getIteratorFromSomewhere();
+ Event *e = (*i);
+ e->set<Int>(BaseProperties::FRET_NUMBER, 4);
+ ++i;
+ long fret = (*i)->get<Int>(BaseProperties::FRET_NUMBER);
+
+The get/set code is obviously more laborious than it would
+be with fixed accessor methods in classes, but it's good
+when you haven't quite decided which properties you need,
+and it means you can extend other peoples' events, and it
+means you get I/O done for you.
+
+Another thing is, you may notice various calls to "setMaybe"
+on Events as well as to "set". This is because Events
+distinguish between persistent properties (which have
+usually been set by the user through the GUI somehow) that
+get streamed out to the XML file, and non-persistent ones
+(usually resulting from caching following some calculation,
+and usually possible to recalculate whenever required if
+necessary) that don't. The set method can take an extra
+argument specifying whether you're setting a persistent or
+non-persistent property (the default is persistent), but
+it's rarely used: instead to set non-persistent properties
+we generally use setMaybe, which sets a non-persistent
+property only if there is no existing persistent property
+of the same name. This allows the user easily to override
+computed values, for example in the stem-direction menu
+functions on the score view (the user's settings are
+persistent, the computed ones are not).
+
+
+===== XML format =====
+
+Rosegarden's file format is a gzipped XML file with
+a .rg extension. (We use zlib to read and write files.)
+
+The most basic XML elements are event and property.
+Event has a type, subordering (sorry, forgot to describe
+that, it's not terribly important, it just indicates the
+ordering of events in a segment where the absolute times
+are equal -- so we can display clef before key before any
+notes at that time, etc) and duration, and then the event
+element contains a series of property elements each of
+which specifies a single property by name and type. Events
+are assumed to start at the time at which the previous
+event ended, except when overridden by a chord element
+(within which all events start at once) or a resync
+element (which specifies the starting time of the
+following event, after which events continue to count from
+there -- this is too verbose, we should change it to an
+optional absolute time property on the event element).
+
Modified: website/wiki/data/pages/dev/development.txt
===================================================================
--- website/wiki/data/pages/dev/development.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/development.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -4,6 +4,7 @@
A place to gather miscellaneous development notes.
* **See also: [[Contributing|HOWTO contribute]]**
+ * **See also: [[new_developers|A getting started page for new project members]]**
* **See also: [[Future Plans]]**
* **See also: [[http://rosegarden.sourceforge.net/code_doc|Doxygen code documentation]]**
* **See also: [[EclipseCDT|Eclipse/CDT with Rosegarden]]**
@@ -31,27 +32,22 @@
===Translations===
* [[Making strings translatable]]
-
-
====Documents in Subversion====
There are several plain-text documents found in the Rosegarden source code repository ([[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/|browse]]).
These ones are either vaguely interesting, or at least not hopelessly out of date:
+**NOTE I didn't realize this page simply linked to SVN. These documents are no longer available. We should just move them into the wiki and update them as we go, but I am not going to finish that anytime soon. The documents that have not yet been rescued can be found in http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/branches/obsolete/docs/ **
+
===Basics===
- * [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/code/guidelines.txt?view=markup|Code formatting guidelines]]
- * [[Overall code structure]] (out of date with respect to code file locations and build structure)
- * [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/code/creating_events.txt?view=markup|Creating Events and their properties]]
- * [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/data_struct/units.txt?view=markup|Pitch and time units for Events]]
+ * [[coding_style|Coding Style]]
+ * [[Overall code structure]]
+ * [[dev:creating_events.txt|Creating Events and their properties]]
+ * [[dev:units.txt|Pitch and time units for Events]]
* [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/code/iterators.txt?view=markup|Iterating over Events in segments and compositions]]
-===GUI===
-
- * [[http://%5b%5bhttp//rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/design/Menu-Standards.txt?view=markup%5D%5D|Menu layout explanation]]
- * [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/code/toolbars_management.txt?view=markup|Saving toolbar state]]
-
===Notation===
* [[http://rosegarden.svn.sourceforge.net/viewvc/rosegarden/trunk/docs/data_struct/tuplets.txt?view=markup|Triplet/tuplet event storage properties]]
Added: website/wiki/data/pages/dev/device_management_and_replacing_auto-connect.txt
===================================================================
--- website/wiki/data/pages/dev/device_management_and_replacing_auto-connect.txt (rev 0)
+++ website/wiki/data/pages/dev/device_management_and_replacing_auto-connect.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,18 @@
+===== Device Management (in Thorn), and Replacing the Unwanted Auto-Connect =====
+
+Rosegarden 1.7.x has quite a strange device management system, in which devices (meaning: virtual things within the Rosegarden document, that can be connected to external MIDI hardware ports or software programs) are created "on demand" by Rosegarden itself, connected up automatically, and so on.
+
+Devices in 1.7.x exist in two places -- there is a device record within the document in the GUI process (base/Studio), and a mapped device record within the sequencer process. The sequencer's list is actually the authoritative one in 1.7.x, and at various pivotal moments it will contact the GUI and ask it to re-pull the list of devices from the sequencer (RosegardenGUIDoc::syncDevices()). So when, for example, the user adds a device from within the device manager dialog, the add-device command (in the GUI) both adds a device to the studio and pushes a device to the sequencer; the sequencer then requests a re-pull; and the document pulls back the list of devices, hopefully matching the list it already has. When a new device is created at the sequencer side (as happens automatically when a new ALSA client becomes visible, for example), the sequencer requests a re-pull and the document pulls back the list which now contains a device it did not already have.
+
+There are various reasons why this is an awkward design from a code point of view, as well as being godawful to use.
+
+As of right now (SVN rev 10600) the Qt4 port in trunk contains much of this structure, but auto-device-creation on the sequencer has been disabled. We need to go quite a lot further, as various disgusting race conditions and so on still remain. We need to make the document's list of devices the authoritative one, and have the sequencer either refer to that directly (requiring some thought about locking strategies) or pull its own copy (perhaps simpler when re-using at least some existing code). Devices should be added to or removed from the list only when the user asks.
+
+A list of aims from an email of mine some time ago:
+
+ - On first startup with an empty composition, we should have one output device, connected to some plausible looking MIDI client if there is one. ("Plausible-looking" means that ALSA reports it as a software synth or a hardware port.) You want any more devices in your composition, create (and connect) them yourself.
+ - If a new "plausible-looking" MIDI device appears while we're running, and _if_ an existing device has no current connection at all, connect that to it. Don't create any new devices.
+ - When loading an existing composition, do our best to connect the devices in that document to connections that look the same as the ones they were connected to before it was saved. In the ideal case where all the MIDI devices are exactly the same as they were then, we should be able to do this perfectly...
+ - Make it simpler (somehow!) for the user to see and change connections in the main user interface, without having to use the MIDI device dialog. Adding and removing devices however will involve the dialog.
+
+Generally, even in comparison to the relatively muted behaviour just described, we should err on the side of caution when it comes to automatically connecting things, and we should never create, remove, or disconnect a device without the user specifically requesting it (except when creating the very first device in an empty document).
Modified: website/wiki/data/pages/dev/future_plans.txt
===================================================================
--- website/wiki/data/pages/dev/future_plans.txt 2009-09-23 14:44:46 UTC (rev 10946)
+++ website/wiki/data/pages/dev/future_plans.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -14,6 +14,7 @@
* [[Notes on porting to Qt4]]
* [[Making a noise by default]]
* [[First Impressions and How to Improve Them]]
+ * [[Device Management and Replacing Auto-Connect]]
===Notation===
Added: website/wiki/data/pages/dev/michael.txt
===================================================================
--- website/wiki/data/pages/dev/michael.txt (rev 0)
+++ website/wiki/data/pages/dev/michael.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,134 @@
+====== 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.
+
+===== Fermata and text marks on rest =====
+I never finished fixing that. I got sidetracked along the way. NotePixmapFactory. Follow the bread crumbs.
+
+===== Debussy harmonics tutorial =====
+
+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.)
+
+===== The repeats tutorial =====
+
+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.
+
+===== Port the documentation to the wiki? =====
+
+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.
+
+===== Raising the bar! =====
+
+'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.)
+
+===== Arbitrary mark directions and other thoughts =====
+
+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"//
+
Added: website/wiki/data/pages/dev/missing_slots.txt
===================================================================
--- website/wiki/data/pages/dev/missing_slots.txt (rev 0)
+++ website/wiki/data/pages/dev/missing_slots.txt 2009-09-23 15:02:36 UTC (rev 10947)
@@ -0,0 +1,105 @@
+====== Missing Slots ======
+We need to investigate all of these and either restore the missing slots or remove the useless cruft calling slots that no longer exist for good reason.
+
+===== NoteRestInserter =====
+
+ * NoteRestInserter::slotNoAccidental()
+ * NoteRestInserter::slotFollowAccidental()
+ * NoteRestInserter::slotSharp()
+ * NoteRestInserter::slotFlat()
+ * NoteRestInserter::slotNatural()
+ * NoteRestInserter::slotDoubleSharp()...
[truncated message content] |