SNES audio hardware info

This is always something I've been curious about, but never bothered tampering with. I know that the audio is almost entirely separate from the rest of the system and is controlled by the SPC 700 cpu, which is apparently similar to the 65816 cpu found in the other part of the system. Does the SPC 700 look straight at the cartridge slot and forget about the 65816, or do you have to tell the 65816 to send information to the SPC 700? I noticed that the music still runs in a majority of these games even when they crash, so would it be the former? I also know that the SNES has 8 channels for "real life" sound effects (as apposed to FM) that make the music and, off course, are used for sound effects, meaning that you can arrange the tracks for music and the sound effects however you like. I also know that all the sounds are stored in a 64kB space called "audio ram", but I don't really have a good understanding as to how big that is for this sort of thing. How many seconds of audio can you store at the highest quality, assuming you can even change it in the first place? would music like this be possible? (Space wise. I'm pretty sure there aren't more than 6 instruments playing in the song at a time.)

https://www.youtube.com/watch?v=kY2awRU3Sx0 (I'm a sucker for this kind of fast passed, cheesy electric guitar crap)

Oh yeah, is the SPC700 8 bit or 16 bit? A lot of places say the processor speed, but nothing else.

Yes. One uploads the program that runs the music to the SPC700's CPU, and that runs it more-or-less independently.
the SPC700 supports a native compression format called "Bit Rate Reduction", which packs 16 monaural samples into 9 bytes. The SPC700 could correspondingly hold about 3.6 seconds of raw audio compressed in this way (65536÷9×16÷32kHz).

As a result, most SNES games either use something more like MIDI with soundfonts, or MODs, where they instead encode "play this sound on this channel at this time"
8-bit 6502-like microcontroller with a 16-bit DAC.

The latter. The SPC700 cannot access the cartridge slot; its only connection to the outside world is a set of four I/O ports, which are mapped to $2140-$2143 on the S-CPU side and $F4-$F7 on the S-SMP side. (And yes, this means it will cheerfully keep playing a track if the main CPU goes down, because it has no way of knowing anything is wrong.)

You cannot DMA bulk data to these ports. Anything that goes in one side must be explicitly picked up on the other side by the other CPU. If you want to automate a transfer without having the SNES CPU stuck in a loop, the best you can do is use HDMA and make sure the SPC700 is checking the ports often enough to catch it all.

...oh yeah, there is one thing. There's an analog stereo passthrough on the cartridge slot; the audio module mixes it with its own output. This is how the BS Satellaview, Super Game Boy and MSU1 work.


The sample format is BRR, which has a 32:9 compression ratio on 16-bit material. The output sample rate is 32 kHz. At that rate, 64 kB is enough for a little over three and a half seconds of monaural sample data. Mind you, most samples don't really need that bitrate...

This, of course, leaves no room for the sound driver, sequenced music data, stack, zero page or echo buffer. Everything has to fit in that 64 kB.


You can. Each game has to load the audio RAM before trying to do anything, because there are no built-in sounds or functions - only a tiny 64-byte boot ROM that starts the SPC700 in a useful 'listening to the I/O ports' state.


I don't see why not. It might not sound identical, but I don't hear anything obviously out of the ballpark... Just be sure to use an appropriate pre-emphasis filter on the samples, because the interpolator will muffle them.


8-bit. It does have a couple of opcodes that use or generate 16-bit values (MUL and DIV come to mind), but they hijack one of the index registers for the high byte.

The DSP is 16-bit, or at least the audio output is...

Yeah, I actually looked inside of the game and there was a file that just contained audio. I played it in Audacity, and I noticed that the song wasn't actually all arranged, but all the instruments were there. (Not the FM ones, off course) The thing is, the audio in the file played very fast, so I had to slow it down to sound normal. Would this be to make up for limited space?

Probably. One thing you'll notice if you get into SNES music is that sample data doesn't tend to be high-resolution unless it really needs to be, and sometimes not even then. Saving audio RAM and saving cartridge space are probably two-thirds of the reason SNES audio was sometimes muffled (the third reason being lack of proper prefiltering of samples to counteract the effect of the interpolation filter).

Now, you can stream audio to the SPC700 by continually exercising the I/O ports during playback. Tales of Phantasia famously used this technique to stream a (muffled) vocal track during the intro song, and Star Ocean's soundtrack is undumpable (in SPC format at least) because they changed out instrument data on the fly. Hitting all four ports with HDMA, it seems to me that it might be possible to push nearly 40 kB per second depending on how busy the S-SMP is. That's enough for 32 kHz stereo BRR. And, of course, blargg has demonstrated that if you don't mind dedicating a lot of CPU time to it, you can stream uncompressed 32 kHz 16-bit stereo PCM - which there's room for about a minute of if there's no actual game hogging up the cartridge...

If your using 4 HDMA ports for audio, doesn't that mean you have 4 less ports for other things like scrolling line by line?


Sorry if I sound stupid, but what is taking up CPU time if it is uncompressed? I also wonder about the MSU-1 and what it does to provide "32 kHz 16-bit stereo PCM". Is it a coprocessor that gives the CPU time to do other things?

Yes, but I think you could do it with only two HDMA channels.


Something's gotta write to those ports. Even HDMA stalls the CPU while it's firing. And it strikes me that there's a fairly strict bandwidth limit on HDMA; once you've written all four I/O ports, you have to wait for the S-SMP to notice and get the data before you write again, which I suspect means you can only hit each port once per HBlank. If you want to go faster, you have to put the S-CPU in a polling loop so it can send the SPC700 new data as soon as it signals that it's ready.

