On Saturday 04 August 2007 13:27, Chris Cannam wrote:
> > My next iteration:
> > 1 voice per Segment
> > 1 voice per Track
> > Composition owns a list of Scores.
>
> As well as the existing list of tracks (i.e. in my mind at least, the
> main sequencer view would not necessarily change much -- the score
> management views/dialogs would be elsewhere).
You mean "Composition owns a list of Tracks"? I don't see any reason to change
that. I was thinking of ScoreView as a window opening from a menu or toolbar
button or something, pretty much leaving all current track view stuff alone.
> > class ScorePart
> > {
> > StaffType m_staffType; // StdStaff, GrandStaff, StdTabStaff, etc.
> > TablatureTuning m_tabTuning;
> > map<Segment*, int> m_segmentVoiceMap; // <segment, voice>
> > map<int, int> m_voiceSubstaffMap; // <voice, substaff>
> > string m_label;
> > };
>
> I'm not sure that it's necessary to identify voices directly. Rather
> than saying "this segment is voice 0" and defaulting to "voice 0 is
> stem-up on the top staff", why not say "this segment is stem-up on the
> top staff"? You can always derive voice numbers from this when you
> render it all, assuming you need them for user interaction purposes,
> and they'll be consistent between renderings. For identifying voices
> to the user, the segment names are now perfectly acceptable as each
> segment contains material from only a single voice.
I'll have to think about this. I have to sit down and work it out on paper.
> > Scores get saved in the .rg file. We could do templates and all sorts
> > of convenience stuff later.
>
> Yes, yes and yes. Also, when printing to Lilypond or wherever from the
> main view, you could choose one of the set of known scores (or
> just "everything arranged per default") to print out.
Yes, once the mechanism is set up, printing or exporting to Lilypond should
follow without too much trouble.
I think I can come up with at least the basics of score layout. I think I'm
going to start with the underlying code rather than a user interface (i.e.
ScoreView waits till later). My use case:
User selects a bunch of Segments in TrackEditor and right clicks on "Open in
Notation View".
NotationView will create a default Score from the selected Segments.
NotationView also creates a list of Staffs. The Staffs create StaffSegments.
Each Staff is passed a font name and size to create its own
NotePixmapFactory. Each Staff also needs its own StaffHLayout and
StaffVLayout (to scan the staff, position chords, etc.). NotationView creates
a ViewHLayout and ViewVLayout (possibly combined into a single class?) which
take care of reconciling the staffs. I have prototype code laying around
somewhere, which does something like this and allows for multiple staff types
in the same view.
A Staff consists of a single set of lines. The Score should hold the logic of
combining staffs into a grand staff or std tablature. ViewHLayout and
ViewVLayout should have access to Score so that connecting lines and such can
be added.
Sound reasonable?
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Rosegarden-devel mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
