PGM File Format

Does anyone have or know where to find info describing the PGM file format? I've been wanting to develop my own tools for creating/editing PGMs on the PC, but need this info to get started. Any help's appreciated.

Try the archives for PGM file format.

Try mpc1000.com for free software that does PGM handling already.

Try the archives for PGM file format.

Try mpc1000.com for free software that does PGM handling already.

I've used the free PGM creator for the MPC1000, and it saves me a bit of work. I want a feature that would help automate creating multisample programs (one or more samples, assigned over all the pads, tuned +/- as needed to cover all notes). This is mainly for my own exploration for now; not prepared to develop anything for distribution.

If you have the MPC and a hex editor by your side it should be easy to figure out how tuning works in the PGM format.

If you ever figure out what the 128 bytes after the MIDI Note data section of the PGM file is, let me know.

I have a hex editor, and I'll just have to sit down and try changing program settings and see what bytes change to decipher what's what. Don't have alot of time for that now, but hopefully I get into it before I forget about it and move on to something else.

Thanks loads for this link; this is what I was looking for. I did a search, but must have not searched on the right keywords or I skipped right over this.

Also, BIG thanks to stereoroid for doing the legwork to get this format banged out and posted for the public.

Oh, yeah, it's been a while...
I haven't done any more work on this, since I got so used to using the MPC itself it removed my need for the scripted stuff I was considering. I stopped just short of reading the Tuning figures, but that should be simple, I think.

"MIDI Note data section"

Which one? There are two.

There's another MIDI Note section between the "first" MIDI note section and the Program Change / Slider data? Those are the 128 bytes which I have not found to affect the MPC programs in any way. With my app I just store them and write them out again. You know what they do?

There is a 64 byte section that relates pad numbers to midi notes (as opposed to midi notes to pads in the prior section). They are related and I had to write an small algorithm to to calculate both sets out correctly.

The broken up sets of 29 and 35 bytes are nothing and I suspect reserved to allow for changing the midi scale of the pads.

Yeah, those are the bytes. I've just been storing the 35/64/29 byte sections. I haven't noticed any ill-effects by not correctly setting those 64 bytes. Has any MPC Pad 187 user found strange behavior with program files created by the app?

I'll look into correcting those bytes.

I've figured out the tuning bytes. The value's stored in 2 bytes, and when cast into a signed 16-bit integer and divided by 100, you get the tuning value as displayed by the MPC1K.

EX:
- In my PGM file I'm using for testing/exploration, I have a layer's tuning value set for +03.18.

- I looked in the 2-byte area set aside for tuning in a layer (as outlined by Stereoroid's specs) and I found 0x013E (stored as 3E 01 on my platform), which translates to the integer 318.

- Divide by 100, and you get 3.18. Since I'm moving these bytes into a signed 16-bit integer type, this also correctly interprets tuning values < 0.