Also, IIRC the audio in blargg's demo was in fact compressed, using a lossless scheme incompatible with the S-DSP. The S-CPU decompressed it before sending it to the audio module, which played it by putting it in the echo buffer.


MSU1 audio is full-scale Red Book at 44.1 kHz. It uses the analog passthrough pins on the cartridge slot to completely bypass the digital part of the audio module (and of the rest of the SNES, for that matter). blargg's demo doesn't use the MSU1.

Just thinking, if you're not constantly uploading music, couldn't you use all 4 HDMA channels when you are doing something like changing levels, and then have all 8 free? I don't see why not.


I know that you said it takes up a lot of processor time, but does it really take up more time than if you used 4 HDMA channels for anything else? Would blarg's demo along with an actual game be out of the question? From what you told me, the MSU-1 seems a bit like "cheating" and I never really wanted to use it in the first place.


If you're just swapping out instruments with HDMA and your not planning on playing an entire song using it, you can still have the samples be compressed and this would save on CPU time?

Between levels, you're often DMAing to VRAM. If a normal DMA finishes too close to the start of HDMA, this could cause the DMA controller in a launch console (S-CPU revision 1) to crash.

MSU1 only looks like cheating until you realize there is a hardware implementation of the design in Verilog. Meaning that it's as real as the Super FX is.

What do I think? You didn't ask lol. but here goes :

I think you should stop focusing on all this HDMA / DMA / streaming balogna and focus on tracking

The 65816 has to wait for the SPC700 to keep up with it.

I'll be waiting on you for that...


What a slowpoke.

I meant that I think you could fully occupy all four SPC700 I/O ports with just two HDMA channels. One mode 4 indirect addressed for data, and one mode 0 direct addressed for transfer control (a byte the S-SMP can check so it knows the data is new). You waste a write this way, but the overhead is a lot lower and you free up two channels.


No. I'm talking about the case where you don't have enough bandwidth with just HDMA, and you have to put the CPU in a poll/update loop.

Refreshing audio RAM is very tedious compared to refreshing VRAM, because you can't DMA to it.


It's one minute of music, and it takes 4 MB. And the CPU is almost at 100% load just decompressing the audio and feeding it to the SPC700. So yes.


The samples have to be compressed. The S-DSP only understands BRR. And further compression of BRR won't get you anywhere; it's pretty tightly packed already.

A sample swapping engine is a very sophisticated trick. Keep in mind that undumpable games are very rare, and that most of them are that way not because of streaming but because the developers didn't understand the SPC700 and wrote audio engines that required continuous S-CPU input to work.


This. I probably shouldn't have mentioned streaming; it's a very advanced technique, and only a few games used it very late in the system's life. (I had Bad Apple on the brain, I guess.) The meat and potatoes is using what you've already put in the audio RAM to make fine music and immersive sound effects.

It's limited, but it's not that limited. When I said the music you linked was probably possible, I wasn't taking streaming into account. Plok, Rock 'n' Roll Racing, Vortex, Dracula X, the DKC games, Super Star Wars, Energy Breaker, Final Fantasy VI, Seiken Densetsu 3, Super Mario RPG, Actraiser, Super Turrican 2 - none of them use streaming. Even Tales of Phantasia only uses streaming for voice work; the instrumentals are all preloaded.

I thought that you said that the SPC 700 decompressed the audio. Is the "S-CPU" not the sound processor? Would the music be possible in a game if there was no compression and you instead used an insanely large cart? I'm probably not going to try something like this, I'm just curious.


Just for the heck of it, here's how all the instruments and sound effects sound in the game before slowing them down. (You can't upload a WAV file? Huh.)


You know, if sound on the SNES is so flexible, then why do a lot of songs from games like Street Fighter 2 sound a lot different than the arcade version? I'm pretty sure sound on the CPS 1 is FM, but couldn't you have instruments that sound exactly like FM that you can use?

That reminds me of something I heard about the DKC games. Dave Wise said in an interview, that he used a synthesizer that produced instruments by linking shorter waveforms together, and programmed the SPC700 to emulate it.

In that case, what's really stopping you from having a simple beep for a instrument and chain hundreds of those together at different pitches to create instruments?

The "S-CPU" is the main CPU. I think the "S" exists to distinguish it from the NES CPU, as there also exist S-PPU1 and S-PPU2. S-SMP is the SPC700 CPU, which talks to S-DSP.


You wouldn't be able to change the tempo when time is about to run out, which is one thing that sequenced music has over streaming music.


You can upload .ogg though.


In my opinion, RAR is even worse, as its decompression requires use of software that you aren't allowed to understand.


Perhaps they didn't have tools to make them sound "exactly like FM", or they wanted to make it better. Case in point: Super Mario All-Stars could have just used square waves, but instead it changed all the instruments and added additional music channels.

You can do some FM with pitch modulation (assuming we speak of sine waves). However, it takes two channels to use, and it has a limited range on how the pitch is affected (up to I believe an octave). Plus, only ADSR and gain values affect the strength of the modulation, not the actual volume.

...okay, Espozo, my previous explanations should make a lot more sense to you now. To reiterate - sending data to the audio module requires the S-CPU (the 65816 clone known as a Ricoh 5A22) to send data via the previously-discussed I/O ports to the S-SMP (the souped-up 6502 knockoff known as a Sony SPC700). The S-SMP shares a single 64 kB RAM pool with the S-DSP, which generates the actual audio and is controlled by the S-SMP.


Without compression, the chipless Star Ocean map could hold about a minute and a half of 32 kHz 16-bit stereo PCM, with no space left over for game data. And the transfer loop would probably still take up a large fraction of the available CPU time. So no, it's probably still unfeasible, unless you used a bankswitching chip and maybe a coprocessor.

