|
 |
|
| MIDI file problem |  |
|
|
|
 |
|
 |
| |
|
John Simpson wrote:
|
June 13th, 2003 |
|
I'm using the full HoHo on my Tungsten W, using the patched version (thanks, Radoslaw!)
I am having issues when beaming the MIDI files out of the palm and trying to use them on other systems- on the computer itself, as well as on other phones (my Siemens S46 being a perfect example) and MIDI devices (such as a MIDI keyboard.)
The palm seems to be the only device capable of correctly playing the MIDI file produced by HoHo. Every other device (computer, phone, keyboard) which tries to process this file ends up trying to play every note in the track, almost at the same time.
I seem to remember reading something about some MIDI files playing "immediately", and that I would recognize it if it happened- I think this is it.
A dump of the resulting MIDI files show two potential problems. They have no "tempo" meta event (the FF 51 03 xx xx xx event) at all, which means that the sequencer which plays the file either has to guess, or use its default, to tell how fast to play the file (in "microseconds per quarter note".) Most sequencers have a reasonable defualt of 500000 (half a second, or 120bps.)
The other issue is where I think most of the problem lies. The MThd chunk contains a "pulses per quarter note" parameter, which tells how many MIDI pulses occur for every quarter-note. Normally this value is under 200, usually either 96 or 120, but the MIDI files generated by HoHo have 59176 as the value!
With the default tempo, this results in the sequencer trying to generate 59176 MIDI pulses per half-second, which is FAR beyond the timing precision of most PC's, let alone a cell phone.
My guess is that any sequencer which tries to process this file gets REALLY confused, because it's being told that it should be generating pulses that quickly. Maybe the sequencer in the Palm ignores this value and uses a default of 96, but my computer and both of my other phones (a Siemens S46 and a Motorola TimePort) are all having serious issues with these files, and end up playing the entire file in about 1/2 of a second.
I tend to be long-winded so I'll stop now. If anybody REALLY wants to know how MIDI sequencers handle these kinds of timing issues, let me know and I'll type something up. | |
|
Aaron J. Outhier wrote:
|
June 14th, 2003 |
|
Something I have been been meaning to write about also concerns HoHo's MIDI file implementation: The MIDI files in my System MIDI database play slightly faster than the original ringtone from which I exported it. I am wondering if this has anything to do with the CPU Clock Speed of my handheld being slightly faster than the original specification. (No, I'm not using an overclocking utility, my handheld was designed to run at 33 MHz, as opposed to the original 16 MHz). When I select a MIDI file and tap More->Edit, followed by [MENU]->Adjust Tempo, I find that: All of my Built-in Alarms are set to 400 ticks per quarter note; All of my Alarms created by MonkeyTone (Primate Systems, Inc.) are set to 288 ticks per quarter note, and play at the same speed as they do, in the MonkeyTone program; All of my alarms created by HoHo are set to 25 frames per second, 40 ticks per frame. If I change this setting to about 37 ticks per frame, it seems to compansate some what. (Either way, I have no idea what these settings mean or how they are supposed to affect playback). In response to Mr. Simpson's questions, I have noticed that none of the HoHo generated Alarms actually set the Ticks per Second field as you cannot (that is, HoHo doesn't allow me to) set both property fields at once.
--Aaron | |
|
I'll try to explain. As the Standard MIDI-File Format Specification says, the tempo can be saved in two ways - in metrical format, and in time-code-based format. See eg.: http://www.csw2.co.uk/tech/midi2.htm#BM2_1
It seems, however, not all MIDI sequencers can correctly decode the latter. Unfortunately HoHo uses this one for creating MIDI files out of exported ringtones. Because sequencers have no problems with the former, it will be used starting with the very next version of HoHo.
John, HoHo does not use tempo meta events while encoding MIDI files. It encodes the tempo once - in the header only.
Aaron, the main reason why the playing speed in the MIDI files is slightly different than in the ringtones (from which they were exported) is because ringtones store note lengths as divisions of the full note, while MIDI files store them as multiplicity of the tick. The value has to be translated while exporting, so you can never get the exact length. Yes, in the "Adjust MIDI Tempo" dialog you may manipulate either the Metrical time or the Time-code-based time to adjust the tempo manually. | |
|
John Simpson wrote:
|
June 15th, 2003 |
|
I had totally forgotten about the possibility of the MThd value being stored with timing based on SMPTE frames instead of note lengths. I've just added this to my MIDI dumper script.
http://www.jms1.net/code/
While I can see the merit of storing a MIDI file in this format with 25fps and 40ppf (the durations become milliseconds) it leads to ambiguity when trying to import a MIDI file and convert it to some other format.
For example, if a note has a duration of 104, the sequencer can tell exactly how long to play it (i.e. 104ms) but it becomes guesswork as to what duration to assign to the note when you have to represent it on a staff or as an RTTTL entity. Should it be an eighth note, a quarter note, a half note, or what?
Storing the file with "ticks per quarter note" in the MThd chunk and a tempo event at the beginning of the MTrk chunk makes it possible, just by seeing the duration, to tell what kind of note it is. If PPQN is 96 and a certain note's duration is 48, you KNOW it's an eighth note (48/96, or 1/2, of a quarter note.)
And with a tempo value of 500000 microseconds per quarter note (which is 120bps) the sequencer can tell that the delay between sending the KEY DOWN and KEY UP events should be 250000 microseconds (500000*48/96). It makes the sequencer do a little more math, but sequencers are designed for that.
This change (storing the MIDI files with PPQN and including a tempo event) will make it possible for some future version of HoHo to import MIDI files. I don't think it would look too good if HoHo weren't even able to import the MIDI files which it creates itself... I think it's a good idea.
| |
|
In fact HoHo already can import MIDI files - just install the MIDI Import Plug-in, and call the "More..." => "Import..." command in the HoHo's MIDI Manager. | |
|
John Simpson wrote:
|
June 15th, 2003 |
|
How does it handle files with SMPTE time-base and no tempo event? Does it just guess? For example, how would it handle a note with duration 104 (which one of my tones has?) Obviously the sequencer which plays the file knows how long it should be (104ms) but how does HoHo know what kind of note it is (i.e. 1/2 note, 1/4 note, 1/8 note, etc.) | |
|
The importing engine must be ready for various tempo values, and thus it is not always possible to follow the simple mathematical procedure (the one you mentioned before) to generate a ringtone.
What HoHo does with every imported MIDI is scan for the longest and the shortest notes in the whole file. Then, depending on the detected difference, it lets you adjust the tempo manually.
As a result you may have to import the MIDI again - with different settings - to finally achieve the expected ringtone. | |
|
John Simpson wrote:
|
June 16th, 2003 |
|
So (for exmaple) if the durations in the file are 104, 208, 416, 624, and 832, would it decide that 104 is a 1/4 note, 1/8 note, 1/16 note?
Or is it just a common sense guess- since most ringtones are designed for somewhere near 120bps, a duration near 125 would be a 1/16, near 250 would be 1/8, near 500 would be 1/4, and so forth? Does it have some default tempo number that it uses as a base, or does it depend on the tempo slider on the simple keyboard? What if a duration doesn't match an even division of whatever you're using as a 1/4 note (i.e. if you've decided that 500 is a quarter note, and one of the notes has a duration of 318?)
I'm asking this because I'm trying to understand how it makes these decisions when importing a MIDI file. If you'd rather not go into specifically how HoHo does its thing, that's fine- I'll keep plugging away and figure something out on my own.
I'm actually trying to write a command-line MIDI-to-RTTTL converter, because I have a bunch of old MIDI files which I would like to turn into ringtones. It doesn't look like there's anything out there to do it, so the plan is to convert them to RTTTL, sync them into Memo Pad items, and then use HoHo to convert them back to MIDI on the Palm.
A better solution would be to write a MIDI conduit... that's actually what I'd rather do, if I can find documentation on how to write a conduit (under Linux, of course.) The HOWTO for this used to be hosted on a web site whose domain name has since been taken over by a much larger company. I *think* I've found the person who used to maintain the document, but I haven't heard back from him yet.
If I can write a working MIDI conduit, I'll post something here about it. Maybe RNS:: can bundle it with HoHo or something... | |
|
The best idea is that you simply install and try MIDI Import Plug-in on your own.
While importing a MIDI file, HoHo lets you choose how the longest note (and thus all other notes) will be decoded. Note lengths are then decoded by linear divisions of the longest note (these divisions tend to round down) with the base length selected in the import dialog.
The sliders' settings have no influence on the created ringtone. | |
|
Aaron J. Outhier wrote:
|
June 16th, 2003 |
|
Mr. Simpson:
This probably goes without saying, but keep in mind that Ringtones exported through HoHo is not the only way to get a "MIDI Alarm" into your system database. If you were to use the previously mentioned "Pilot Install" to import a MIDI file from the Internet, there's no telling what timing base it will use, nor the range or diversity of note lengths. Some Alarms may be originally based on ringtones, others may not. Flexibility when dealing with unknown circomstances is both a programmers bane, and a user's delight.
Keep up the good work RaNo!
Like I said, this is probably pretty obvious, but in case it's not...
--Aaron
P.S.: Here in America, "Polish Jokes" are in high abundance. But, after seeing the work done by RaNoSoft, I want to kick myself for actually listening to my Dad. I thought I had learned that lesson long ago... :P | |
|
Unfortunately Simply Install - Pilot Install does not work on Linux, which seems to be what John was looking for. What's more, I don't know any similar tool for Linux.
P.S.
I thought the era of Polish jokes in the USA has already gone. Perhaps the jokes will really disappear now that Poland supports your anti-terrorist policy. Also we are soon joining the European Union (in less than a year's time), so maybe the jokes will pass on the Europeans, not just Poles... That would be funny ;) | |
|
Aaron J. Outhier wrote:
|
June 18th, 2003 |
|
Before reading John's first message for the first time, I didn't know for what exactly the "Beam" option was used (in MIDI manager). Last Saturday, I received the USB to IrDA Adapter I ordered off eBay, and Today I tried to beam an alarm to my Windows 2000 machine. Let's just say I was NOT beaming with pride 8P . All jokes aside, however, I am left to wonder what I'm doing wrong, as I'm given the message "an unknown problem occured" on the first attempt. On the second attempt, it seems to work, except I don't end-up with a MIDI file, but rather a file named HoHo### with no extension (the '#' signs mean a three digit number, which varies depending which alarm I'm sending). If I rename the received file, I discover that it isn't a valid MIDI file. If you would like, and if this isn't my fault, I'll E-Mail you a sample of one of the sent files. Also, on the second attempt with the same alarm, If I say No to the prompt "do you want to accept the file?" given by my W2K system, I am told (by my palm/by HoHo) that "this operation isn't supported". Once again, what am I doing wrong?
P.S.: I guess I didn't state that clearly, the number of different jokes out there are numerous, the relaying of such jokes - from one person to another - is very low, so yes, I suppose America is mostly over the whole Polish joke era.
BTW, Here are some Puns which relate to the word "pole", but aren't Polish jokes of the usual 'Put-down' variety, which are commonly associated which the phrase "Polish Jokes":
Q: Of what nationality is Santa Clause?
A: Northern Polish.
After a long debate about who should be the next Catholic Pope, one person said "let's take a pole"
Good night everyone! (or, good morning, to those in the eastern hemisphere | |
|
In fact the "Beam" command was supposed to beam MIDI files from one Palm OS handheld to another - it works.
Yes, please send me the files, perhaps it is easy to force HoHo to beam MIDI files to anywhere... | |
|
Thank you, I have recived the files.
The files you get on your PC contain standard MIDI data (MThd and MTrk) preceded by Palm MIDI resource header (MPrc). While revising HoHo's beaming module I'll try to make it to send data without Palm's header and naming the files *.mid. | |
| |
|
|
|
| Forum navigation | |
|
|
|
|
|
|
| |
 Click here to go back to the list of threads.
| |
|
|
|
| Add new message to this thread | |
|
|
|
|
|
|
| |
|
Posting to this forum has been permanently disabled.
| |
|
Palm, Treo, and Centro are trademarks or registered trademarks of Palm, Inc.
Copyright © 2024 RNS::
| |
