[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Denemo-devel] importmidi.c
From: |
Jeremiah Benham |
Subject: |
Re: [Denemo-devel] importmidi.c |
Date: |
Tue, 25 Aug 2009 12:08:55 -0500 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Tue, Aug 25, 2009 at 10:47:18AM +0100, Richard Shann wrote:
> On Mon, 2009-08-24 at 13:09 -0500, Jeremiah Benham wrote:
> > On Sat, Aug 22, 2009 at 02:32:18PM +0100, Richard Shann wrote:
> > > In the course of removing compiler warnings I noticed that importmidi.c
> > > was seriously abusing pointers. I have redefined the offending
> > > structures to contain integers, and changed the code to suit.
> > > I may have broken something in the process, I have just done a single
> > > MIDI import to make sure that there is nothing completely stupid there.
> > > But I thought that this would be a good time to get this cleaned up, as
> > > we are at the start of the 0.8.10 cycle, giving us time to sort out
> > > bugs.
> >
> > Something is now broken.
> Can you establish a test.midi file that shows a problem. Then revert the
> changes to importmidi.c (they don't have any impact elsewhere) and see
> if there really is a change?
I noticed that there are memory issues. I can't import two midifiles one after
the other anymore. I also noticed that some midifiles don't load at all now. So
I think my attempt to support multi-voices caused a regression or something.
Ok. I will look into what causes these midi files to crash denemo. I don't know
how to fix the memory issues. This is one of the reason I was wanting to work
in scheme. I am horible when it comes to memory management and I always screw
up type casting in c especially when dealing with pointers.
> I say this because it may give a clue to other problems that may be
> there. The changes I made would not break the code unless it was already
> using some undefined behavior (e.g. there was a comparison between a
> pointer and an integer, which might do something strange on 64-bit
> pointers).
>
>
> > I think I am going to rewrite some of importmidi.c and put it in scheme.
>
> Of course, if you *were* going to do something radical like this, then
> exploring problems in the current importmidi.c would be less attractive.
> But my instinct tells me that this is not a good way to go. I have had a
> look at the code, and I think it may well be close to doing what you
> want.
> Before committing to a big change in direction, I think it would be good
> to get a test file that exhibits a problem, and let me look at what the
> problem is.
Its too bad I already started working on it. I got a lot of it finished
already. Oh well. Probably good scheme practice. Do you want to see it?
>One thing that may be causing difficulties is that libsmf
> has not been tested by us for doing what you are using it for: you might
> change to scheme and find yourself with the very same underling problem.
There is a problem I remember that I encoutered in c and will experiece in
scheme also. This is When music has a time signature change in a staff. The
midi file I created (with Nted) had a "control track". This is a track with
mostly nothing in it but metamessages like Timesig, Keysig, tempo changes etc.
Then in track 2 that had the midi noteon/noteoff there were no timesig changes
indicated. So in denemo I would have to created this timesig change on every
track/staff. This is a problem. I don't know how to do that for future tracks
that have not been created yet. Denemo does not do this automatically. This is
why I was wondering if it would be better to do in scheme because all of these
weird work arounds that I would have to do to get this to work correctly. I
would have to lay out all the tracks in denemo. Then apply timesig on that
paticular measure for *All Staves*. Then I would have to rebar everything!
> Do you have a program that displays the contents of a midi file (did you
> say libsmf came with something to display its own interpretation of a
> file?)
smfsh does that. It is in the libsmf dir. Its easy launch it. Type help in the
shell. Select a track like this:
track 1
dump events from the track onto the screen with something like this
events
Jeremiah
> Richard
>
>
>
> > importmidi.c is doing some ugly low level stuff and I don't feel that it
> > needs to be that way. My idea was to use libsmf to read the midi file and
> > dump the track data out to be processed via scheme. The c portion of this
> > is mostly all written in libsmf/smfsh.c. What is passed to scheme would be
> > similar to the output of smfsh utiltily included in libsmf/ . Then when
> > scheme recieves the string of events it then decides what to do about it.
> >
> > Some helper scripts that will need to be written to:
> >
> > 1. determine how much time is left in the measure.
> > 2. if note is inserted and note duration > space left in measure tie the
> > note over to contain (duration - time_left) in next measure
> > 3. if inserting a note at time x duration x does it collide with note
> > already inserted
> > 4. if note collides and duration and start time are =, add the note to the
> > notelist for that object
> > 5. if note collides and duration or start !=, put the note in next voice ->
> > (create if nonexistant) (if existant rerun check for collision)
> >
> > Richard if you think this is not a bad idea then I will get started on this
> > now. I may need your help on some of it.
> >
> > Should I write a wiki page on my idea?
> >
> > Jeremiah
> >
> >
> >
> >
> > >
> > > I have also given the prototype of the DenemoDirective->graphic field as
> > > GObject *, to reflect its evolving role as a graphical object
> > > representing the directive. The case I have in mind is the textual
> > > commentry that people may want to add to a denemo music file, which will
> > > have its text editor stored here.
> > >
> > > Richard
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Denemo-devel mailing list
> > > address@hidden
> > > http://lists.gnu.org/mailman/listinfo/denemo-devel
>