If you want to try scaling down the bitrate, well, Tales of Phantasia exists (to be clear, only the vocals are streamed). At that point it's a question of balancing quality with ROM and CPU time.


Theoretically, yes - as long as you can fit what you want to do in the memory you have available. That Gunforce 2 audio file is 2 MB, or nearly 600 kB in BRR format, so it would have to be cut down judiciously (or streamed on demand) to work on the SNES.

There's also the curious and oft-neglected "pitch modulation" feature, whereby the audio output of a channel (before main channel volume) can be used to modulate the pitch of the next channel. You may recognize the word "pitch" as a commonly-understood synonym for "frequency" - that's right, the S-DSP is an FM synthesizer.

Kinda. FM synth and SNES pitchmod are conceptually identical, but they're a fair bit different in practice, and using the latter musically is rare, probably because it's not set up to make such use easy. You can use arbitrary waveforms, but there are no routing options, modulation is limited to +/- one octave, and each operator burns a channel. And there's no autosync, so you have to align the waveforms yourself. You can do cool things with it if you know what you're doing, but you're probably better off with straight samples for the vast majority of cases.

...ah. KungFuFurby scooped me on this... just so we're clear, he's the expert; I'm just a well-read n00b...


That sounds like granular synthesis. I think Rock 'n' Roll Racing used something like that.

If you mean additive synthesis, though... Eight channels, remember?


Or Capcom sucked at SNES audio...

PCM streams suffer from transitional disadvantages when it comes to looping as well. All those special effects have to carry over into the next loop. I also don't completely trust PCM for interactive music for the same reason: I can just simply program a flag check in music data. PCM is more of a polling-style transition, and even then, it has to be sample exact (and you need more PCM files to account for special effects fading away during these transitions).

I think of Packy and Marlon when I think of pitch modulation... even if the results are not quite right. Playground 2 and House 4 come to mind, and Unknown Song 9 and 13 also contains pitch modulation that sticks out.

Blockade from Jurassic Park 2 uses pitchmod.

Something I observed a while back with fooling around with soft synths is that the best sounding instruments have some kind of detuning in them, but if you try to sample a detuned instrument, you won't find any loop points.

You know though, about all the instruments, if you see some of the noises in the track I've shown you, It seems like a lot of them are instruments that are very long to lower the tone. Can you change the tone of a sample while it's playing and possibly loop it so that you don't have a long portion of space you are wasting? This way, you could have the guitar noise be very short and you could loop it and simultaneously lower it to have the effect of drawing it out like they have it. You know, another thing I forgot to ask is how you set it up to where you are using both speakers. Can you make it to where you can a channel can either use the left, right, or both speakers? Can you also have it to where it works for both, but is a different volume on one? It seems like ram (definitely not wram, though) is the SNES's main problem, and this is no exception on the audio side of things either.


Why a coprocessor? Is it still the HDMA? I'd love to see someone actually try and do something like this, even if the cart would reach gargantuan size. (I think a bank switching chip is a bit more "fair" than just completely bypassing the audio hardware.)

Espozo the answer to all these questions is YES and that's what Tracking is, and this is how the SPC is generally programmed.

Wow, that's actually pretty awesome! So if I really wanted to (even though I'm not going to) I could probably nearly recreate all the instruments that play in the song while using a fraction of the space. The only thing is, It seems a bit more difficult to do this sort of thing when it comes to sound effects. Could you would use HDMA to constantly stream the sound effects, allowing more room for the actual song? I plan on using 6 channels for the actual song and 2 for sound effects, so could you have it to where an HDMA port works with one sound effect and the second for the other?

