Re: [Denemo-devel] dynamics

[Richard Shann]

On Wed, 2009-03-25 at 21:18 -0500, Jeremiah Benham wrote:
> On Wed, 2009-03-25 at 17:21 +0000, Richard Shann wrote:
> 
> > > I am thinking: 
> > > 
> > > volume settings like piano, forte, accents, etc...
> > So what represents these in MIDI? A 0-255 value? 
> 
> Volume or velocity is a value from 0-127. I figured accents would apply
> only to the individual note. Forte would apply until the dynamic volume
> was changed.  
> 
> > What distinguishes an
> > accent from a forte? 
> 
> The string that is passed via the directive to exportmidi.c. Forte
> applies until the dynamic is changed. An accent only to that note. The
> dynamics can come with an integer if you think the user will want to set
> values for forte piano etc...
I see: exportmidi is going to calculate velocity values for each note
(as in MIDI in from the keyboard), and the indications forte, accent,
cresc...endcresc are indicating what velocity value to use on each note
that the effect applies to.

> 
> > The question is how many fields do we need to pass
> > all the information we would want MIDI to respond to, and what should
> > they be called.
> 
> I am thinking at most a GString and 3 int values. 
I presume you mention a GString because a dynamic at the moment stores
something like "ff" or "mp" and exportmidi interprets that. Instead I
suggest we store directly the information the exportmidi needs. This
means that someone could write a script to create a DenemoDirective that
displayed mp put mf into the LilyPond and made the velocity output by
exportmidi to be 0, there would be nothing to prevent this, only good
sense. So the graphic to display (or display text) and the LilyPond and
the MIDI effects will all be settable independently, and it will be the
menuitem, via a script that will set them to consistent values.

> 
> > > note length settings like staccato, marcato, fermata, Tenuto, etc...
> > again would this be an single int value, what would the semantic be - a
> > value relative to the written duration ...
> 
> Yes so marcato would be about 2/3 of the normal time.
This means we could write a script that says (for example)

(d-DirectivePut-chord-postfix "Duration" "\\marcato")
(d-DirectivePut-chord-duration "Duration" 33)
...

where 33 is the percentage shortening of the duration of a note that
MIDI should give (meaning 1/3 shorter than normal).

>  The rest of the
> time would be filled with rest. Exportmidi should take care of padding
> with rests and reducing the length of the note.  Tenuto and fermata
> should give a little extra time to the note. Tenuto would have to
> somehow subtract time from other notes. I think we can easily get very
> complicated trying to recreate a human performance. 
Yes, we want to provide simple tools. Tenuto, for example, is an
ambiguous indication: the script writer can provide a more than one
tenuto command with different MIDI meanings. Tenuto in normal western
notation can mean full-duration note (notes are typically slightly
short) and/or an accented note - either a higher volume(velocity)
combined with shorter length or a note that starts louder and drops in
volume quicker than the regular note (an accented note). 
 We just need to create simple MIDI control over duration of notes,
volume and (I gather from an earlier email) possibly some sort of XXX
switching, where XXX is something that I don't know about, but I suspect
is to give the note a different characteristic, e.g. a different attack
etc - this is something I really know nothing about... someone wrote
about mcha-mcha...???

> The fermata can have
> an int argument to control length. 
I guess this will be a global tempo change for the duration of the note
- I guess we will want to place it like the fermata sign on every note
that is being simultaneously sounded (some of the parts will be moving
while others have already reached their fermata sign).

> 
> > > Pitch settings like tuning system, portamento, glissando, vibrato 
> > tuning system sounds like per Voice rather than per note?
> > What would be needed to describe a gliss?
> 
> I think if a glissando is created up/down to a note then it is going to
> need a starting pitch. So I would say a String and integer (to define
> the starting pitch).
The starting/ending pitches are defined by the denemo notes between
which the gliss is placed. We will need (perhaps later?) to install
something into the DenemoDirective that exportmidi will be able to
interpret as a gliss command (that is, I don't think we should use the
GStrings that control the display or the LilyPond etc to communicate
with MIDI). In any case, we should leave this out for now.


>  This would describe a note glissando up/down to a
> note that treated more like a grace note. We could also have two quarter
> note that glissando from one to another. This would require a string
> argument and perhaps int of NULL to let exportmidi.c that it is not a
> grace note. 
> 
> Portamento can have two integer describing the value note is bent or
> changed and the speed in which it was changed. There is a special midi
> signal to send out for portamento but exportmidi can cover that.  
Let's leave this for later


> 
> > No, we only need one to get the system worked out. We need a (hopefully
> > standardized) representation of the things we will want the exportmidi.c
> > code to slurp up off of the CHORD structures as it passes over them. So
> > if MIDI uses a 0-255 volume indicator and we want to represent a change
> > from one volume to another in so many time steps (what would the units
> > be?) we might want, I don't know, three ints, or perhaps there is some
> > packing that is done in some standard encoding that we could use...
> 
> The string and three ints sounds right to me. 
> 
> > > Yes. tempo changes and all the things mentioned above. 
> > Would tempo change be a field called, say, bpm representing the number
> > of quarter notes per minute - is an integer good enough? 
> 
> I think putting an integer tempo change event should be enough. Midi has
> tempo change as an event and the values look like this:
> 
> 255 (0xFF) 81 (0x51) 3 0-8355711
> 
> 0xFF (meta event)  81 (event type) 3 (no of bytes data takes up)
> 0-8355711 (microseconds per quarter-note)
> > I am guessing
> > that this value is internal to the exportmidi.c code - the MIDI output
> > values just reflect the tempo changes in the different timings that
> > exportmidi.c assigns to the note? 
> 
> just giving me an integer bpm is good enough here. 
I haven't done the math - does an integer number of bpm allow fine tempo
control over a sensible range of quarter-note durations?


