Design Notes

One big page for all design notes
Older notes, some of which document now-implemented features are linked to from http://www.old.denemo.org/index.php?title=Roadmap

Source Links
We have had point and click for some time - you click with the mouse on an object in the final typeset score (in the print preview window) and the Denemo cursor is moved to that note in that staff in that movement.

What this technology will also allow is placing references to source manuscripts, facsimiles at points in the Denemo score. At present we can store snapshots of a original source manuscript of the music with the measures. This requires quite a bit of storage and is done for the whole of the piece.
Instead, we will be able to place "links" to the manuscript which when clicked on will open the pdf at the given location (highlighted) so that the editorial process can be easily reviewed. The links can be inserted by the inverse process, clicking on the pdf at the point we are about to transcribe will insert the link, as well as giving a marker in the source pdf to show where we are.
The source manuscripts/facsimiles would be displayed in a different window from the print preview window, of course, but most of the programming is the same - just more evince widgets and some filechooser to load them up.

Audio Score Mixer

When transcribing a piece from audio (e.g. an ogg or mp3 file) it would be nice to be able to do the work with the audio linked to the score. So, for example, one could write a chordal accompaniment and playback the original audio and the denemo-generated MIDI. The key to doing this is synchronizing Denemo's playback with the audio (which is assumed to be real (human) music whose tempo will vary slightly.

This synchronization is possible with the control Denemo has over the live playback of a score (see e.g. the Conductor feature in the playback controls). What else is needed is a means of reading an audio source and playing it back with a Denemo score. In principle the libaubio could provide beat information, but I suspect this is a research topic. What would be very practical would be for the user to input the beats by pressing the space bar while the audio is playing, which would give Denemo a basic rhythm track which it would use for subsequent playback.

The simplest use would then be to write the proposed transcription in Denemo and when playing back any discrepancies would be easily audible. With this in place it should be also possible to play in via MIDI controller during playback - so you could play along with the original audio with a MIDI recording being made of your contribution. Then a scheme script (like the current Record and Convert script could be used to covert to notation.

To implement this libsndfile could be used to open the audio original. Also of interest would be librubberband to change the tempo of the incoming audio.

Spanners in Denemo

We need to protect our users against trying to print or play files with incomplete "spanners". "Spanners" are things that span notes (such as start repeat section end repeat section, start tuplet end tuplet, start cresc end cresc...). We might extend the concept to things that span 'vertically' such as start piano staff end piano staff.

The sort of operations a user can do to damage a spanner is to delete the start or end object (possibly a note with directive attached), to delete an object enclosed in a span, to cut a range of objects including one end of a span. To paste back such a cut, possibly now enclosing more objects, possibly now with the end span pasted before the start span.

The simplest thing would be to run a check before typesetting or midi-creation. Such a check routine would need updating every time a new sort of spanner was introduced by scripters.

Better would be some spanner support. Simplest would be some convention for tags that indicate if the directive is the start or end of a spanner. (And then more elaborate schemes such as might be used for repeat, first time, second time constructions). Again these would be used by a check routine, but now a new sort of spanner could automatically be checked by creating its directives following the convention.
Better still - but needing some real design work - would be a flag to mark DenemoObjects as being involved in a spanner. These would trigger a callback to when something happened to the object. The callback could be the original command used to create the spanner with a parameter so say what was being done. So the one script handles both creation and what to do on deletion. Handling what to do on object creation (extra objects within the span) would also be possible - but it could become difficult to avoid a performance hit without building elaborate indexes (where spans start and end).
With some support it would be possible for the callback to indicate if it was d-Cut or d-DeleteObject that was causing the deletion. How that information could be used is moot.

Facsimile Mixer - This has been implemented.

When working from a source score in facsimile making a transcription
a good way to associate the source score more directly with the transcription would be as follows:
Each measure would have
attached to it the measure of music it transcribes. It would make the transcription process easier, as the source material
would be presented next to your transcription.
This would have another merit - a user could consult the original material if they
doubted your editorial decision.

So in this scheme you would first of all go through the original print
dragging a box over each measure - each time you clicked a measure would
be created in Denemo with the image of the measure the user has outlined
attached.
Then, when playing a measure in, the original would be visible
immediately below the current measure.

There is a parallel here with the audio
score mixer above. In each case I envisage the user dividing the original up into measures and
then adding stuff in Denemo that corresponds to the original, be it an
accompaniment or a transcription.
Here are some snippets of code for the gtk-screenshot program that would be needed for this:

screenshot_select_area (int *px,
int *py,
int *pwidth,
int *pheight)

screenshot = screenshot_get_pixbuf (window, rectangle, include_pointer, FALSE);

job->window = find_current_window (&window_title);

find_current_window (char **window_title)
window = gdk_get_default_root_window ();
tmp = screenshot_get_window_title (window);

gdk_pixbuf_save_to_buffer ()

We are currently using xml to save denemo scores, this would be a verbose way of storing the pixbufs, even when converted to .png using the above call.