I'm pretty sure the fighting games used streamed BRR for calling characters' moves, as did games like NBA Jam for the announcer. Pushing bytes to the APU I/O ports with HDMA might work with only one HDMA channel (I haven't tried it yet), but it would need special attention by the SPC700 to make sure that it never misses a byte of sample when, say, processing music. (There's no IRQ; everything's polled.)

If you mean lowering the pitch, yes. If you mean reducing the volume, yes. If you mean keeping the pitch the same while the timbre dulls (like the guitar sample in Gunforce 2), no. That's a job for either a long sample or an adventure in pitch modulation (you can sharpen the beginning of a sound with pitchmod, then fade out the modulating waveform, but doing this so as to match an existing sample might be quite difficult). One might have to make a hard decision about how much high-frequency information the sound in question actually needs, so as to pick an optimum sample rate... I suppose you could use a dynamic sample rate, but that would require you to continually change the playback rate so as to maintain the pitch...

The guitar in the audio file you posted contains multiple recorded loops - ie: it's wasting space as it is. The same is even more true for the long orchestral/choral sample two doors down. And some of the percussion sounds are longer than they need to be; they could be looped or faded out, with appropriate care, and perhaps some could work with a lower sample rate. The brass thingy could probably be looped too, with the volume scoop handled in software. But this is already pushing the limits, and there are the FM instruments to consider. Doing them with pitchmod would eat too many channels; it's probably better to just use samples for most or all of them. It might be necessary to sacrifice some aspect of the guitar sample to fit everything in with room for the non-sample data...

The sound effects are right out. That's where all the Neo Geo brute force went. They'd need either major rework or on-demand streaming, maybe both.


Easily. Each of the eight channels has separate volume controls for left and right, as does the echo. The volume can even go negative, which gives you phase inversion; this is how games like Vortex do their Dolby Surround.


No, HDMA doesn't take much CPU. But you can't transfer uncompressed 32 kHz stereo with HDMA because it needs way too much bandwidth. So the CPU has to spend a lot of time giving the SPC700 a few bytes of data, waiting for an acknowledgement, giving it a few more bytes, etc. This is not fast. ~2 kB per frame is nothing for bulk DMA, but this is not bulk DMA.


Why? The BS Satellaview and Super Game Boy did it. I'd have thought the fact that the MSU1 itself didn't exist back then would be a bigger issue...


Really? So it's not as rare as I thought...

I wouldn't stream the sound effects, I would just load them into the SPC, and send a command to the SPC telling it to play that sound effect.

Is there a way to read the playback pointer of a given channel into the sample? I'm just trying to think of a way to do a real wave-table synth setup with a series of small waveforms (kinda like the PPG synth), without breaking the output stream of the channel and change the timbre on an internal level instead of a note-by-note basis. Can the DSP generate interrupt for when a channel sample block encounters a 'loop' point?

Well, I mean this wouldn't be the ideal thing to do, but if you have just about no space left for sound effects in ram, then you might have to.

I just think it's funny that you're learning about the non-traditional mechanics of SPC when you came here asking for an introduction, and for some reason the main topic has been streaming high quality audio or streaming BRR with HDMA and all this crap and it's like.. Is that seriously how you introduce someone to SPC audio hardware???

No!! It isn't!! We should be talking about the tradition of classic SPC music, which is not streaming, but tracking!!

Tracking is at the heart of SPC because it is sample-based.
1) Tracking -- you really ought to download a tracking application like Renoise, MilkyTracker, Schism Tracker ... these are the kind of sequencing tools people use to make sample-based music. If you actually learn how to do some basic tracking (Renoise has EXCELLENT tutorials -- google "renoise tutorial", here is a great example, the first tutorial to Renoise! : http://files.renoise.com/videos/Renoise ... rt%201.mp4 -- you might feel like you're learning Renoise but you actually learning also the fundamentals of every Tracker software

Understanding tracking is going to help you understand the fundamentals of how most games use the SPC -- and you will be able to visually see how most events will be parsed by an SPC driver. for basic level, we can say by rhythmically playing samples back at certain pitches and certain volumes.

Not only does SPC play the samples, it can shape them too. The most fundamental way to do this is by the ADSR envelope. Go, learn about it! There is also echo, pitch modulation, and noise, but these should be considered bonus topics until you understand the basics of tracking.
The SPC DSP has hardware ADSR envelope implementation, unlike most tracking software which define a software implementation. There is also a gain mode which has other ADSR qualities, or can be used in defining your own custom ADSR envelopes, I want you to know that but it's not something you should focus on.

Tracking then gets deep in-depth with "effects commands".. But I'm not going into that, I'm trying to lay a map for you. With the notion of SPC, we can consider effects commands as a way of modifying the DSP registers in interesting ways while the song is playing, for instance vibrato, which would alter the sample's pitch at specified rates, rates which may be associated mathematically with the BPM of the song.
-------
2) SPC and Tracking
How does the SPC rhythmically play music??? The answer is timers! The SPC has 3 of them!! You can do whatever with them --You set SPC to go off at a certain rate in time and you can base quarter notes 8th notes etc. from the timer.

But yeah!! once you have a timer firing, you can then play certain samples rhythmicaly!! That's it basically!

The rest is just special limitations of SPC700, and other Super Nintendo specifics.. but that's the nature of tracking and roughly how SPC correlates.


3) Choosing what song to play, or what SFX to play -- How does that work?
To do this, a protocol must be established, and the SPC must parse the SNES IO registers in the SPC loop, it checks for certain commands and command parameters on the SPC IO ports that you define.. when the SNES writes the trigger values and parameters, the SPC can react accordingly, ie "ie command:play SFX, parameter:#2" ..

4) Getting data to SPC from SNES
There is a communications protocol .. bla bla [I'm getting tired]


4) Putting it all together!!!
Not many people have put all of this together .. I am working on SNES Tracker which will do all of the above eventually.. Also there is pre-existing solutions like SNESMod and SNESGSS. But to actually put it all together, you will need ALOT.. and this is why for the most part people have relied on non-native solutions like SNESMOD -- which translates something originally not purposed for SNES into something that may work on SNES -- the downside of these solutions is that you can't hear immediately how they will sound on the SNES, for instance, especially if they use the SNES DSP-only effects like Pmod or echo.. -- SNESGSS is the closest it's gotten as far as "native" level released software goes... SNESGSS, along with SNES Tracker, uses an SPC emulator inside it so that the user can actually hear and interface with the "real" thing as he develops the music.

If you want to experiment doing things manually.. here's what you would do :
1) Use Bregalads BRR Tools and convert some small WAV file to BRR
2) Write an SPC program
. a barebones SPC program to play a sample. To do this, you need to decide a start address for the SPC program in SPC memory. let's say $200, then write a SPC program in something like TASM or wla-spc700 that inits the SPC and plays a sample.. primarily you must set FLG register, main / voice volume registers, voice ADSR/gain (use direct gain it's easiest), and set the DIR address, and create DIR entries.. I'll write a tutorial on this.. maybe.. maybe not..
You must have wondered what is DIR?? hehe
. include the SPC program and BRR sample in a SNES program that uploads to the SPC -- you need to learn how to communicate and send the data to SPC, but it is essentially just "send this many bytes from some place in SNES memory to some place in SPC memory, and maybe do that again from/to other places, and then start executing SPC from some SPC Address" .. that's it.

Maybe interrupt the spc700 every, say, 256 cycles to calculate if the next timbre change is about to happen or not, and change the sample directory when needed to.

The SPC700 has no interrupt sources wired to it. It has only the interval timers.

