[Top][All Lists]

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

Re: [Denemo-devel] Linking smf events to Denemo objects

From: Jeremiah Benham
Subject: Re: [Denemo-devel] Linking smf events to Denemo objects
Date: Tue, 19 May 2009 14:41:54 -0500

On May 19, 2009, at 10:34 AM, Richard Shann <address@hidden> wrote:

On Mon, 2009-05-18 at 17:37 -0500, Jeremiah Benham wrote:
On Mon, May 18, 2009 at 06:24:57PM +0100, Richard Shann wrote:
I have been having a look at the MIDI stuff. For immediate playback I was wondering whether the smf data structures could be used directly.
Each DenemoObject could have a pointer which would either be NULL or
point to an smf_event_t.

You might want to create the smf_event_ts along with the DenemoObject
insertion, or postpone it until a play request is made (if it slowed
down Denemo too much).

Does this sound reasonable?

I believe you can do this. Read smf.h line 131.
line 131 was in the middle of a comment. But anyway, having read around
in this file I wonder if you can bring me up to speed on how Denemo is
using MIDI?

Importmidi.c is reading midi files. Exportmidi.c is exporting them. Then I know we now have a jackmidi and the OSS midi input stuff. There is some remnants still around from an atempt to add Alda midi in/out also. I am not sure were that code is at.

My reading of exportmidi.c is that each staff is given a track and then
a channel is chosen (by this crufty-looking piece of code)
     if (!strcmp (curstaffstruct->midi_instrument->str, "drums"))
     midi_channel = 9;
midi_channel = (tracknumber >= 9) ? tracknumber + 1 : tracknumber;
and this is not changed during the rest of the output.
What program change would be/mean I am quite unclear.

I would have to look this up. I think it has to do with the midi patch to use. #1 may be piano, #2 could be bright piano. I think it depends on what it is mapped to. I may be wrong so IIRC.

It looks to me like we could overhaul exportmidi.c changing all the
places where it writes to the output file to be calls to the smf
library, creating smf_event_t s inserting them into the si->smf and
putting a pointer to the smf_event_t in the DenemoObject. Writing to an
output file would then be a single smf library call, and playing could
be started at any point by going to the smf_event_t attached to the
current object and doing the smf library next call. (There would be one
smf structure attached to each DenemoScore object, ie movement or
"song", this is what I have called si->smf above).

For an initial version of the code, we could just invalidate the smf
whenever the score was changed; later we could enable the DenemoObject
insertion routine to call the smf library to update the si->smf
structure. For this we would want exportmidi.c to be broken down into
tiny functions for each DenemoObject type, instead of the large switch
statement that it has at the moment.
Does this all sound ok?

This all sounds good to me. Clearing up export and import midi was the reason I added libsmf into the project directory.



I think that will give you what you need.



Denemo-devel mailing list

Denemo-devel mailing list

reply via email to

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