]> git.donarmstrong.com Git - lilypond.git/blob - request.hh
release: 0.0.3
[lilypond.git] / request.hh
1 // mpp96's second egg of columbus!
2 #ifndef REQUEST_HH
3 #define REQUEST_HH
4
5 #include "glob.hh"
6 #include "string.hh"
7 #include "mtime.hh"
8 struct Request {
9     Voice_element*elt;
10     enum {
11         UNKNOWN, NOTE, REST, LYRIC, SCRIPT, CHORD, BEAM,
12         BRACKET, STEM, SLUR, CRESC, DECRESC, ABSDYNAMIC
13     } tag;
14
15     Note_req *note();
16     Rest_req *rest();
17     Request(Voice_element*);
18     Request();
19     virtual Real duration() const { return 0.0; }
20 };
21
22 /**
23     Any Voice_element can do a number of requests. A request is done
24     to the #Staff# which contains the #Voice_element#. The staff decides
25     whether to to honor the request, ignore it, or merge it with other
26     requests. Merging of requests is preferably done with other
27     requests done by members of the same voicegroups (beams, brackets, stems) 
28
29     Please refer to the documentation of the Child classes of
30     #Request# for explanation of each request type.
31
32     The result of a request will be an #Item# or a #Spanner#, which
33     will be put on a #PStaff#. Note that the #PStaff# and the original
34     #Staff# need not have anything in common. For example, the
35     ``double'' piano Staff could interpret commands which juggle
36     melodies across the left and right hand, and may put the result in
37     two five-line PStaffs (maybe with extra PStaffs to carry the dynamic
38     signs and any lyric.
39
40     The class #Staff# should be thought as a container for the
41     #Voice#s, and an interpreter for #Request#s and #Command#s.
42     Different staffs can produce different outputs; a melodious voice
43     which is put into a percussion-Staff, will be typeset as the rythm of
44     that voice.
45
46     After #Staff# made up her mind (Would #Staff# be a smart
47     name? How about #struct Lily {}# :-), the resultant items and
48     spanners are put on the PScore, and pointers to these items are
49     stored in the #Voice_element#. This construction enables the
50     beams/stems to look up the balls it has to connect to.  */
51         
52
53     
54 /// Put a note of specified type, height, and with accidental on the staff.
55 struct Note_req : Request {
56     char name;
57     int octave;
58     int accidental;
59     bool forceacc;
60     int balltype;
61     int dots;
62     
63     Real duration() const;
64     Note_req(Voice_element*v);
65 };
66 /**
67 Staff has to decide if the ball should be hanging left or right. This
68 influences the horizontal dimensions of a column, and this  is why
69 request processing should be done before horizontal spacing.
70
71 Other voices' frivolities may cause the need for accidentals, so this
72 is also for the Staff to decide. The Staff can decide on positioning
73 based on ottava commands and the appropriate clef.
74 */
75
76 ///Put a lyric above or below (?) this staff.
77 struct Lyric_req : Request {
78     String text;
79 };
80
81
82 ///Put a script above or below this ``note''    
83 struct Script_req : Request {
84     int orientation;
85     Symbol *sym;
86 };
87 /**
88 eg upbow, downbow. Why a request? These symbols may conflict with slurs and brackets, so this
89 also a request
90 */
91
92
93 ///Put a rest on the staff.
94 struct Rest_req : Request {
95     int balltype;
96     int dots;
97     Rest_req(Voice_element*);
98     Real duration() const;
99 };
100 /**
101 Why a request? It might be a good idea to not typeset the rest, if the paper is too crowded.
102 */
103
104
105
106 ///Draw a (Guitar) chord above or below this ``note''
107 struct Chord : Request {
108         // don't know how this looks.
109 };
110 /**
111 Why a request?
112 Because everything else is done in requests.
113 */
114
115
116 /// for absolute dynamics
117 enum Loudness {
118     FFF, FF, F, MF, MP, P, PP, PPP
119 } ;
120
121 /// attach a stem to the noteball
122 struct Stem_req : Request {
123     /// 4,8,16, ..
124     int stem_number ;
125 };
126 /// requests to start or stop something.
127 struct Span_req : Request {
128     /// should the spanner start or stop, or is it unwanted?
129     enum {
130         NOSPAN, START, STOP
131     } spantype ;
132 };
133 /**
134  This type of request typically results in the creation of a #Spanner#
135 */
136
137
138 ///Start / stop a beam at this note.
139 struct Beam_req : Span_req {
140     int nplet;
141 };
142 /** Staff will have to combine this with the stem_request, since the
143     number of flags that a stem wants to carry will determine the
144     number of beams.  if #nplet# is set, the staff will try to put an
145     appropriate number over the beam
146
147     [what to do  if the nplet fields of start and stop conflict?]
148     */
149
150 ///Start / stop a slur or a bracket.
151 struct Bracket_req : Span_req {
152     int nplet;
153 };
154 /**
155 Start/stop a bracket at this note. if #nplet# is set, the staff will
156 try to put an appropriate number over the bracket
157 */
158
159 /// a slur
160 struct Slur_req : Span_req {
161     
162 };
163
164 /// helper in the hierarchy
165 struct Dynamic {
166     Mtime subtime;
167 };
168 /** Each dynamic is bound to one note ( a crescendo spanning multiple
169     notes is thought to be made of two "dynamics": a start and a stop).
170     Dynamic changes can occur in a smaller time than the length of its
171     note, therefore fore each Dynamic request carries a time, measured
172     from the start of its note.
173
174     This subfield would come in handy, if mpp96 was adapted for midi
175     support.
176     
177     Dynamic should have been derived from request, but I don't want to
178     fuss with virtual baseclasses.  */
179
180 /// do a crescendo
181 struct Cresc_req : Span_req, Dynamic {
182     
183 };
184
185 /// do a decrescendo
186 struct Decresc_req : Span_req, Dynamic {
187     
188 };
189
190 /// do a dynamic like "fff" or "mp"
191 struct Absdynamic_req : Request, Dynamic {
192         Loudness loudness;
193 };
194
195 #endif