KungFuFurby
Offline
Augustus Blackheart wrote:
KungFuFurby wrote:

I'd be doubly happy with noise generation and pitch modulation (as well as the type of muting that allows pitch modulation to pass through). I've especially been a fan of pitch modulation lately, since I hacked SNESMod to add both noise and pitch modulation features for some of my songs.

Nice!  I've been meaning to look into this whole pitch modulation stuff.  Any plans to release your changes to SNESMod?

I have the binary on hand, although my method of implementation would require a hex editor to test .spc files. I just simply copy the binary to its predefined location (where the SPC700 code is loaded), then put in a #$03 into #$01F4, and a #$01 into #$01F5. If you want to start anywhere other than order number zero, just modify #$01F7 to be your desired order number.

It's also not completely safe for video games because there aren't any checks for the sound effects on the last two channels (it's especially bad if noise were to be on those two channels... although pitch modulation can allow for some unusual effects to the music through the SFX if you want really unusual magic.). Technically I could make it public, but it would come with a few caveats... one of them being global volume should always be maximum, or else your pitch modulation might be weak. Technically the binary is already rippable if you look up my SPC files that use them. Just copy the data from #$0500-#$1AF6 in the SPC file and paste them into your own compiled copy (or save it for SNES ROM use) and there you go, your own SNESMod with pitch modulation and noise. But for everyone else's convenience, I'll just put the binary up here:

Get SNESMod with Pitch Modulation (.bin format)

The amount of bytes this takes up is dangerously close to where the module file starts (at #$1B00 in the .spc file)... a mere 10 bytes left. Thus, I would have to update the source code for the converter if I were to make additional modifications to account for pointer modifications to the module (and I can't build Windows or Intel Mac binaries from here because I have XCode 2.0... yeah...).

You need your instructions for how to apply pitch modulation to your modules and all you need are these brand new effects (not used by Impulse Tracker):

S05 ~ Turn on pitch modulation for one channel
S06 ~ Turn off pitch modulation for one channel
S07 ~ Turn on pitch modulation for all channels
S08 ~ Turn off pitch modulation for all channels
S09 ~ Turn on noise generation for one channel
S0A ~ Turn off noise generation for one channel
S0B ~ Turn on noise generation for all channels
S0C ~ Turn off noise generation for all channels

S1x-S2x ~ Noise frequency (take away 10h to get your frequency)
Warning: Noise frequency applies to all channels that have noise on

S92 ~ Mute channel (but still give it an output for pitch modulation)
S93 ~ Unmute channel

These might overlap with unofficial add-on effects that have been applied since the original Impulse Tracker... but SNESMod doesn't support those effects in the first place. Thus, I use them for the bonus features instead. They might affect playback when you're originally making the song in an unintended fashion, just to note.

I am able to get away with this for pitch modulation and noise generation because of the DSP register setup, which means I simply recycle the echo code with some parameter modifications. Since SNESMod uses gain to fool around with the volume, I can simply zero out the actual volume to perform the channel mute that allows pitch modulation to pass through.

I end up doing many more builds when using pitch modulation and noise because I have to double check and make sure they're not accidentally carrying over to other channels (plus, I have to make sure they sound good). I actually have a very good sine wave on hand if anyone wants it in either .brr format or in an .it module (it uses a non-zero loop point because I couldn't get a proper sine wave with a loop point at the start of the sample). I also have my own set of pulse waves that I use for my SNESMod songs that I manually created through creating them in a hex editor then saving as .txt and raw importing them into Schism Tracker.

potato-tan
Offline
ncie
KungFuFurby wrote:

I actually have a very good sine wave on hand if anyone wants it in either .brr format or in an .it module (it uses a non-zero loop point because I couldn't get a proper sine wave with a loop point at the start of the sample). I also have my own set of pulse waves that I use for my SNESMod songs that I manually created through creating them in a hex editor then saving as .txt and raw importing them into Schism Tracker.

When I make my seamless-looped BRRs, I set a start/end loop point in OpenMPT to make sure they're multiples of 16, then I chop off the end of the loop using the Edit>Cleanup function. I export the .wav and import it into Audacity.

In Audacity, I go to File>Export and export as "Other uncompressed files", clicking on "Options" to set it to export as a headerless RAW, signed 16-bit PCM. I also make sure to clear the metadata before clicking OK.

Then I take the .raw's filesize (not on disk) in bytes and do "64-(<filesize>mod64)" and whatever value it is, I insert that many "00"s to the top of the file via a hex editor. I import it back into Audacity and export a .wav, then import a "looped sample" into SampleTool with a loop point of 0, click "Play" and steal the "temp.brr" from the tool's directory. (snesbrr likes to add silence near the end of the loop for some reason, and SampleTool can prevent that)

Finally, I import the BRR into C700, insert the loop point OpenMPT gave me, tweak the loop point a bit (it shouldn't be too far off) and export the final BRR.

It's a total pain in the butt, but it's the best method I know of, and thought I'd share it with you all. Special thanks to Vitor Vilela for all this information.

Augustus Blackheart
Offline
Ballard, Washington
KungFuFurby wrote:

I have the binary on hand

Sweet.  Thanks.  That has been on my list of things to do for so long.

If it's helpful to anyone I added it to sneskit+examples; add -D PITCHMOD to ASFLAGS to select KungFuFurby's version.

Most of the examples here are Anthrox demos slightly modified to use some of the SNESKit stuff.  The only thing using sound right now are the two snesmod demos and the pitchmod demo.

I will try to update with more documentation and such as soon as possible.

If anybody needs any help with this stuff or would like to help  make more examples message me.

http://www.morganleahrecords.com/august … kit.tar.xz

edited to update link; added snesgrit info and 63mbit template.  Archive updated August 8th 2014.

Last edited by Augustus Blackheart (Aug 9, 2014 3:21 pm)

MCM Productions
Offline

On a side note - because I'm doing SNES style stuff, but by using ModPlug Tracker and saving my "source files" to the .IT format.

My question is this - if it's really true that a SNES music tracker in the works - I'm wondering about these things...

(1) Will it allow .IT files for importing (provided that we have no more than eight channels)?
(2) Are we able to export our works to .SPC from the SNES music tracker itself?

Reason being is that as I said, I've been doing SNES music style stuff via ModPlug Tracker (saving them to .IT files as the "source files"), and I've always been curious to how they would operate if they were converted to the .SPC format (and yes, I already know there's an .IT to .SPC converter out there; the only case is making sure that it's done right - but I'm not confident in THAT process... yet).

ferris
Offline
Oslo

mcm:
1. It hasn't been something I've considered. For the most part (notes + samples etc) it's trivial, but things like pitch bend effects and stuff probably don't necessarily match 1:1 with what .it specifies (our tool may bend stronger, for instance) and covering all of those corner cases isn't something that sounds very practical. Maybe it's easier than that; I mean, if nothing else I could always bolt one on there and leave those issues for you to fix in the tool (which I find pretty reasonable actually). If nothing else that would get you one step closer smile .

2. The tool is a PC tool that currently exports .spc's, prebuilt rom's and a somewhat botched source export that allows me to get the dumped music as source for demos but isn't really useful for much else yet smile .

KungFuFurby
Offline

Wait... the tracker itself is for PC??? Or is it an actual native SNES tracker that could be run through emulator?

If it were an actual native SNES tracker, then I could in theory just simply dump .spcs straight out of the tracker through emulator and then use the .spc files as is... mostly. The only modification I would have to make is to the loop points if the sample loops, because the loop points are stored in the ROM as offsets from the start of the sample. The .spc automatically makes the loop points based off of these offsets.

Also, is the aforementioned PC tool a command line utensil, and would the source be available?

For whatever reason, I'm getting the unusual sensation that this could end up like MTV Music Generator 2 or Digital Hitz Factory (both PS2 games)... or Famitracker. So far, the musical data format (which I reverse engineered directly from the .spc) is on a per-channel basis, and it looks like it's synched up to a certain delay value.

ferris
Offline
Oslo

kungfu: Looks like you've been spending a lot of time pulling apart my rom's big_smile The tool is a pc tracker like famitracker for snes.. superfamitracker I guess smile . There's a replayer that's a native rom, but it's in a VERY early state atm. We'll plan to be able to mute channels and stuff on the fly; it'll be mainly for playing back tracks live.

the main reasons we opted for a pc tool are for comfort: you really want to be tracking without the ram limits on the actual system, and you want to be able to reimport/encode samples very quickly on the fly. Since processing samples externally is a huge part of the process, iteration time needs to be as fast as possible. You can import .wav's whenever and there's an indicator for when you've gone over ram limit etc. It's pretty shit to try and track with samples and stuff with 8 buttons and a d-pad too, I'd imagine XD . Sure, LSDj gets away with something simpler, but so's the medium wink .

Also, this really simplifies the data model while actually working on the song, so the tool is inherently much more simple/stable. It's just less code smile . All the spc-specific transforms (minus sample encoding really) are done on export - pattern data gets split up into per-track components and compressed, samples are chopped at the loop points.. those kinds of things. But I guess you saw that stuff already ;D

so no, not a command line tool, as it's a full tracker. And it'll very likely be open source. Actually, the spc emu core that the audio engine is built on already is: https://github.com/yupferris/SamuraiPizzaCats (not done yet, but pretty close to what will ship in the tool. Better resampling and postproc are really all that remains for that purpose).

MCM Productions
Offline

Well, I do know this for certain - as we Super Nintendo music enthusiasts know - in terms of channels - this tracker obviously has to "emulate" how many channels the Super Nintendo sound system has -- which is eight channels. Any more than that, and we've got problems. Major problems.

But what about samples themselves? Are we able to import .wav/.brr files (provided that the loop points, if any, are included with them) as well? That's what I'm also trying to solve.

ferris
Offline
Oslo

mcm: of course! the whole goal is to impose "what you hear is what you get" - the ram expansion in the tool is the only difference, and as I said, there's an indicator for when you go over smile . The rest of the audio engine is pure snes apu emulation; there's echo, noise and pitch mod too.

for samples, there's currently .wav import and .ins, which is a format I made for ripping/testing from other .spc's. It's basically just .brr with some metadata like loop point + envelope info, wrapped up in bson for extensibility.

Last edited by ferris (May 8, 2014 8:58 pm)

potato-tan
Offline
ncie
ferris wrote:

mcm: of course! the whole goal is to impose "what you hear is what you get" - the ram expansion in the tool is the only difference, and as I said, there's an indicator for when you go over smile . The rest of the audio engine is pure snes apu emulation; there's echo, noise and pitch mod too.

for samples, there's currently .wav import and .ins, which is a format I made for ripping/testing from other .spc's. It's basically just .brr with some metadata like loop point + envelope info, wrapped up in bson for extensibility.

By the way, will the coarse/rough tuning values from the instrument table be included in the .ins files? Also, are there plans to implement Gain release, and will ADSR release behave like N-SPC? I was also wondering about the pulse-phasing effect that Romancing SaGa 3 does in some of its songs. Regardless, this project is looking awesome so far!

EDIT: Whoops! I forgot to ask about inverse/surround panning values too!

Last edited by potato-tan (May 8, 2014 11:03 pm)

ferris
Offline
Oslo
potato-tan wrote:

will the coarse/rough tuning values from the instrument table be included in the .ins files?

well, the ones from the tool will likely include this info, but in terms of instruments ripped from games, it's kindof guesswork at that point, so they'll probably be left out in that case. This actually isn't something I've addressed yet, so I'm glad you brought it up smile

adsr is a hardware thing, so it behaves how it behaves smile I'm currently working on a nice viewer for editing them, so it should feel pretty comfortable. Gain release will be supported.

As far as inverse/surround pannings, that's something I'll have to evaluate later. Again, not something I initially thought about smile

Also, do you have an example of that romancing saga3 stuff? never heard it myself smile

potato-tan
Offline
ncie
ferris wrote:
potato-tan wrote:

will the coarse/rough tuning values from the instrument table be included in the .ins files?

well, the ones from the tool will likely include this info, but in terms of instruments ripped from games, it's kindof guesswork at that point, so they'll probably be left out in that case. This actually isn't something I've addressed yet, so I'm glad you brought it up smile

adsr is a hardware thing, so it behaves how it behaves smile I'm currently working on a nice viewer for editing them, so it should feel pretty comfortable. Gain release will be supported.

As far as inverse/surround pannings, that's something I'll have to evaluate later. Again, not something I initially thought about smile

Also, do you have an example of that romancing saga3 stuff? never heard it myself smile

Thank you for the quick reply, and I'm really glad to hear about the ADSR and Gain release features! Here's an SPC from an Romancing SaGa 3 RSN: http://puu.sh/8FfhF.spc

In this SPC on channel 1 and 5 at 0:23 into the song, there's a waveform modulating on the fly. It's possible to change the speed of the modulation, and is featured in an MML compiler! (AddMusicM, to be specific)

Oh and another question, will there be hex value input for settings like ADSR/Echo/FIR input? Over the years I've grown accustomed to working in hex for that, and I think it would be helpful to have implemented. Thanks again!

Last edited by potato-tan (May 9, 2014 11:54 am)

KungFuFurby
Offline

I actually have an idea for sample swapping that is theoretically possible with a sound driver. It's just that you have to do data importing and it is best done with sections of music that can loop while the samples are loading to avoid glitching (expect some samples, defined by the user, to be overwritten as samples are swapped in and our). The same can be done with actual musical data, meaning dynamic music is possible by importing sections of musical data whenever needed (or all of the data can be loaded at once and instead special branching commands can be put in there that are affected by whether or not a certain user-defined flag are set). Main problem is that this can't technically be done in .spc format (unless you want multiple .spc files for each section).

Also, I would recommend that it be able to support multiple songs in the SPC700 RAM (or even start from any point... your sound driver as-is appears to be able to support this feature on a technicality). I've invented multiple music modifiers in which the result is banked music in the sense that a variable number of songs were stored in the SPC700 RAM.

All that needs to be added on is the ability to make some sound effects (one channel or multi-channel), some command IDs to send them over, and you've got yourself a functional sound driver that could be used for a game.

ferris
Offline
Oslo

potato: thanks for the spc! I'll definitely take a look at this soon. Also, hex will be supported for sure smile

kungfu: yep, sounds pretty standard smile . The driver will certainly support all of these things in some form or another (as soon as there's commands that can move around data most of your issues are already solved on a technical level, excluding stuffing it all into just an .spc as you mentioned). The hard part will be to figure out the abstractions in the tool and making it comfortable smile . It may be that compilation tools like that could be a additional programs actually - where the tracker tool is then used for instrument/sample prep; not necessarily organizing it all. We'll have to see when things are a bit more finished.. for now I'm just focused on making a great music composition/playback tool.

cTrix
Offline
Australia

Hey guys - update:  I'm playing a show on the weekend with a SNES using tunes built with the Alpha 0.0.7.  It's only going to be an 8 minute section of the show -  but I'll see if I can record it so you can hear the SNES in replay.

For all the technical questions - esp about ADSR and BRR techniques, etc - by all my accounts, the tracker and SNES output are very similar right down to the glitches in BRR looping to the ramping on the ADSR being spot on.  There is a slight difference in the brightness of the DAC .... everything in the tracker space is (at this point) slightly brighter.  However, with a treble boost on the SNES side... it sounds fine and very similar on real hardware.  We've been discussing implementing a modelled filter in the tracker replayer - but then again, every gen of SNES sounds slightly different (and also hums differently!).  Put it this way if perfect emulation worries you : our tracer is close enough that I'd happily play tunes live on a SNES even if I didn't have the chance to test the binary on real hardware before a show.  And if all else fails, fist pump and the crowd won't notice it sounds a bit muffled.

As far as when the public beta will be out - can't quite lock that down yet.  Ferris been workin' hard on the codebase to add more of the vanilla essentials (think everyday features like select, delete, copy, paste, undo! Oh, and a labelled interface too.)  It's been built backwards to what you'd expect - hardcore features first - basics last.  Meanwhile, I've been working on breaking each of these.  And I always seem to find odd ways to break the compiler because I'm trying to push each experimental build to it's limits :-P  Once something is stable, includes most basic features, and has a finalized native save format that will remain forward compatible - we'll get it out there.

End goal in sight : just workin' around various day jobs and demo parties ;-)

Last edited by cTrix (Jul 11, 2014 10:20 am)

potato-tan
Offline
ncie

Thank you for the update! It's a shame to hear about the difference in sound, but I'm glad to see the project in full motion. Good luck with the remainder of the project, and I hope your show goes well!