Hence "timers as interrupts.." == find an appropriate timer (3, one of which is high resolution), and evaluate an appriopriate interval to "interrupt on" -- but if you're doing "heavy" processing outside of your timer poll routine, you might sometimes arrive out of rhythm. I dunno what you guys are doing in-depth, and therefore cannot judge the effect of this possible circumstance and how it relates to your goal (real-time synthesis?)....

And if you actually build this thing, and you start incurring overhead and it's a problem, you can talk about curing this later, potentially with a less frequent timer interval... or please I invite you to summarize your effective repair of this situation, I know I am certainly interested in hearing the full development story of a synth on SNES.

Yes and no, -- although an interrupt cannot be generated, you can use timers and check the ENDX register. ENDX signifies each voice's arrival to the BRR end block. This will be the last BRR block before the loop is started, of course only if the loop is enabled, however I am not sure exactly when in relation to the decoding of the BRR blocks, that this register is updated.

from me to you:

ENDX:
[Byte] nnnnnnnn -- each bit = voice #76543210
n=0: BRR END not yet reached [from KON, or from last write to this register]
n=1: BRR END reached [roughly, not sure exactly where in pipeline this is updated, check FullSNES or ask NoCash]

A Voice's bit in this register is cleared each time it is KON [or all voices' bits are cleared if you write to this register],
and if desired, you can reset "only all" of the bits by writing to ENDX register <--- this last feature could of maybe been helpful if you wanted to repeatedly know when the BRR end block was reached during looping, rather than just only from KON, however its limitation is that you could only do it for one voice, since the whole register is clobbered on write.

Okay, no, there are at least three other ways to do something like that without streaming.

1) Wavetable synthesis, as tomaitheous suggested. (It's at least kinda possible; see the DKC2 credits.) If necessary, using two channels would allow chorus-type effects, mitigating the disadvantages of using short waveforms on a synthesizer that doesn't have a built-in chorus effect.
2) Use two channels, with one short low-rate sample for the bulk of the note and one short high-rate sample for the treble component, and just vary the relative volume of the high-rate sample. Not sure how good this would sound, but probably better than nothing, and it's the easiest option of the three. For certain sounds you might even be able to reuse the same sample...
3) Use the FIR filter on the echo, if nothing else is using echo. Could also possibly modify the filter on the fly to do a sort of phaser/flanger effect without using an extra channel, though I'm not sure how well that would work in practice 'cause I haven't tried it. Sadly there seems to be no way to hear the echo without the direct signal... What does EDL=0 do? Is it one sample or nine, or something else?

Other schemes may present themselves to intelligent cogitation. I'm not sure what all KFF is doing here - the saw filter seems to be similar to the DKC2 trick; the variable-pulse-width thing is something else, and there may be yet another trick in there - but whatever he's doing it works great (on synth waveforms, admittedly, not a distorted guitar)...

...you know, you can do a variable-width pulse wave by combining two phase-inverted saw waves and tweaking the pitch of one of them slightly to change the phase; I wonder if that's what he did? That also allows you to morph from pulse to saw by fading one of them out, and from any combination of pulse and saw towards sine using a lowpass filter or a wavetable (in this case moving to lower sample rates). Is there a name for this technique? I made a synth that did that for Emulator X, and had thought of doing the same on the SNES, but it looks like I might have been pre-empted...

That's a combination of pitch modulation and playing different samples...

I intend to enhance this effect with real time loop point modifications one day. I'm creating my own sound driver to do this job.

I remember reading about that trick from somewhere. It kind of reminded me of LA synthesis, where the attack phase supposedly the most hardest part in replicating an instrument sound. I mean, not exactly the same thing - but the concept was similar. Making a more complex sound by having a more complex attack. I had the idea that you could stream really low bit-rate samples overlaying that part of the attack in the sample. I was counting on the higher resolution waveform to hide the noise of the low bit-rate attack phase sample.



Not sure if this is the same thing, but I had this idea: http://pcedev.net/audio/sub_waveform6.xm (second pattern). The primary wavefrom has all sample data on the positive range of the waveform, and a second channel has all waveform data in the negative range (I forget the terms for this) - so when they 'accumulate', the effect is stronger. The volume controls the brightness of the sound, but it's obviously not enough. Instead, you think of the two waveforms as single waveform, and you 'walk' the phase of the second waveform in small increments. By advancing the frequency by a large amount and quickly putting it back - you're 'walking' the phase difference of the waveforms (you can do the opposite too; slow down the second warm and then put it back to the same frequency to retard the phase). Of course, you'll probably need translation tables. If the effect is strong enough, then you don't need to replicate on other channels (if you're doing chords), because the timbre sounding effect is strong enough to stand out. Though, I didn't really experiment with it much so I have no idea what type of waveforms are applicable to this approach.