> String="Tempo"
> int = 60
> 
> > In which case, what we should store is
> > the value as used by exportmidi.c unless it's very obscure and the
> > script writer will find it easier to write something that will be
> > converted to the internal thing used by exportmidi.c 
> > 
> > Once you have a set of names and their meanings you can create fields in
> > the structure DenemoDirective to hold them, and start writing code in
> > exportmidi.c to extract them and act on them.
> > I'll implement them so that, for example, 
> > (d-Directive-put-chord-<yourfieldname> "Dynamic" 50)
> > will set the directive->yourfieldname to the value 50.
> 
> So would this value 50 also have a "mf" that appears on the screen that
> shows up in the final printed pdf or does the user enter that dynamic
> marking separately.  
I hope I have explained well enough above, but just to re-iterate
the value 50 is the choice of the writer of the script as is the choice
of displaying say mf on the screen and the choice of outputting /mf in
the LilyPond.
We will ship Denemo with a set of common dynamic signs (==menuitems that
invoke scripts) and there will be a set of values stored in scripts as
well as graphics displaying them and LilyPond text to print them. Users
can modify them for their own taste, as well as creating new ones. We
can concentrate for the moment on creating one or two sample scripts to
see how everything will work - we will be able to use common editing
scripts to edit the volume field for instance, and so on. Once we have
something better than what is currently there we can drop the old code.

So far I think we have established that we need

gint volume;
gint duration;
gint tempo;

but we have not established how we say to exportmidi that this volume
change is the start of a cresc, or that it is a one off applied to just
this note (specifically I don't think we should leave it to scripts to
write a series of volume changes onto successive notes so as to define a
cresc. Editing would be a nightmare).
I think we should introduce a field

GString *partner;

where partner is the tag of another DenemoDirective, which this one
requires to make sense. Which direction the partner is in (before or
after the current DenemoDirective) depends on the semantic of the
current DenemoDirective, so for example a "Cresc" has the partner field
set to "EndCresc" and a directive with this tag has to be found later in
the music for the Directive to make sense. Exportmidi will go in search
of this second directive and if found generate a set of volume values to
fill in between the two values given in the Directives.
There is the question of how exportmidi knows which way to search -
there is an elegant solution exploiting the .scm files, but perhaps we
should keep it simple: if partner is non-NULL then a otherwise unused
bit in the volume can be set to indicate whether this is the start or
end of the volume event. This bit will be set by the script that is
setting the volume in the first place - a Cresc script for example.

In fact, using two bits for this we can do all the cases, calling the
two bit fields START and END we have

START == 1
END == 0
partner==NULL
means step change in volume

START == 1
END == 0
partner==non-NULL
means volume is increasing or decreasing until following DenemoDirective
with tag partner->str

START == 1
END == 1
partner==NULL
means change volume just for this note.

START == 0
END == 1
partner==non-NULL
means volume is increasing or decreasing until previous DenemoDirective
with tag partner->str

These searches could also detect an intervening DenemoDirective whose
tag is our own tag (meaning we have a start or end missing and we have
reached the partner of some other pair).

Similar design should apply to the other start/end cases...

Richard


> 
> Thanks,
> Jeremiah
> 
> > 
> > whereupon your code in exportmidi.c will do something with that value,
> > and the user will hear fortissimo or whatever...
> > 
> > Richard
> > 
> > 
> > 
> > > Jeremiah
> > > 
> > > > Richard
> > > > 
> > > > 
> > > > On Wed, 2009-03-25 at 08:29 -0500, Jeremiah Benham wrote:
> > > > > On Wed, 2009-03-25 at 09:44 +0000, Richard Shann wrote:
> > > > > > On Tue, 2009-03-24 at 15:00 +0000, Richard Shann wrote:
> > > > > > > I don't know what exactly you would be storing as MIDI 
> > > > > > > information, it
> > > > > > > would be a good idea to bounce the possible fields and their names
> > > > > > > back
> > > > > > > and forth a bit. 
> > > > > > Also we will need to coordinate changes, as I am currently working
> > > > > > through adding the keysig directives and timesig directives. I 
> > > > > > could do
> > > > > > adding the MIDI fields to the DenemoDirective structure (and then 
> > > > > > the
> > > > > > code for them in view.c, imp/exportxml.c lilydirectives.c), while
> > > > > > Jeremiah could add the actions to take in exportmidi.c
> > > > > 
> > > > > Ok. This sounds good. I will need you to point me to an example 
> > > > > because
> > > > > I am very behind on this directive stuff.
> > > > > 
> > > > > Jeremiah
> > > > > 
> > > > > 
> > > > > > Richard
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > Denemo-devel mailing list
> > > > > > address@hidden
> > > > > > http://lists.gnu.org/mailman/listinfo/denemo-devel
> > > > > 
> > > > 
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/denemo-devel
>