[Top][All Lists]

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

Re: [Denemo-devel] Scripting mode changes

From: Jeremiah Benham
Subject: Re: [Denemo-devel] Scripting mode changes
Date: Fri, 22 Aug 2008 17:20:56 -0500

On Fri, 2008-08-22 at 20:36 +0100, Richard Shann wrote:

> > enternote_function(gint *pitch, duration)
> What is the value of pitch for middle c and for any other note?

for this planned function enternote_function()  pitch is actually the
midi note number. So middle c would be 60. c# would be 61. b would be
59. etc ... It would probably be more efficient if denemo stored notes
as midi note numbers instead of (scale_degree, accidental). The scale
degree and accidentals should be done only for drawing the display and
exporting lilypond but I don't see a need for denemo to store the notes
the way it does. I am willing to do the work on changing it if you don't
see a good reason opposing this idea. What do you think?  

By the way we should name enternote_function something different.

> What is the value of duration for a quarter note? and any other?

notes are entered as note_types:
0 = whole
1 = half
2 = quarter note
3 = eigth
4 = sixteenth
etc ...

In the function 
DenemoObject * dnm_newchord (gint baseduration, gint numdots, int tied)
baseduration = note_type
numdots is the number of dots on the note
tied is if this note overflows unto the next measure. 

For many purposes I think we would need something that would calculate
the base duration, num dots and tied value automatically. 
I wonder if it would also be more efficient to store duration values in
midi tick numbers like this:
384 = quarter 
192 = eigth
etc ...

Storing values in this way would make quantization and rebeaming a
breeze. Since note objects are essentially just a list of duration such
as 384. We could change the values inserting objects in between note
that do not fit in a measure. The rebeaming function could redraw based
off the updated list data.  In this way it would be incredibly easy to
change a piece composed in 4/4 to 3/4  or 2/4 to 6/8. Also rhythmic
diminution and augmentation would be a breeze.     

I believe it would be nicer to switch to this format and let do draw
routines convert it to note_type values using the function 

notetype ConvertLength(gint endnote, midicallback *mididata)

notetype is this:

typedef struct notetype {        
        gint notetype;
        gint dots;
        gint tied;

While I look at this I notice bugs in importmidi. I will fix them

> Is c-sharp and d-flat being represented by the same values on entry to
> this function?

I was thinking having it be midi note numbers. We could have a separate
function that wrapper function to accept different types of input like
similar to the above struct notetype and sturct harmonic if users
wished. Harmonic is defined as :

typedef struct harmonic
        gint pitch;
        gint enshift;

pitch values equate to this:
local.pitch = (input / 12) - 5;

input is the midi note number value. 60 = middle c etc.....
local.pitch for middle c would be 0. b would be -1. 

> Given a pitch can we calculate pitch + minor 3rd?

If we switch to storing pitches in midi numbers a minor third would be
extremely simple to perform.

int interval = 3; //half steps in minor third
int notepitch = 60;
notepitch += interval;

> do you see what I am getting at? It may be very simple, but I don't feel
> I've ever got to grips with it.

Its not simple at all. I recommend we simplify it for next release. I
will fix some of these bugs in importmidi later tonight. Many of these
functions can be reused for this simplification. 


> Richard

reply via email to

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