• Just a reminder that providing specifics on, sharing links to, or naming websites where ROMs can be accessed is against the rules. If your post has any of this information it will be removed.
  • Ever thought it'd be cool to have your art, writing, or challenge runs featured on PokéCommunity? Click here for info - we'd love to spotlight your work!
  • Our weekly protagonist poll is now up! Vote for your favorite Conquest protagonist in the poll by clicking here.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

How to add a function that allows players to adjust the speed of music

  • 5
    Posts
    1
    Years
    • Seen Oct 1, 2024
    If your simulator implements acceleration, the music will also be accelerated, so I hope there is a feature that allows players to adjust the playback speed of music so that they can hear normal music while accelerating
     
    This would not be easy, but it is possible. It won't be a quick process.
    1. You would need to add a music speed variable to the SaveBlock2 struct. Two bits will probably suffice, giving you 4 different options.
    2. You would need to add code in src/option_menu.c to display this new option in the Options menu, as well as code to change the value of your music speed variable when the player interacts with this new option.
    3. The ugly part is actually having all of this affect the tempo of the music. You could change how the tempo command is translated from the midi to the .s file, making it always multiply/divide the tempo by whatever value the player has selected. You would need to create an extended command in src/m4a.c and add it to gXcmdTable in the file src\m4a_tables.c to handle all of that, as well as edit tools/mid2agb/agb.cpp so that the midi tempo command doesn't create a TEMPO command in the .s file, but instead creates your extended command. I've written a fairly detailed tutorial on working with music at this low level in pokeemerald (here it is), which should help a lot. What you'll mainly be looking for is under "How to Work with .mid Files", more specifically "Adding Your Own Commands to mid2agb (A Slightly Deeper Look at the .mid → .s Process)". It will take a fair amount of reading to be able to figure out how to make your function, as well as have it show up in the .s files.
     
    This would not be easy, but it is possible. It won't be a quick process.
    1. You would need to add a music speed variable to the SaveBlock2 struct. Two bits will probably suffice, giving you 4 different options.
    2. You would need to add code in src/option_menu.c to display this new option in the Options menu, as well as code to change the value of your music speed variable when the player interacts with this new option.
    3. The ugly part is actually having all of this affect the tempo of the music. You could change how the tempo command is translated from the midi to the .s file, making it always multiply/divide the tempo by whatever value the player has selected. You would need to create an extended command in src/m4a.c and add it to gXcmdTable in the file src\m4a_tables.c to handle all of that, as well as edit tools/mid2agb/agb.cpp so that the midi tempo command doesn't create a TEMPO command in the .s file, but instead creates your extended command. I've written a fairly detailed tutorial on working with music at this low level in pokeemerald (here it is), which should help a lot. What you'll mainly be looking for is under "How to Work with .mid Files", more specifically "Adding Your Own Commands to mid2agb (A Slightly Deeper Look at the .mid → .s Process)". It will take a fair amount of reading to be able to figure out how to make your function, as well as have it show up in the .s files.
    Thank you!!!
     
    This would not be easy, but it is possible. It won't be a quick process.
    1. You would need to add a music speed variable to the SaveBlock2 struct. Two bits will probably suffice, giving you 4 different options.
    2. You would need to add code in src/option_menu.c to display this new option in the Options menu, as well as code to change the value of your music speed variable when the player interacts with this new option.
    3. The ugly part is actually having all of this affect the tempo of the music. You could change how the tempo command is translated from the midi to the .s file, making it always multiply/divide the tempo by whatever value the player has selected. You would need to create an extended command in src/m4a.c and add it to gXcmdTable in the file src\m4a_tables.c to handle all of that, as well as edit tools/mid2agb/agb.cpp so that the midi tempo command doesn't create a TEMPO command in the .s file, but instead creates your extended command. I've written a fairly detailed tutorial on working with music at this low level in pokeemerald (here it is), which should help a lot. What you'll mainly be looking for is under "How to Work with .mid Files", more specifically "Adding Your Own Commands to mid2agb (A Slightly Deeper Look at the .mid → .s Process)". It will take a fair amount of reading to be able to figure out how to make your function, as well as have it show up in the .s files.
    ply_tempo can be found in m4a_1.s. Can I achieve the effect I need by modifying it? If so, what is the appropriate modification?
     
    ply_tempo can be found in m4a_1.s. Can I achieve the effect I need by modifying it? If so, what is the appropriate modification?
    Theoretically, you could. Unfortunately, that file's written in assembly, which is a bit above my paygrade. I know you would need to create another constant in constants\m4a_constants.inc to be able to access your music speed variable within ply_tempo. Beyond that, I've got nothing. I don't know how you would link this new constant with whatever value the player chooses, nor would I know how to go about impacting the tempo with this constant. I'm sure there are several people who are more well-versed in the assembly-level stuff of the sound engine than me. I think CyanSMP64 is decently knowledgeable. He did a big expansion to the sound engine for it to handle DS Pokémon voices and songs pretty well.
     
    Back
    Top