Re: [Denemo-devel] Scripting mode changes

[Richard Shann]

On Fri, 2008-08-22 at 17:20 -0500, Jeremiah Benham wrote:
> 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?
That's a very bad idea! What is great is that I think you have got the
meaning of denemo's internal representation understood. And you
obviously understand another representation (midi), so you should be
able to write simple short functions that translate from one to the
other.  Plus, I guess you understand LilyPond's representation (in the
non-\relative mode that we output from Denemo). (This last is the only
one that I have in my head, cis'' is c-sharp above middle C, or
something like that, 8. is a dotted eight note, possibly in a triplet
etc).

So all we need is functions to call from Scheme to get the note
information of the si->currentobject in some well documented format.
Midi is more widespread than LilyPond, but scroll on down to see my
worry......


>   
> 
> 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
Golden rule - never think about efficiency, think about clarity of code,
ease of use, ease of scripting ... By the time you've finished thinking
about efficiency the latest machines will be ten times faster, but we
humans will be typing at just the same snail's pace.
>  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;
> }notetype;
> 
> While I look at this I notice bugs in importmidi. I will fix them
> tonight.
> 
> > Is c-sharp and d-flat being represented by the same values on entry to
> > this function?
Is this not a crucial question??????????????????
....... so here is my worry - can Midi represent the information we need
to hold? Can you represent a cis,,4. in Midi? And distinguish it from
des,,4.
???
I can write the glue code in and out of scheme (there is a sample,
passing a string from scheme to denemo in the source under #if 0, it
turns out to be quite gruesome involving an old gh-interface, because
they are in transition between the old gh_ stuff and new scm_ stuff).

Assuming the Midi representation can hold the needed information then
if you write something to take the appropriate DenemoWhatever and return
the midi pitch/duration integer/string (whatever will be convenient in
Scheme), I can glue it in (or you can do this bit as well, as I am very
busy with getting the scripts insertable into the menu system as first
class menu items).
Richard


> 
> 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;
> }harmonic;
> 
> 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?
I put this badly - I should have said note: 256 Hz is a pitch, but we
want C-sharp to transpose to something different form D-Flat or
B-double-sharp.
> 
> 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;
> 
This doesn't look like it can do what we want does it?
Richard