Re: [Denemo-devel] importmidi.c

[Jeremiah Benham]

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
>