denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] dynamics


From: Jeremiah Benham
Subject: Re: [Denemo-devel] dynamics
Date: Wed, 25 Mar 2009 21:18:52 -0500

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...

> 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. 

> > 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. 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. The fermata can have
an int argument to control length. 

> > 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). 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.  

> 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. 
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.  

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]