Yeah, or some sort of approximation. It seems all the hardware was there to do so such a thing (basic wave-table synthesis, it's just missing a few small but key features).

Probably not doable on the SNES, but I also had the idea of non linear playback of a waveform pointer (like with 80's Casio keyboards). But that would require an interrupt. The idea is that you deform a waveform that has two parts, by stretching or compression the first and second halfs. The timbre changes are you change the mid point between these two points in the waveform. If you have an interrupt, you could do 'hard sync' as well. I did it on the PCE with a 7khz timer, but it was kinda noise-y/gritty.

Is there an easy way of getting an .spc file into a ROM? KungFuFurby's song is pretty epic. I also promised to use one of Augustus's songs a while ago.

An .spc file is 65kB, so it must be the contents of the RAM plus some kind of header.

The SPC has faster timers if it helps, one is 32,000 Hz.. the other 2 are 8000 Hz..



Besides the header(s) and RAM are also the DSP registers, and CPU registers.
http://snesmusic.org/files/spc_file_format.txt


^ is there a newer SPC file format I should know about for SNES Tracker?

This bit of inspiration from Roland LA synthesis is also why my NES music engine uses FamiTracker-style envelopes (at 2 bytes per frame, encoding arpeggio, duty, and volume) only for the attack and NerdTracker II-style fades (2 bytes encoding duty, initial volume, and decrease rate) for the decay or sustain.


I guess that means I need to get working on my proof of concept of half-bit-depth BRR using [-5, -1, 1, 5] and [-7, -2, 2, 7] quantization tables, expanded by either the S-CPU or S-SMP before being written to sample memory and played through the S-DSP. I've got so many things I could be doing that I need to put a list of projects I could be working on somewhere so that people can rank them.


Perhaps we need a spec for a simplified .spc for inclusion in a ROM that disallows things like overwriting $0000-$01FF and $FFC0-$FFFF, leaves initial DSP and timer contents unspecified, and includes a standard way for the S-CPU to tell the S-SMP to jump back to the IPL at $FFC0.

Do you guys write your music in ASM? If so, the ASM source file would be more useful when it comes to using music in homebrews.

I'm surprised how acceptable it is to use 2 channels for one instrument. I didn't notice any lack of polyphony. It could be that 4 simultaneous instruments is good enough for most melodies, or it's good enough to not use 2 channels for every instrument.

Ever since I got Noise Tracker for the Amiga, back in the day, I've usually avoided writing songs in ASM. I like to be able to see the relation bewteen notes and to be able to play back anything immediately. If I have a song that is already completed for the Amiga or the SNES, sometimes I will go back and make a version in ASM or MML depending on what machine it's for.



Depending on how many channels I have available on a given pattern I'll use anywhere from 1-5 channels for a single instrument with somewhat alternating volume envelopes or different octaves.



This is one of the techniques I like to use when I have the bytes and channels to spare.

Isn't that pretty much what pitchmod does? Though achieving that exact effect seems like it would require the modulating waveform to be modulated as well, meaning this scheme would burn three channels unless you got a wavetable going, or maybe KungFuFurby's variable-loop-point scheme, or something like that...

SNESGSS has exactly that kind of hidden feature. You'd have to rig the sample IDs without keying off and on, but I just pulled that off. Here... https://app.box.com/s/5sgjwijni14ef0bacm3sstejf29gwfgj

I didn't even use the tracker!

KFF, what exactly is happening here?

I simply messed around with the sample IDs while the note is playing. The SPC700 will simply fetch different loop points as it plays the samples when the sample ID is changed without keying on the sample again.

SNESGSS's change instrument feature directly messes with the sample ID and ADSR envelope, but doesn't key off the note automatically.

Be prepared for a barrage of questions!!!

So all the sample IDs refer to the same sample, but at different loop points?? Yee, but what effect have you exactly achieved here?? Is there a name for this, and does it require a certain type of sample waveforms to produce the effect? I have no idea what's going on, please keep filling in light on my dark places.

Are you setting the loop point to somewhere inside the initial sample, or B) into a new sample altogether??
In the case of B, how did you precalculate a variety of samples that would provide the desired effect when the loop points were changed? What effect is this??

Afterthoughts:
It could be possible to have one sample ID, and just change its loop address.. Is it because it was easier for you to use many sample IDs that you didn't do what I'm suggesting?? Well, in my case, you could have up to 8 sample ID's (one for each voice, this provides potential for each voice to simultaneously play this new kind of instrument), each one individually having its loop points updated, and the effect could be reset at a voice's KON/KOFF. My method would consolidate on sample IDs.

FYI I updated my previous post like 20 times.. please take another look at it

Technically yes, as I needed to initialize the BRR sample altogether. Using the same block allows the sample to start without incident, as my BRR converter (when using SNESMod) magically produced the same initialization blocks, so I simply removed duplicate blocks and matched the starting pointers (I also had to activate the loop flag in my starting BRR block: otherwise bad things could happen). The waveforms have to be relatively small in order for the effect to properly work. Otherwise, if you're rapidly swapping loop points, you'll skip "steps" of the waveform.


It's B for my SNESGSS demonstration. For me, the "pre-calculation" was really just me creating the samples in a hex editor (which is how I optimized them so that they would play properly in the first place).


This is a SNESGSS limitation. I can't just go in there and overwrite loop points like that. Had I coded my own sound driver, I would have indeed updated the loop points in the sample ID as they were playing. However, you have to put the sample directory in direct page (starting at direct page 100 or direct page 100). 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). KON/KOFF definitely resets this effect.

Somebody throw me a bone here, seriously!!!

What exactly has KFF achieved?? All I know in a rough sense is that he has sucessfully performed some effect on SPC, "emulated" by the use of rapidly altering loop points during a sample playback.. But from a general perspective, what did he produce. I'm looking for someone to say something like "KFF implemented chorus on SPC" -- I'm looking for that kind of explanation lol.

Why did you have to hand code waveforms? Do these waves have to be "simple" like square, saw, sin?? or does the effect you made work with "complex" waves, like a flute or piano sample??

Now, KFF, hopefully you're still reading, I have question based on your last post



You're being so vague.. init the BRR sample altogether?? "Using the same block" -- What block are you talking about? Initialization blocks?? What are those?? Why did you need the loop point set in the BRR start block, as I recall only the loop bit is checked in a BRR end block....

I hand-coded them on the grounds that I wanted fine control over the sample I was creating. I could have just simply snatched any old pulse wave sample and resampled it, but in this case, I decided to specially craft one and import it raw.



This effect works with more "complex" waves, where technically you can use this like a sustained loop point... although depending on the length of the sample, they may not respond to rapid modifications of loop points as well. You can in theory chop those "complex" waveforms into itty bitty pieces and play them that way.



This was actually only necessary in this scenario because of how I set up the samples (which meant I set the flag at the BRR start block). If you were dealing with one-block BRR samples, then that block would act as both a start and end block.

Setting the loop flag on the start block means at the end of the BRR block, the SPC700 will jump the sample pointer to the next BRR block as specified by the loop pointer.

My apologies if I'm still confusing you...

KFF, can you please tell me what effect this is?

If you tell me that, I don't even have to try to learn this from you, I can just learn it somewhere else.

I did respond to your last post and here were my thoughts:


but you still haven't acknowledged what is an initialization block -- is it synonymous in your lingo with BRR start block..

and you said "if you were dealing with one-block BRR samples" -- but that's not an IF, that's a MUST.. one doesn't set a loop bit in a BRR block that isn't the last block because it has no effect.. which doesn't tell me anything except that you are probably using BRR samples that are only 1 block long... but that doesn't help me understand what you're doing, and why say IF in that regards..?

Yeah you're pretty confusing dude!

I implore you to explain in full what you are doing. Or at least just tell me the effect so that I can be on my merry way

I think the effect is called granular synthesis.

ありがとうございます

KungFuFurby is this correct? or is this wavetable synthesis - in which case I recall the term thrown around earlier in this thread, but its fundamentals are above my knowledge levels

To me, granular synthesis sounds correct.

I really love what you're doing here KFF, I just don't have the time to invest in learning about this stuff right now

Ok, so I had some spare time to learn about granular synthesis, but I'm having a hard time tying it to get her to what KFF has done here..

In granular synthesis, from what I've read, you have a sample that is chopped into small pieces 10-50ms each for example, and then you control the envelopes and timings of playback of these grains, no???

KFF, if you wouldn't mind, could you tell me are you using one sample in this way, or several..

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

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

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?

I have no SNESGSS file. I literally created the file in a hex editor since I couldn't use the tracker.



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).

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.

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!

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).

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?

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.

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?

