Output of midiconv

This forum is for artists to post their music and graphics or discuss artistic matters that could be used in Uzebox games.
Post Reply
immortalx
Posts: 32
Joined: Sun Dec 10, 2017 7:01 pm

Output of midiconv

Post by immortalx » Sun Dec 31, 2017 5:40 pm

Hey guys
I had a look at some of the converted midi files and tried to figure out what's the sequence of bytes.
It seems there's a repeating pattern of 4 bytes:

1. Note (as in steptable)
2. ?? <-- Volume or something?
3. ?? <--number of frames? Duration?
4. ?? <--channel? Instrument?

The order of the notes doesn't seem to be per channel. Are they ordered in the order they are triggered (eg. note1-chan1, note1-chan2, note1-chan3, etc)?
There's also a sequence at the beginning of the file that I don't understand at all.
Can anyone please analyze what's going on?

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Output of midiconv

Post by D3thAdd3r » Sun Dec 31, 2017 6:25 pm

I should be able to say completely as I had done quite a lot of manual verification when creating a compression scheme for streaming music. But I can't because my mind cast that out as soon as it wasn't used again :lol: The best way to understand it is probably to read and run the song player code in your head, keeping track of your offset on the song data in a hex editor. It is slow, but not too hard after you start to understand the nybbles of each byte. For me, the player code would make more sense if it was showing binary explicitly.

At the beginning of each song there are going to be several events in a row which setup the patch to use for each channel. Then every note on event will trigger the currently setup patch, with a specific note and volume modifier encoded in the event. Events can be variable length, and will always store the number of ticks to wait before processing the next event. So the data at the beginning will have wait times of 0 so they all run the first tick. The first byte of the song (in the stock player) is discarded. Then most of it will be various notes on different channels, which all have a volume. Some songs are polluted with many expression events.

Not sure if it would confuse or help, but if you check out the streaming music branch and in particular mconvert, it will hopefully make sense. One of those daunting things, then it just clicks and makes perfect sense (it seems like sound in general is this way for most everyone learning). I wrote the code very explicitly using binary masks instead of hex, and the encoding scheme is a little more complex there for space efficiency, but I feel it ultimately is easier to understand due to code as documentation. The whole structure and events is the same idea, just a compressed representation.

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Output of midiconv

Post by D3thAdd3r » Sun Dec 31, 2017 6:33 pm

Should say, the stream is totally time based so the order of events is related sequentially to the notes in a song. Notes in a song that should be simultaneous of course are just an event with 0 delay until the next one. Different channels have notes at different times, so it should not be expected to see channels used in order, just the order they are (in time) in the song.

Note On events do not encode the patch to play, because that is set for the channel by a separate command. All notes on a channel are implied to use that patch, until another "instrument change" is encountered for that channel.

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Output of midiconv

Post by Artcfox » Mon Jan 01, 2018 3:18 am

If you are using the C++ version of midiconv, try passing it the -d option, because if I remember correctly, you should see what all of the output bytes mean translated right on the screen.

immortalx
Posts: 32
Joined: Sun Dec 10, 2017 7:01 pm

Re: Output of midiconv

Post by immortalx » Thu Jan 11, 2018 5:39 am

Thanks a lot guys and sorry for the late reply. I did some tests and there indeed is some stuff that doesn't get processed at all and removing them from a song makes no difference.
Now the reason I'm asking is because I'm writing a little tracker-like app and would like to export as output bytes for the uzebox. Should I target the stock player or the new streaming format? (If I can ever finish it, considering my luck of skills :? ).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Output of midiconv

Post by D3thAdd3r » Thu Jan 11, 2018 8:02 pm

Could be good to target the stock, since then you could use it as is (until I am not so lazy to finish flash "streaming") for stock flash only games. Mconvert can take stock format and convert it to compressed anyway, so matching the output of midiconv seems most useful at this moment IMO.

If you wanted to gamble that the flash compressed code gets done before your tracker, then I guess there is really no disadvantage to output compressed/streaming, and it removes the need for an extra config file for mconvert. Eventually I would anticipate the stock flash player only existing for backwards compatibility with the legacy games, or someone not needing space and not wanting to build an extra config file. I wont use stock anymore, since there is never a time I don't end up tight on space.

The last deciding factor might just be complexity which equals time. If it were me, I would do which ever format seems easiest to understand. If you end up going compressed, I will be more than happy to explain anything that is confusing. I cannot objectively say which is easier to understand, but for me personally compressed format is a lot more straight forward for me.

immortalx
Posts: 32
Joined: Sun Dec 10, 2017 7:01 pm

Re: Output of midiconv

Post by immortalx » Thu Jan 11, 2018 9:20 pm

Thanks again D3thAdd3r. I think I'll be able to post an example in the next couple of days. I can currently enter notes/vol/instrument and playback a single pattern, but having performance issues on playback. This shouldn't be a problem with exporting, but playback is completely sloppy since it's written in VB6 (please don't laugh at me, I'm no programmer :D )

immortalx
Posts: 32
Joined: Sun Dec 10, 2017 7:01 pm

Re: Output of midiconv

Post by immortalx » Fri Jan 19, 2018 5:55 am

It seems I'm on to something. I finished a somewhat crude version of the tracker and exported a test .inc file. I only added the program events manually.
It's the first few notes of "Korobeiniki-3tracks" from Megatris. I'm having sound issues with both of the emulators (crackling sound) and my son has my uzebox so I can't test it on the real hardware. Could someone please try playing it on a uzebox?
Attachments
r1.rar
(281 Bytes) Downloaded 89 times

User avatar
Artcfox
Posts: 944
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Output of midiconv

Post by Artcfox » Thu May 03, 2018 9:41 pm

Were you able to get this tested?

I don't have an unrar program on my phone, but if you attach the .uze file, I should be able to test it.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests