It looks as if Csound is writing the wrong tempo value to the midi file, and this should be fixed. It will probably help the developers if you can provide a very simple example that writes such a midi file.

In the meantime, you could work around it by converting the midi file to text (using mf2t.exe if you're on windows), and writing a small python script that rewrites the tempo value in that text file. I'm sure you can automate this procedure to batch process all midi files in a directory, so the process could be incorporated in your general setup automatically.
best

Oeyvind
 

2007/12/13, Tim Mortimer <timmortimer@d2.net.au>:

So I wrote to Tim Thompson (of keykit fame) & said "here's my MIDI file that
Csound generated, & whilst your keykit application is one of the few things
around that seems capable of importing it (but readers, let's just drop that
issue for the time being...one step at a time...) it plays back at
100,000,000 miles an hour - i think it's something to do with the header
data - any ideas?"

he opened my file (with his fancy programming doo-daddery) & advised that
whilst a "normal" midi file might be headed

MFile 0 1 96

the one that Csound made was headed

MFile 0 1 59256

leading him to conclude (quote)

"The 'divisions' value in your header is causing the problem"

I thought this might be due to the fact that i was rendering the MIDI file
from csound as fast as i could / slash in "non real time" - but when i tried
a moment ago rendering the file in "real time" (still using --midioutfile
flag of course) same thing happened. playback with keykit at 50 zillion
BPM...

so is there an issue with the --midioutfile, & can it be resolved, not only
to create a more generic output 'divisions' value, but while who-ever is
looking at it is looking at it, they may as well check all the header data,
because like i say, other apps that i have tried importing the csound
--midioutfile into (Cubase & Ableton both for example... not that i use them
anymore - but desparate times call for desparate measures... ) have failed
to manage to import it

& as i mentioned previously, if i open the file & save it again using the
seq object in Max, the problem "dissapears", so seq obviously creates the
adequate "generic" headers & 'divisions' value, & still produces bog
standard type 0 file formats...

can't believe i've devoted about the last 50 hours of "python / csound" time
to dealing with midi files - conceptually "peripheral" as they are to my
overall creative "direction" here... but u live & learn i guess....

i can still work towards "hand fixing" these midi files for further use
(somehow...), but my whole "batch render MIDI & sco with python" is SO CLOSE
to blockbusting rapid fire fruition here, I really desperately implore those
responsible to fix this issue if at all possible (& i'll shut up about Loris
i promise & try & get that happening using the python environment
instead...well, at least for another 6 months or so anyway ; ) ...)
--
View this message in context: http://www.nabble.com/the---midioutfile-properties-tp14267381p14310795.html
Sent from the Csound - General mailing list archive at Nabble.com.



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"