rlm@440: (ns com.aurellem.exp.music
rlm@440:   "scratchpad namespace"
rlm@440:   (:use (com.aurellem.gb gb-driver util constants
rlm@440:                          assembly saves
rlm@440:                          items pokemon status types
rlm@440:                          characters species moves
rlm@440:                          pokedex money rival-name
rlm@440:                          text-speed badges
rlm@440:                          pokemon-presets
rlm@440:                          ))
rlm@440:   
rlm@440:   (:import java.io.File)
rlm@440:   (:import [com.aurellem.gb.gb_driver SaveState]))
rlm@440: 
rlm@440: 
rlm@440: 
rlm@440: 
rlm@440: (defn analyze-music []
rlm@440:   (clojure.pprint/pprint
rlm@440:    (map (fn [[addr nums]]
rlm@440:           [(hex addr) nums])
rlm@440:         (apply harmonic-compare
rlm@440:                (map read-state
rlm@440:                     ["song-1" "no-song-1"
rlm@440:                      "song-2" "no-song-2"
rlm@440:                      "song-3" "no-song-3"
rlm@440:                      "song-4"])))))
rlm@440: ;; there are only two addresses that alternate between only
rlm@440: ;; two unique values:
rlm@440: 
rlm@440: 0xC0DE ;; lol code :)
rlm@440: 0xC0DF
rlm@440: 
rlm@440: ;; perhaps they are the address of the current playing sound?
rlm@440: 
rlm@440: ;; after watching them for a while in different environments,
rlm@440: ;; I can tell that they're definately music related, but they
rlm@440: ;; _don't_ seem to be the address to the current track.
rlm@440: ;; they generally change whenever a substantually different
rlm@440: ;; sequence is played.  maybe they control some high level
rlm@440: ;; setting in the synthesizer? They are only affected by the
rlm@440: ;; background music and not by pokemon cries, etc.
rlm@440: 
rlm@440: 0xC001 ;; seems to change along with the music, but is much
rlm@440: ;; more stable than 0xC0DE and 0xC0DF. It _is_
rlm@440: ;; affected by sound effects.  When a sound effect happens,
rlm@440: ;; is sometimes does not return to its previous value when the sound
rlm@440: ;; effect is done.
rlm@440: 
rlm@440: 0xC000 ;; does not seem to be affected by music
rlm@440: 
rlm@440: ;; maybe 0xC001 - something is loaded with the actual sounds?
rlm@440: 
rlm@440: 
rlm@440: ;; replacing just the first 0xFF bytes starting at 0xC001 with those
rlm@440: ;; found in celadon changes the music to celadon city.
rlm@440: 
rlm@440: ;; this can't be the actual music because it doesn't have enough
rlm@440: ;; information.
rlm@440: 
rlm@440: ;; let's try to narrow down the bytes from the first 0xFF of celadon
rlm@440: ;; starting at 0xC001
rlm@440: 
rlm@440: (def celadon-song
rlm@440:   [202 0 0 255 0 178 117 40 118 158 118 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
rlm@440:   0 0 0 0 0 0 0 0 0 0 0 202 202 202 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
rlm@440:   0 0 0 0 128 128 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
rlm@440:   0 0 0 0 0 0 0 0 0 0 0 0 115 88 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
rlm@440:   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
rlm@440:   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 5 5 1 1 1 1 1
rlm@440:   1 1 1 1 1 1 1 1 12 12 12 1 1 1 1 1 128 128 128 0 0 0 0 0 5 4 4 0 4 3
rlm@440:   4 0 178 194 32 0 180 196 32 0 3 0 0 144 1 0 66 31 0 2 2 32 48 0 0 0
rlm@440:    0 0 0 0 0 0 0 0 0 0])
rlm@440: 
rlm@440: (defn change-music-to-celadon
rlm@440:   ([#^SaveState state start length]
rlm@440: 
rlm@440:      (set-memory-range state (+ 0xC001 start)
rlm@440:                        (take length (drop start celadon-song))))
rlm@440:   ([start length]
rlm@440:      (continue! (change-music-to-celadon (read-state "rlm-viridian-forest-battle")
rlm@440:                                          start length))))
rlm@440:    
rlm@440:   
rlm@440: 
rlm@440: ;;0 0x90) blend between both, with end theme as well
rlm@440: 
rlm@440: ;; 0x05 0xEA is the limit to completely change song to celadon from
rlm@440: ;; viridian forest
rlm@440: 
rlm@440: ;; 0x05 0xEA is also sufficient to change music to celadon from
rlm@440: ;; a battle in viridian forest