From d4b00db0f577d2c2227f2b5085aac4117137a5b4 Mon Sep 17 00:00:00 2001 From: fred Date: Sun, 15 Sep 1996 14:59:17 +0000 Subject: [PATCH] lilypond-0.0.1 --- request.hh | 195 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 195 insertions(+) create mode 100644 request.hh diff --git a/request.hh b/request.hh new file mode 100644 index 0000000000..0cd0fe0903 --- /dev/null +++ b/request.hh @@ -0,0 +1,195 @@ +// mpp96's second egg of columbus! +#ifndef REQUEST_HH +#define REQUEST_HH + +#include "glob.hh" +#include "string.hh" +#include "mtime.hh" +struct Request { + Voice_element*elt; + enum { + UNKNOWN, NOTE, REST, LYRIC, SCRIPT, CHORD, BEAM, + BRACKET, STEM, SLUR, CRESC, DECRESC, ABSDYNAMIC + } tag; + + Note_req *note(); + Rest_req *rest(); + Request(Voice_element*); + Request(); + virtual Real duration() const { return 0.0; } +}; + +/** + Any Voice_element can do a number of requests. A request is done + to the #Staff# which contains the #Voice_element#. The staff decides + whether to to honor the request, ignore it, or merge it with other + requests. Merging of requests is preferably done with other + requests done by members of the same voicegroups (beams, brackets, stems) + + Please refer to the documentation of the Child classes of + #Request# for explanation of each request type. + + The result of a request will be an #Item# or a #Spanner#, which + will be put on a #PStaff#. Note that the #PStaff# and the original + #Staff# need not have anything in common. For example, the + ``double'' piano Staff could interpret commands which juggle + melodies across the left and right hand, and may put the result in + two five-line PStaffs (maybe with extra PStaffs to carry the dynamic + signs and any lyric. + + The class #Staff# should be thought as a container for the + #Voice#s, and an interpreter for #Request#s and #Command#s. + Different staffs can produce different outputs; a melodious voice + which is put into a percussion-Staff, will be typeset as the rythm of + that voice. + + After #Staff# made up her mind (Would #Staff# be a smart + name? How about #struct Lily {}# :-), the resultant items and + spanners are put on the PScore, and pointers to these items are + stored in the #Voice_element#. This construction enables the + beams/stems to look up the balls it has to connect to. */ + + + +/// Put a note of specified type, height, and with accidental on the staff. +struct Note_req : Request { + char name; + int octave; + int accidental; + bool forceacc; + int balltype; + int dots; + + Real duration() const; + Note_req(Voice_element*v); +}; +/** +Staff has to decide if the ball should be hanging left or right. This +influences the horizontal dimensions of a column, and this is why +request processing should be done before horizontal spacing. + +Other voices' frivolities may cause the need for accidentals, so this +is also for the Staff to decide. The Staff can decide on positioning +based on ottava commands and the appropriate clef. +*/ + +///Put a lyric above or below (?) this staff. +struct Lyric_req : Request { + String text; +}; + + +///Put a script above or below this ``note'' +struct Script_req : Request { + int orientation; + Symbol *sym; +}; +/** +eg upbow, downbow. Why a request? These symbols may conflict with slurs and brackets, so this +also a request +*/ + + +///Put a rest on the staff. +struct Rest_req : Request { + int balltype; + int dots; + Rest_req(Voice_element*); + Real duration() const; +}; +/** +Why a request? It might be a good idea to not typeset the rest, if the paper is too crowded. +*/ + + + +///Draw a (Guitar) chord above or below this ``note'' +struct Chord : Request { + // don't know how this looks. +}; +/** +Why a request? +Because everything else is done in requests. +*/ + + +/// for absolute dynamics +enum Loudness { + FFF, FF, F, MF, MP, P, PP, PPP +} ; + +/// attach a stem to the noteball +struct Stem_req : Request { + /// 4,8,16, .. + int stem_number ; +}; +/// requests to start or stop something. +struct Span_req : Request { + /// should the spanner start or stop, or is it unwanted? + enum { + NOSPAN, START, STOP + } spantype ; +}; +/** + This type of request typically results in the creation of a #Spanner# +*/ + + +///Start / stop a beam at this note. +struct Beam_req : Span_req { + int nplet; +}; +/** Staff will have to combine this with the stem_request, since the + number of flags that a stem wants to carry will determine the + number of beams. if #nplet# is set, the staff will try to put an + appropriate number over the beam + + [what to do if the nplet fields of start and stop conflict?] + */ + +///Start / stop a slur or a bracket. +struct Bracket_req : Span_req { + int nplet; +}; +/** +Start/stop a bracket at this note. if #nplet# is set, the staff will +try to put an appropriate number over the bracket +*/ + +/// a slur +struct Slur_req : Span_req { + +}; + +/// helper in the hierarchy +struct Dynamic { + Mtime subtime; +}; +/** Each dynamic is bound to one note ( a crescendo spanning multiple + notes is thought to be made of two "dynamics": a start and a stop). + Dynamic changes can occur in a smaller time than the length of its + note, therefore fore each Dynamic request carries a time, measured + from the start of its note. + + This subfield would come in handy, if mpp96 was adapted for midi + support. + + Dynamic should have been derived from request, but I don't want to + fuss with virtual baseclasses. */ + +/// do a crescendo +struct Cresc_req : Span_req, Dynamic { + +}; + +/// do a decrescendo +struct Decresc_req : Span_req, Dynamic { + +}; + +/// do a dynamic like "fff" or "mp" +struct Absdynamic_req : Request, Dynamic { + Loudness loudness; +}; + +#endif -- 2.39.5