On Wednesday 01 August 2007 17:50, Chris Cannam wrote:
> Possibly, yeah. Perhaps it's better to resolve the question of how
> voices should be supported first, then. Looks like we're getting back
> into the "big plan" stuff with a vengeance.
It does seem that we can't get around the "big plan" stuff. I think we're
getting close to something workable though.
> If we take the premise that separate voices on the same staff may want
> to use different MIDI programs or play through different devices, it
> follows that separate voices have to occupy separate tracks, or else
> editing them in a "MIDI sequencer" is going to be appallingly hard work
> (and I really don't think it would be a good idea to start messing
> about with the MIDI sequencer interface to make it work). But is that
> premise valid, or would it be reasonable to always insist that separate
> voices in the same staff play with identical MIDI channel and program?
To do tablature correctly requires at least 2 MIDI channels per staff at
times. (e.g. Hold one note and bend another. This is actually required for
std notation that allows for bends. This is such a common thing with guitar
that I'll call it GtrLick1.)
What I don't like is the thought of having GtrLick1 appearing on 2 Tracks in
TrackEditor. It's unintuitive from a musical perspective and would be a
hassle from a user perspective.
I have some knowledge of MIDI and MIDI files, but I don't know much about the
RG sequencer in particular. PowerTab outputs to MIDI in the "ugly" way.
GtrLick1 would appear on 2 tracks in a MIDI file. Is the RG sequencer limited
to handling things this way? Cakewalk doesn't output to MIDI that way. A
track may consist of multiple MIIDI channels and can have program changes.
Most MIDI files you find on the net are done this way.
My point is that if GtrLick1 must appear as 2 tracks in TrackView, then the
user is forced to deal with tracks as something more "raw" than what's found
in a MIDI file. Is that what we want? If the answer is yes, then I would
suggest the current TrackView be called RawTrackView or something and have a
more "normal" or higher-level TrackView (one in which GtrLick1 appears in a
single rectangle) available to the user.
> > Question 3: If we have 1 voice per track, what do we call the Thingy
> > that encapsulates a group of tracks for display as an atomic unit in
> > a notation view.
>
> Staff.
So you want to rename the current class we call Staff to StaffSegment or
something? I'm all for that.
My next iteration:
1 voice per Segment
1 voice per Track
Composition owns a list of Scores.
class Score
{
list<ScorePart*> m_staffs;
string m_label;
};
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;
};
ScorePart represents one unit in a musical score (e.g. the flute part on a
StdStaff, or the piano on a GrandStaff).
ScorePart could have a couple of constructors to give the user different
levels of control. The simplest would be
ScorePart(list<Track*> trkList, StaffType type, TablatureTuning tabTuning);
The first track is mapped to voice 0, the second to voice 1, etc. On a
StdStaff, even voices get stem-up, odd stem-down. For a GrandStaff voice 0 is
top part stem-up, voice 1 top part stem-down, voice 2 bottom part stem-up,
and voice 3 bottom part stem-down.
The user configures the Score in a (tabbed) dialog. NotationView has acces to
Score. If opened by selecting a bunch of segments in TrackEditor followed
by "Open in Notation View", a new score is created using sensible defaults.
When the view is closed, user can save the Score or just let it be deleted.
Scores get saved in the .rg file. We could do templates and all sorts of
convenience stuff later.
-------------------------------------------------------------------------
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
