1. I think the lines like this:

old_len -= 0x1000000;
old_len -= 0x10000;
old_len -= 0x100;

will only work right when the bytes in the first three positions are exactly 1:

01 01 01 xx

2. Perhaps you might consider using bitwise operators, some people might find it easier to follow:

old_len = ( buffer_peek(new_buffer, buffer_tell(new_buffer)    , buffer_u8) << 24 ) +

          ( buffer_peek(new_buffer, buffer_tell(new_buffer) + 1, buffer_u8) << 16 ) +

          ( buffer_peek(new_buffer, buffer_tell(new_buffer) + 2, buffer_u8) <<  8 ) +

          ( buffer_peek(new_buffer, buffer_tell(new_buffer) + 3, buffer_u8)       )   ;



old_len += global.new_length_add;



buffer_write(new_buffer, buffer_u8, (old_len & 0xFF000000) >> 24);

buffer_write(new_buffer, buffer_u8, (old_len & 0x00FF0000) >> 16);

buffer_write(new_buffer, buffer_u8, (old_len & 0x0000FF00) >>  8);

buffer_write(new_buffer, buffer_u8, (old_len & 0x000000FF)      );

3. Minor nitpick: You might consider changing the name of "old_len" to just "length" or something similar. (Once you add in "global.new_length_add", it's no longer the "old_len", it's the "new_len" right?)

[quotePost id=17558]
will only work right when the bytes in the first three positions are exactly 1:
[/quotePost]
I thought so too. I tried to compensate by multiplying by the digit provided by the division in the previous line, but it ended up neutralizing all changes to the track length.

2. Perhaps you might consider using bitwise operators, some people might find it easier to follow:

My brain can not properly process bitwise operators 😉 Though that is probably the ideal way to do it. 😀

3. Minor nitpick: You might consider changing the name of "old_len" to just "length" or something similar. (Once you add in "global.new_length_add", it's no longer the "old_len", it's the "new_len" right?)

I used to have a separate value from my previous lazy math version, but when I updated it, I ended up just using the single value, so now everything old is new again?

Just before you replied, I changed all of the "/" to "div" to force integers only, but I think Game Maker automatically does that when using hex values anyway. I also realized that if the value I am checking is less than the value I'm comparing to (ie, old_len > 0xFFFF) I was moving to the next byte, ASSUMING that the byte already there by default would already be 0, which I have found not to be the case. I added in writing a 0 byte instead of skipping, and at least in this particular broken file, it now works properly.

[code type=markup]
if (old_len > 0xFFFFFF)
{
buffer_write(new_buffer, buffer_u8, old_len div 0x1000000);
old_len -= 0x1000000;
}
else
buffer_write(new_buffer, buffer_u8, 0);
// buffer_seek(new_buffer, buffer_seek_relative, 1);

[/code]

As Bavi_H says, his problem is that he only subtracts 0x1000000

If I understand the problem correctly it should be like this without bit operators:

[code type=markup]//This operation looks ridiculous written like this but don't forget that you are losing the decimal places in the process. 😀
old_len -= (old_len / 0x1000000) * 0x1000000;
old_len -= (old_len / 0x10000) * 0x10000;
old_len -= (old_len / 0x100) * 0x100;[/code]

I don't know GML but why write each byte separately and not directly write old_len?

[quotePost id=17767]why write each byte separately and not directly write old_len?[/quotePost]
Endianness.

[quotePost id=17767]As Bavi_H says, his problem is that he only subtracts 0x1000000

If I understand the problem correctly it should be like this without bit operators:

[code type=markup]//This operation looks ridiculous written like this but don't forget that you are losing the decimal places in the process. 😀
old_len -= (old_len / 0x1000000) * 0x1000000;
old_len -= (old_len / 0x10000) * 0x10000;
old_len -= (old_len / 0x100) * 0x100;[/code]

I don't know GML but why write each byte separately and not directly write old_len?[/quotePost]
Haha, actually, I probably can... I've been doing everything with unsigned 8 bit data (1 byte) because most midi data is byte specific. Apparently it supports many more read/write sizes, including 32 bit unsigned, which is just the right length.

https://manual.yoyogames.com/GameMaker_Language/GML_Reference/Buffers/buffer_write.htm

Guess I have something to test out.

[quotePost id=17767]why write each byte separately and not directly write old_len?[/quotePost][quotePost id=17768]Endianness.[/quotePost]__________[quotePost id=17767]why write each byte separately and not directly write old_len?[/quotePost][quotePost id=17769]Haha, actually, I probably can... I've been doing everything with unsigned 8 bit data (1 byte) because most midi data is byte specific. Apparently it supports many more read/write sizes, including 32 bit unsigned, which is just the right length.[/quotePost]
To expand on my previous post about endianness: Most modern computers use little endian ordering, but the chunk size values in a MIDI file use big endian ordering. To ensure the value is read and written correctly, you should read and write the bytes individually.

[quotePost id=17779]To expand on my previous post about endianness: Most modern computers use little endian ordering, but the chunk size values in a MIDI file use big endian ordering. To ensure the value is read and written correctly, you should read and write the bytes individually.[/quotePost]
I was aware of endianness but did not think it would ever be an issue for anything I was doing. However, I just checked some Game Maker information, and you are correct. This is an example that was provided:

var buffer = buffer_create(4, buffer_fixed, 1);
buffer_write(buffer, buffer_u32, 0x01020304);

buffer_seek(buffer, buffer_seek_start, 0);
repeat (4) {
show_debug_message(buffer_read(buffer, buffer_u8)); // prints 4, 3, 2 and then 1
}
bufffer_delete(buffer);

As you expected (but not me), the bytes for a 32 bit buffer value would be written in "reverse" order, causing chaos for me. I only half-finished changing my code to use a 32 bit write, so I guess I'll put it back and correct my 8 bit buffer write code.

[quotePost id=17767][code type=markup]//This operation looks ridiculous written like this but don't forget that you are losing the decimal places in the process. 😀
old_len -= (old_len / 0x1000000) * 0x1000000;
old_len -= (old_len / 0x10000) * 0x10000;
old_len -= (old_len / 0x100) * 0x100;[/code]
[/quotePost]
Because of how the math is handled in GameMaker (no type casting or inherent distinction between decimal and hex during calculation), I had to change the "/" (which keeps remainders) to "div" (which discards remainders) to get the correct track lengths, otherwise the files were getting corrupted with incorrect track lengths. So far, so good!