How to Use C700: Tips and Tricks for .spc

Creating an .spc in C700 without overflowing on memory is a fair bit trickier than using the .smc output, but it is absolutely doable if you know what to avoid, as well as where you can cut corners. You may have to get more hands-on with MIDI information than you're used to, but hey, isn't that good practice?

In the newest version of C700, if you do cause a memory overload in recording .spc, a second file with extension .700 will be created. Similarly to ROM export, this extra file is where song data is offloaded to. This feature is not widely supported, although SPCPlay will play them if they're in the same folder with the same name. In this case, the actual .spc file will contain no song data, only samples and other necessary components. Prior versions of C700 simply created .spc files that eventually hit their limit and stop suddenly (which was only testable through playback). If you see a .700 file, your .spc overflowed, and you will have to reduce the amount of data in your song in order to receive a fully working, independent .spc file. We will now cover some tips for making that happen.

Regarding Storage Space

Since your .spc has to contain samples, song data, echo delay, and sound driver info, all neatly compacted into 64KB, storage space is going to be tight.

At the very bottom-right of C700, an indicator is shown of how much memory is being consumed by everything but song data. That means the samples, the echo delay time setting, and the sound driver, but not all the notes and other MIDI data that comprise your song. Unfortunately there is no way for C700 to know how much data your song will consume until it tries. Adding samples or increasing Delay Time will increase memory consumption. The indicator turns red if you exceed the allotted space this way (and you may have to restart your DAW after resolving that issue; playback can be glitchy afterwards).

For making .spc specifically, it's best to ensure this value is under about 40000 bytes (40KB), although depending on how much MIDI data is contained in your song, your mileage may vary, and you may need to go much lower! If using ROM export instead, you may get quite close to 64KB (again, it will turn red if you exceed maximum size).

Pitch Effects

Perhaps the single easiest way to bloat the memory of your song is with a pitch effect – things like vibrato, portamento, or pitch bends. This is because every small change in pitch is a piece of data that C700 is recording. That data adds up far quicker than you'd expect.

This makes MIDI CC#1 (Modulation) completely unusable on an .spc – pitch changes are written constantly, even during silence on channels where it's enabled! You will instead have to program your vibratos using your MIDI channels' "channel pitch" control, as shown in the example below (FL Studio).

In fact, if you want to be using much vibrato at all, you will have to get very comfortable with MIDI channel pitch. Using very fine pitch data like the left portion of example above will quickly overload your song. You can save significant space by drawing over it at a higher grid size, such as on the right portion of the example above, where it is snapped to 1/6 step (or 1/24 beat). There is virtually no perceptible difference in how it sounds at this level, but it is still relatively dense information (24 pieces of information per beat), and consumes a lot of data. Should you choose to go further and save more space, a vibrato fineness of 1/4 beat is about as low as you can go while still getting a convincing vibrato sound.

Glide/Portamento is another dicey feature to utilize in .spc, but it can be done! You will have to use the MIDI CCs for Portamento: CC#65 (Portamento Enable), CC#5 (Portamento Rate), and optionally CC#84 (Portamento Control) which sets the note to glide from. If enabled on a sample globally, it will probably consume too much data over time, so using CC#65 to toggle the feature off and on selectively is recommended. The longer your selected Portamento Rate, the worse the additional data consumption will be.

Protip: If using automation to control any of these parameters, be sure there are no fine curves or slopes, and avoid unnecessary changes in parameters. This reduces the number of times C700 has to record new data.

Volume/Panning Fades

Similarly to pitch effects, gradual changes in volume or panning will quickly consume valuable song data, and are best implemented using less fine event data or automation, such as reducing a volume fade-out from a smooth slope to a slope with new points every 1/4 beat, as in the example below. (You can go finer if you want, but naturally more data will be consumed.)

When making an .spc, careful use of envelopes is preferred to using volume event data, for the most part. (We learned about envelopes in section D!) If only a few fade-outs are desired, you could automate SR1 (MIDI CC#82) to occasionally switch to a different value instead. This would both save space and avoid the slight noise created by volume event data (described below), if its presence bothers you.

Note that reducing this value much further may brush up against an SPC700 chip limitation which causes a small "crackle" or "pop" sound to occur when volume or panning shifts a large amount very suddenly. In this example, if a note was playing during the immediate shift halfway through, a "pop" would be heard. (This is true of .smc and other tools' exports as well.) In fact, a small "crackle" is always being produced during volume or panning fades, but it is only particularly noticeable during an immediate faraway shift.

The following info and demonstration are useful for both .spc warriors and .smc mages (be warned they are a bit loud):

EXAMPLE 1 (sine wave)

EXAMPLE 2 (square wave)

Both of these examples consist of a single held note across the above two bars of volume event data. Note the "pop" sound that occurs halfway, and note the "crackle" sound behind the sine wave in particular (which has no overtones to mask the crackling). Since we're hearing these sounds solo, the impact is more noticeable in the examples than it might be in a full arrangement, but this quirk of the soundchip is still significant. Fades of volume or panning will create slight crackling noise, and this noise becomes much more perceptible in the event of a huge, immediate shift.

Note that no popping/crackling will occur if the channel volume (or panning) shifts while no note is playing, so if you desire different volumes between sections, change the setting during a rest. Data will still be consumed even during silence though, so don't use more event data than you have to.

Protip: Much like with pitch effects, don't leave any fine curves or slopes in automation data. They will quickly consume a ton of space.