I scrolled through the samples in an even interval without randomizing ordering.

@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

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

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?)

And yet your method sounds like it works fine...

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.

Can you safely use multiple sample table entries to refer to the same physical memory?

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.

I recalled seeing such a state when viewing Kirby's Dream Course SPC's in my WIP SNES Tracker Debugger (std).

I cannot answer your question with regards to KFF's intended practice - but to answer the question bluntly, it seems quite normal to "use multiple sample table entries to refer to the same physical memory." Here it is seen being done in Kirby's Dream Course "Duel on the Dream Course." In the attached GIF, you see in particular a voice changing its DIR index between $0A and $0B even though they are the same. You can also see that a bunch of the unused DIR entries are identical as well. In this case, it is likely that this situation occurs from multiple non-optimized "instrument" references -- which contain other parameters outside of sample address / loop point. These instruments likely had aspects to them that were different (ie. ADSR), but all used the same sample / loop point / loop enable bit. These entries probably could have used the 1 DIR entry all together.

----------

I also took a look at KFF's Duty-cycle-changing SPC in my program - and have attached a GIF of that as well. Note that the slow framrate capture of the GIF does not properly demonstrate the exact transition. It is as follows in linear singular increments/decrements: $09 -> $18 -> $10 (repeat) This skips 6 entries in the return path (0F -> 0A).

-----------

That's all I have time for. Toodles!

No, no. I just mean having more than one sample ID for the same physical sample. That way one could use the trick you've described without having to double up on sample storage.


Okay, cool. I kinda thought so, but I figured it was safest to check. Nice to actually see it in operation, too.

The reason I asked is that for a while now, I've had the idea that if one could compress a long harmonic instrument sample by using a loop chain after the attack instead of the whole recorded note, one could do some rather nice multisamples on SNES. A degree of programmable timbral modulation could be had essentially for free by further modulating the loop position on top of the baseline motion associated with the instrument. I'm not sure how much compression would be possible without unpleasant artifacts, but it seems like it's worth a shot, and I intend to try it someday.

It seems to me that loop modulation synthesis has a lot of potential (and since it only uses one channel, it can be efficiently combined with other modulation techniques that use two, like pitchmod or frequency splitting). If this technique is as generally applicable as I imagine, it could revolutionize SNES music - at least, if sample preparation doesn't turn out to be prohibitively difficult...

...

@KungFuFurby: while we're here, what sort of data/sample streaming capabilities, if any, are you looking at with your engine? And are you likely to release it publicly?

For context: I recently tried to sketch a high-bandwidth HDMA streaming scheme that doesn't require the rest of the audio engine to run exclusively in VBlank. I posted code here and here; the methods are very similar but with a few different tradeoffs (and they're both totally untested and probably buggy if not outright unfeasible). Both of them lack a sync mechanism to protect long samples from over/underrun, but I don't think it'd be too tough to add - part of the HDMA table, perhaps, using an extra command and copying or piggybacking on the streaming start timing scheme...

I'm not really sure what I'm doing yet, but I'm going to want a decent streaming capability for my shmup port (and possibly other stuff), and the more bandwidth it has and the less S-CPU time it takes, the better. This is not a feature request; I'll certainly write my own audio engine if I have to - but if I don't have to I might decide not to...

That trick can also be used for sustain loops... but only to a limited extent because looping sections can't overlap (and it would be even harder to pull off a sustain and a non-sustain looping section in a sample, since the hardware provides limited information about the sample's position).

