SNES audio hardware info
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
Re: SNES audio hardware info
If you were scrolling thru different samples, I'm interested in knowing the change in the adjacent samples relative to each other that allowed your desired effect to come thru.. And what exactly is that effect??
When I watched your spc play in a oscilloscope, I saw what looked like a wave that translated aka moved upwards ... What effect is that?? Amplitude Modulation??
I liked what I heard that's why I want to understand everything about it
When I watched your spc play in a oscilloscope, I saw what looked like a wave that translated aka moved upwards ... What effect is that?? Amplitude Modulation??
I liked what I heard that's why I want to understand everything about it
Re: SNES audio hardware info
reading the description of granular synthesis found at the bottom of this page :
https://documentation.apple.com/en/logi ... tasks=true
Typically, you have a sound which you divide into grains, from which you may reorganize their ordering and play back with different envelopes etc. Is this what you've done with just a square wave?
https://documentation.apple.com/en/logi ... tasks=true
Typically, you have a sound which you divide into grains, from which you may reorganize their ordering and play back with different envelopes etc. Is this what you've done with just a square wave?
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
I have no SNESGSS file. I literally created the file in a hex editor since I couldn't use the tracker.bazz wrote: I read somewhere that granular synthesis is just like wavetable synthesis except with the use of samples instead of mere oscillator waveforms... If that's the case, you would simply be scrolling thru different samples right??? Maybe i will try assigning arbitrary brr end blocks along the way in this scrolling process.. But I'm still interested in what you did KFF. please consider including your snesgss file for analysis
Amplitude modulation doesn't quite sound right to me (there's no way to pull off that kind of effect on the SPC700 without CPU-intensive operations by copying and pasting volumes on a per-sample basis or as close to that as possible).bazz wrote:If you were scrolling thru different samples, I'm interested in knowing the change in the adjacent samples relative to each other that allowed your desired effect to come thru.. And what exactly is that effect??
When I watched your spc play in a oscilloscope, I saw what looked like a wave that translated aka moved upwards ... What effect is that?? Amplitude Modulation??
I actually don't know some of the terminology very well myself, so I will freely admit that I myself don't know the exact terminology for some of these effects.
Sounds right to me.bazz wrote:Typically, you have a sound which you divide into grains, from which you may reorganize their ordering and play back with different envelopes etc. Is this what you've done with just a square wave?
Re: SNES audio hardware info
What kind of file is it??
Would you be willing to share the essential components whatever they may be? Such as brr samples and spc code?
I would love to investigate more!
Would you be willing to share the essential components whatever they may be? Such as brr samples and spc code?
I would love to investigate more!
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
There is no source code to speak of other than whatever source the SNESGSS sound driver used in the first place. Thus, the SPC code can simply be taken straight out of the SNESGSS sound driver. The music file was literally typed in by hand, byte by byte. SNESGSS's documentation has info on what each individual byte does once it is compiled.
The BRR samples can easily be extracted from that SPC file (unless you want me to create 17 .brr files and zip them up: one for initialization, and the rest of them being the individual square wave samples I used).
The BRR samples can easily be extracted from that SPC file (unless you want me to create 17 .brr files and zip them up: one for initialization, and the rest of them being the individual square wave samples I used).
Re: SNES audio hardware info
I would appreciate it if you could zip them up please. Thank you.
Regarding the 17 samples, What is the change being enacted between them? Or, in other words, what are you modulating?
Regarding the 17 samples, What is the change being enacted between them? Or, in other words, what are you modulating?
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
Here are the 17 samples in BRR format:
https://app.box.com/s/aao9o1qzo03ccrxz50mmt0ujfdy2ah4l
I guess it's which waveform is being played after the previous one finishes.
https://app.box.com/s/aao9o1qzo03ccrxz50mmt0ujfdy2ah4l
I guess it's which waveform is being played after the previous one finishes.
Re: SNES audio hardware info
Great! Now can you zip up some motivation.
No but seriously, did you randomize which samples were played after one another, or the durations which each sample is played for?? Or did you just scroll thru in equal intervals, without randomizing sample ordering?
No but seriously, did you randomize which samples were played after one another, or the durations which each sample is played for?? Or did you just scroll thru in equal intervals, without randomizing sample ordering?
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
I scrolled through the samples in an even interval without randomizing ordering.
Re: SNES audio hardware info
@KungFuFurby: So I think I finally answered the question unanswered for so long. you were doing a "high pass sweep"
http://botb.club/~bazz/sfx.mov
I'm still very much intrigued at this approach to sample playback (live modification of the sample ptr or table index)
EDIT: http://botb.club/~bazz/sfx2.mov
So you were mostly changing the duty cycle of the pulse then? but the last 3 waveforms, don't look anything like a pulse? What is their purpose? I don't recall the purpose of the init-pulse but I believe you explained it earlier
http://botb.club/~bazz/sfx.mov
I'm still very much intrigued at this approach to sample playback (live modification of the sample ptr or table index)
EDIT: http://botb.club/~bazz/sfx2.mov
So you were mostly changing the duty cycle of the pulse then? but the last 3 waveforms, don't look anything like a pulse? What is their purpose? I don't recall the purpose of the init-pulse but I believe you explained it earlier
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
Yes, I was essentially changing the duty cycle of a pulse wave.
Those last three were the result of trying to get the three narrowest duty cycles through a BRR converter that was run by SNESMod. When I originally ran them through the converter for use with SNESMod, I specified one BRR block that began the pulse wave (the very top waveform of sfx2.mov), then specified the rest of the pulse wave as a loop that ran through two more BRR blocks (the other waveforms).
Here's the post mentioning the purpose of the init-pulse: viewtopic.php?f=12&t=12383&start=45#p141705
Those last three were the result of trying to get the three narrowest duty cycles through a BRR converter that was run by SNESMod. When I originally ran them through the converter for use with SNESMod, I specified one BRR block that began the pulse wave (the very top waveform of sfx2.mov), then specified the rest of the pulse wave as a loop that ran through two more BRR blocks (the other waveforms).
Here's the post mentioning the purpose of the init-pulse: viewtopic.php?f=12&t=12383&start=45#p141705
Re: SNES audio hardware info
Doesn't MOVW take two cycles for the write? (Or possibly even three, considering it's a 5-cycle, 2-byte opcode, and it's not clear to me where the non-bus cycle falls?)KungFuFurby wrote:The reason is that you need to be able to move two bytes at one time using Y and A. Otherwise, you risk a cycle-exact glitch that results in the loop point being a pointer consisting one byte that's written and one byte that hasn't been written yet (which can result in a glitch if both have to be modified).
And yet your method sounds like it works fine...
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
I actually revised my methodology because I thought that maybe I'd still get that timing glitch (and even if I don't, things can still get nasty when setting up the next sample that's keyed on not using the loop point... and I know of a song that I could have swore switched instruments without keying off and made a big mistake in the process, that being Porky Pig's Haunted Holiday, the beta version, with Start of the Nightmare at 27 seconds in). I'm still using direct page $100 and MOVEW opcodes, but now I'm using 16 samples, two for each channel, and I simply have to flip a single bit in the sample ID to trigger the equivalent of a duty cycle change when using pulse waves (and the pointers are set up as such). This allows me to get away with setting up the next sample pointer early without worrying about the sound that's already playing.
I want to ensure that I don't have to deal with setting up to 256 samples (I'm letting the instrument data deal with the sample pointers, saving SPC700 RAM so that slots aren't wasted, and my sound driver will have a built-in way with dealing with samples that like to fool around with loop points), hence my thoughts.
I want to ensure that I don't have to deal with setting up to 256 samples (I'm letting the instrument data deal with the sample pointers, saving SPC700 RAM so that slots aren't wasted, and my sound driver will have a built-in way with dealing with samples that like to fool around with loop points), hence my thoughts.
Re: SNES audio hardware info
Can you safely use multiple sample table entries to refer to the same physical memory?
-
KungFuFurby
- Posts: 264
- Joined: Wed Jul 09, 2008 8:46 pm
Re: SNES audio hardware info
You mean by fooling around with DIR? I see that as a bad idea, personally, because you have to keep track of the loop points (they get read every time the sample loops). Failure to track them down can result in playback corruption upon looping or playing a new sample.
Otherwise, if you speak of using duplicate pointers for multiple samples, then my pulse wave test SPC file that I posted earlier demonstrates that. In addition, other games have also used duplicate sample pointers before (Bebe's Kids has this as a way of hiding a sample that got cut).
If you want to see an example of someone directly fooling around with the sample table, see the SPC set for Dorque and Ymp. This sound driver uses an 8-sample approach, with the sample directory at $0100.
Otherwise, if you speak of using duplicate pointers for multiple samples, then my pulse wave test SPC file that I posted earlier demonstrates that. In addition, other games have also used duplicate sample pointers before (Bebe's Kids has this as a way of hiding a sample that got cut).
If you want to see an example of someone directly fooling around with the sample table, see the SPC set for Dorque and Ymp. This sound driver uses an 8-sample approach, with the sample directory at $0100.