denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] dynamics


From: Richard Shann
Subject: Re: [Denemo-devel] dynamics
Date: Tue, 24 Mar 2009 15:00:30 +0000

On Mon, 2009-03-23 at 14:12 -0500, Jeremiah Benham wrote:
> I noticed in the code of exportmidi that it acts as if dynamics are an
> object. 
I pointed this out in an email a couple of months back, when Nils
mentioned that dynamics were not affecting midi.

> It scans through the list of objects with a switch. One case is
> for dynamic objects but dynamics looks as if it was being transitioning
> between being an object <<->> to a chord property. I am not sure in what
> direction they were going with that. 
I don't know which way someone was changing the code, but they only got
half way, and I believe both lots of code have bugs.
> denemo_types.h also suggest that
> dynamics are object inserts. I also noticed in denemo_objects.h it is
> clear that dyamics are a GList of strings attached to note. It is
> defined in the chord structure. I think we need to decide if we want to
> have dynamics a denemo object or having it be a property of the chord
> objects. Then delete all code is the antagonist.  What would be the
> benefits of each? 
I suggest doing no more work on either of those (and removing them as
soon as we have something better in the menu system). What we should do
is create menu items that create DenemoDirectives
(d-DirectivePut-chord-postfix "dynamic" "<lilypond code for a dynamic>"
etc.
These will put the dynamic signs (we can use the real graphics that
LilyPond generates, positioned beneath the notes of the chord), and add
some MIDI information for the MIDI loop you mention to be picked up as
the MIDI out passes through the case CHORD:
This would allow people to add more dynamic indications (there are
zillions of possible markings, from poco piu f to sehr ruhig) with their
own MIDI interpretations.

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. The names are quite important since they appear in the
scripts, d-DirectivePut-chord-midivol for midivol for example. We can
syntactically sugar them, but it will be nice to get them right first
time.

This is better than persisting and fixing either of the two built-in
schemes for dynamics, because it allows better display and better MIDI
interpretations to be developed without generating new releases of
Denemo. And by re-using the DenemoDirective code we cut down on the code
maintainance - as I say, I believe both dynamics systems are currently
broken in different ways.

Attaching Dynamics to chords does not mean we cannot have Dynamics as
denemo objects if we wanted: We could generate the same directives as
standalone DenemoDirective objects (picked up in the case LILYDIRECTIVE:
of the switch in that MIDI loop). This would let people cut/paste/delete
dynamics using backspace, and delete a chord without deleting the
dynamic. We might need to play around with the possibilities to decide.
The good thing is we are not hard-wiring a choice into the executable.

Richard


> 
> Jeremiah
> 
> 
> 
> _______________________________________________
> 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]