Sorry, I'm not at all clear what you're trying to to do. Even less, why?

A midi file has a VERY specific structure, you can download the detailed spec from this site. As long as you follow the rules for the overall structure, then you CAN create a file manually as you're hinting at, even if the result is musical nonsense.

If you can work in DOS I have a couple of programms that might help you. DECODE and ENCODE. DECODE takes a midi file, and converts it into a .TXT file that you can edit and manipulate as txt, adding/removing parts as you like,

** As long as you honour the overall file/data structure **

Then, you use ENCODE to write the txt back into a midi file.

Just to hint at one bit of what you need, a midi 'event' should always have some timing data, followed by a byte which defines what sort of data this is (i.e. note on, note off, what channel, controller, etc), then a note number (frequency ?) or a controller number, then for a note say a 'velocity (i.e. loudness).

What data would your input be providing?

Geoff

Geoff,
Many thanks for taking the time to reply. Thank you for pointing me in the direction of DECODE and ENCODE, i will look into these. Also your breakdown of the midi event is very helpful.

As for a reason, basically I am testing an idea of being able to troubleshoot server logs via sound. The output will be complete nonsense but i am sure with some structure applied I might be able to run a script to create a 30 second midi file that i can listen to catch issues as opposed to reading through logs. Its just a concept but i figured midi files would be the way to go.

If you have any thoughts around best practices here that would be very helpful. I have come to midi to facilitate this idea so I am very new to it, all information is greatly appreciated.

Thank you!

As you now put it, it makes somewhat more sense.

I'd say you could do this.

I think you'd need a bit more that a 'script' mind you.

You'd need a process, prob a program, which could read the log file, detect the various events that you wish to follow, and assign a midi event to each as appropriate. So you'd need the data ready for various complete and VALID events. With appropriate midi timings. You could end up with something similar in sound to the noise you hear from an old-style modem, maybe slower, and with more variation. You could use different frequences, different instruments, different note lengths, depending on the urgency/criticallity of the logged event.

The routine would need to assign the header as pretty much fixed. I'd suggest you need one track only, so a type 0 midi file would be fine.

I'm pretty sure you'd need to create the midi file, then play it. I don't think it's usual to play a midi file in real time, although this might be possible with a type 0 file. If you want to play in real time (which may be necessary if the log file you're 'performing' (??) is VERY large) then you could dispense with the midi file and just send midi data in real time to the midi ports, in which case the midi events will not need the timing data, the programming will handle that anyway.

Am I still thinking along the right track. I might be going off-course?

Geoff

As for a reason, basically I am testing an idea of being able to troubleshoot server logs via sound.

This idea reminds me the open source MonAMI "friendly monitoring daemon", a service oriented to servers and data centers, offering a set of sensor plugins to monitor and detect problems on other services and machines, with a complementary set of reporting plugins to notify in several ways the detected events or problems.

Well, there is a reporting plugin for FluidSynth (a realtime MIDI synth) that translates the detected events into sound, generating MIDI events on the fly to be rendered by FluidSynth as sound, without building a MIDI file first. You may find more details here: http://monami.sourceforge.net/userguide.html#fluidsynth

Regards,
Pedro