@bazz: Now you really have me curious... about the SNES Tracker debugger. I see that as being potentially very important for my own debugging. (I already manually compiled vspcplay, but I'm looking to go further) I'm aware of the source code on Github, although I'm not fully sure how to compile the tracker in its current state.

@93143: I intend on actually doing both samples (swapping and/or streaming) and other sound-related data (I think of music and SFX). Plus, I have ideas to have the music switch sections at a certain point based on a flag set by the SNES.

For transferring, I'm considering using a single byte as a sort-of counter (that would be $2140/$F4). First, bit 7 must already be set by the SPC700 so that the SNES knows that it can safely send a command ID to cue the transfer (the SNES always clears, and the SPC700 always sets: this is so that the SPC700 can properly receive the data, as I'm anticipating that read/write conflicts result in ORed data being read on either end). $2141/$F5 and $2142/$F6 represent a memory location (in little endian order), and $2143/$F7 represents a flag byte. Blocks of three bytes are used (these perfectly sync with BRR blocks), and the flag byte represents the action to take upon completion of the transfer of data (and it also accounts for whether or not the file is less than 3 bytes or if the filesize is not divisible by 3, which only affects the last block).

It'll be a long time before I'll be able to release it publicly. I have a sound format that I have defined, but it hasn't even been implemented yet (I have successfully fired off a few notes, though, and I have a dynamic timer event list with doubly-linked lists that is up and running). I'm tied up in college work and internships at the moment.

I invite any of you interested in talking more on your ideas with SNES audio to please consider conversing in #snestracker on ESPERnet on IRC. Also, please consider the forums on http://snestracker.club. I would love to help and/or harbor a community concentrated on these topics.

Admittedly, it is very unknown to anyone besides myself how to build it. I think I did that on purpose (tehehe) but it's time to start upping the support.

SNES Tracker (ST) is using cross-platform libraries to allow builds on OSX / Linux, and maybe Windows. The issue is that the build system is currently entirely concentrated on OSX. I am thinking of introducing autotools or CMake into the project now, so that others can start compiling. Let this also be a calling for anyone skilled with CMake who would like to get involved. I could use your help big-time.

Either do it by hand or consider tup. A lot of major projects avoid both autotools (automake/autoconf/libtool) and CMake. They're awful. Google "tup cmake" and you can read many success stories. But honestly, I just advise doing it by hand -- less dependencies = happier users. Can't help you with the Windows build portion -- that's going to be horrendously painful no matter what.

A lot of major projects also use it (some examples: KDE and LLVM). Personally I do use it. Not because it's perfect, but because a better alternative doesn't seem to exist.

Something like tup (and GNU make) can't replace CMake because they work on a lower level of abstraction: you still have to explicitly specify all the build commands, whereas in CMake you simply say add_executable(my_executable foo.c), and it will adjust the build commands based on the target generator (MSVC, XCode, Makefile, ...), platform, etc.

The scripting language used in CMake is somewhat quirky, but it does the job (it might take a little time to learn the quirks, though).

I don't know... I mean.. maybe the simplest thing I could do for now is just make sure it builds with MAKE on OSX / *nix platforms and then hopefully someone who wants it for Windows does the work and makes a pull request or something

Well, after realizing you used an acronym (and going to gme_vspc/std, where I finally realized where the source was located... that proved to be confusing), I actually found what I thought was std (SNES Tracker Debugger), found the makefile... and I realized that it has C++11 involved.

This puts the program in a similar situation with bass: the source itself is currently not compatible with my computer (in theory I can attempt to circumnavigate this, as I know of a few resources, but I'm nervous about taking this route).

In all honesty, I can't remember using cpp11 for anything other than Class Member Initialization, to aid in rapid prototyping class design. It's possible that modding all the initializers *could* be all that is needed to escape cpp11. Of course, I will be maintaining cpp11 at least for now to aid my prototyping, if nothing else. Time will tell if this dep becomes more critical.

C++11 has std::unique_ptr (a cleaned-up version of std::auto_ptr), anonymous functions (which combine with std::unique_ptr to make scope guards with finally semantics), std::shared_ptr (reference counted garbage collection), and auto-matic inference of variable types. To learn how to use its new features, try the book Effective Modern C++.

GCC 4.8.1 finished support for C++11, and the version of GCC in the repository of Ubuntu 14.04 LTS is GCC 4.8.4. There's also a PPA with GCC 4.9.

KungFuFurby: What operating system does your computer run?

Good news, I got SNES Tracker to build on Linux for the first time last night / this morning. https://twitter.com/imyourbazz/status/7 ... 1749334016 It still needs more "build automation" (how to do dependency (library) checking?) work. If I really need to avoid autotools like the plague, I may at least strive to create a simplified "configure" script that can discover if lib deps are installed, allows manual specification of their location, and prefix specification.

@tepples: Mac OS X 10.6.8 is my operating system.

Snow Leopard

Is it not possible to homebrew / macports install an updated gcc? At least, it may work for STD! Of course, after settling its other dependencies (more on this later)

I have tried Homebrew exactly once... on my iMac G5. This was attempting to compile Git on Mac OS X 10.4.11. My XCode version caused me to run into a brick wall on that one, as one of the libraries said I had too old of an XCode version. This is because I had come in for an unreleased demo. I never completed the song (being rather unfamiliar with "demo-style"... now when I think of demo-style, I think of Strobe's music from BOTB), and I have what little was made of the demo.

I successfully cross compiled STD from Linux to win32 -- largely a WIP but to actually see 90% of the program running made me hugely happy.

@KFF maybe I can find a way to compile and target your system somehow ... it looks like it could be a real pain in the butt though so I might forego. i have already expunged all of my energy to win32