It is currently Tue Nov 21, 2017 7:05 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Oct 20, 2017 10:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
In light of previous discussions about perceived barriers to the SNES homebrew scene and the samples included with Windows's built-in MIDI renderer not being the best:

Off and on I'm developing a music engine for the Super NES. Users of this music engine (or others such as SNES GSS) will need to produce music that respects the hardware's limits. Just as Bitbeam wrote a post documenting S-PPU limits, I'll document practical S-DSP limits.

  • A song should use no more than 8 voices, without Impulse Tracker's "new note actions". This means some techniques like chorus and chords will need to be baked into samples rather than using up a whole bunch of voices.
  • Samples that loop should loop on 16-sample boundaries. This is guaranteed if you resample middle C to a multiple of 4186 Hz or A440 to a multiple of 7040 Hz.
  • Samples should total no more than 81920 samples for a particular set of songs that a game can switch among without a blank screen load. When converted to BRR, 81920 samples represent 45 KiB, or 70% of the Super NES's ARAM, leaving the rest for the player and sequences.

With this in mind, how do tracked music composers find samples that are suitably short, sound good when looped, and are clearly free to use? Or should people on no budget be using squares, saws, Digitar plucks, and other things that can be synthesized as part of a game's build process?


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 10:41 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
freesound.org has kinda been the definitive place for permissively licensed samples for many years:
https://freesound.org/

There's a lot of low quality stuff there, but there's good stuff too. Takes some time to pick through the pile.


tepples wrote:
Or should people on no budget be using squares, saws, Digitar plucks, and other things that can be synthesized as part of a game's build process?

Synthesizing sounds is a really good way to make samples, especially since you can have extreme/perfect control over it. There's no particular reason be limited to simple things like square and saw waves, unless you like those, and there's tons of free synthesizer programs, VSTs, etc.

Synthesizing them as part of a build process is a bizarre idea to me though. I don't know why you'd want to do that. You should make the sample before/as you start composing with it. Building the game is far too late for that?


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 10:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Synthesizing them as part of a build process is a bizarre idea to me though. I don't know why you'd want to do that. You should make the sample before/as you start composing with it. Building the game is far too late for that?

Anything that can be synthesized at build time need not be stored literally in the game's source tree. They can be synthesized in advance (make samples) and sent to the composer as wave files, but only the instructions to synthesize them need to be sent to the CI server.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 11:05 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
There are other algorithms, such as PADsynth. (PADsynth works as follows: Make a table where the first half is filled with a sum of several Gaussian PDFs (at different amplitudes, means, and standard deviations), where each point is then given a random phase. Now, do inverse Fourier transform.)

One program I have written to synthesize sampled instruments is XISYNTH, which produces .XI output format (it can also produce raw output format if requested). It may be possible to adapt this for this use (perhaps by using a second program to perform the conversion, so that you can pipe them together), maybe. (It does implement PADsynth, Karplus-Strong, FM, and others.)

(AmigaMML, in addition to supporting external instrument files, also has a built-in synthesizer: # L designates a square wave, # V designates a triangle wave, # N designates a saw wave, and you can also combine them and change duty and other settings.)

Some algorithms might be slow, for example, I have found PADsynth slow, although other people have said it can work realtime.

_________________
.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 11:33 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
tepples wrote:
Anything that can be synthesized at build time need not be stored literally in the game's source tree. They can be synthesized in advance (make samples) and sent to the composer as wave files, but only the instructions to synthesize them need to be sent to the CI server.

I don't want to argue about this hypothetical bandwidth problem, but I don't think storing a few sound samples is a significant problem that requires a specialized solution.

If writing your own synthesizer that you can integrate with a build process seems like fun, go ahead and make it, but in terms of what's useful for making music: the composer should find/make their own samples and use them immediately. Don't limit them to some synthesizer of your own concoction, and definitely don't create a workflow where they have to play some telephone game of requesting something and you having to implement it and send it back. There's already a billion good tools for synthesizing sounds out there, so don't cut those off.


If you want something that already fits the programmable / command-line usable synthesizer bill, maybe you'd like CSound:
http://csound.github.io/

...but I wouldn't expect any composer to want to learn how to use CSound. This is just not a good tool for most people.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 11:41 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
rainwarrior wrote:
... Don't limit them to some synthesizer of your own concoction, and definitely don't create a workflow where they have to play some telephone game of requesting something and you having to implement it and send it back. ...
This is correct. You should be allowed to use already existing instrument files, rather than being required to only use the source files for the synthesizer.

I suppose a make samples command can then do nothing if there aren't any source files for synthesis, only copying the existing already made files. (You could also define your own make rules if you are using different synthesizers.)

Quote:
If you want something that already fits the programmable / command-line usable synthesizer bill, maybe you'd like CSound:
http://csound.github.io/

...but I wouldn't expect any composer to want to learn how to use CSound. This is just not a good tool for most people.
And Csound is a very good program; I have used it myself to write some music.

_________________
.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 2:03 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
I find the hard part, running from computer program to computer program, hoping that it sounds like how you want it to sound, and then finding out it's at a wrong pitch, or you looped it wrong, or it doesn't fit, or you down sampled it too much.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 6:40 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5825
Location: Canada
psycopathicteen wrote:
I find the hard part, running from computer program to computer program, hoping that it sounds like how you want it to sound, and then finding out it's at a wrong pitch, or you looped it wrong, or it doesn't fit, or you down sampled it too much.

In my experience making SNES music via tracker conversion, the disconnect between sample format and actual output has been a bit of a pain. My usual way of coping was to convert the sample from WAV to SNES format, then back to WAV to at least know what I'm working with.

A dedicated SNES tracker would be nice, or even just a VST program that emulates all the SNES music capabilities directly. A sample editor tool that can apply the 16-sample loop constraint, import and edit directly from the SNES format, assist in creating crossfaded loops, etc. I don't really think a SNES synthesis tool makes much sense, but a good dedicated SNES sample editor (sort of like RJDMC) would be great to have.

Tightening that iteration loop between input and feedback is paramount. It's exactly why Famitracker has done so much for NES music. You can hear what you're doing immediately and accurately.


Edit: Wow somehow I didn't know about SNES GSS being a tracker. How many trackers has shiru made now? O_o I gotta try this out...


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 6:51 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
In my experience making SNES music via tracker conversion, the disconnect between sample format and actual output has been a bit of a pain. My usual way of coping was to convert the sample from WAV to SNES format, then back to WAV to at least know what I'm working with.

I could make my WAV to BRR converter output an equivalent decompressed WAV.

rainwarrior wrote:
A dedicated SNES tracker would be nice

I ought to start a new topic about joystick input methods for trackers.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:41 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
Quote:
I don't really think a SNES synthesis tool makes much sense, but a good dedicated SNES sample editor (sort of like RJDMC) would be great to have.


If the program can accept VSTs, and record directly from them, that would be great.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 7:55 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
psycopathicteen wrote:
If the program can accept VSTs, and record directly from them, that would be great.
I doubt it makes sense it this case to use VSTs (or any other similar kind of plugin format, such as LADSPA, also doesn't seem suitable here either).

However, the program to convert audio into the SNES format (and from the SNES format, to make the lossy output) might be useful to have.

_________________
.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 8:09 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2361
If it can accept VSTs, then you don't have to save millions of samples that you would have to convert to BRR anyway.


Top
 Profile  
 
PostPosted: Fri Oct 20, 2017 8:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19238
Location: NE Indiana, USA (NTSC)
zzo38 wrote:
the program to convert audio into the SNES format (and from the SNES format, to make the lossy output) might be useful to have.

As part of my ca65 LoROM project template, I made WAV to and from BRR in 265 lines of Python, including pre/de-emphasis to compensate for the Gaussian filter.


Top
 Profile  
 
PostPosted: Sat Oct 21, 2017 7:54 am 
Offline

Joined: Wed Jul 09, 2008 8:46 pm
Posts: 238
psycopathicteen wrote:
I find the hard part, running from computer program to computer program, hoping that it sounds like how you want it to sound, and then finding out it's at a wrong pitch, or you looped it wrong, or it doesn't fit, or you down sampled it too much.


Pitch is not as much of a concern for me, as I use Schism Tracker and Mukunda Johnson's SNESMod to test my conversions (Schism Tracker doesn't auto-tune, but I can enter a nice default pitch value in there). SNESMod itself can handle the tuning fine, although I do have to watch out for pitch limits (it's 128,000hz, and Schism Tracker can technically tell me when I'm going over if I have the right view present while playing the song).

I don't use SNESGSS due to a combination of a platform incompatibility and what I found out about the sound driver looking at what it uses for pitch adjustments (I thought I could, in theory, simply implant my own samples into a compiled version of the sound driver. I found a complication in doing that via the tuning, citing a failure to adjust for octaves). However, I also knew of a trick with the sound driver that allows me to pull off a synth-like effect (although I don't create the samples in real time, instead I simply store all of the segments in the SPC700 at once and then change the ID back and forth).

Plus, I'm tempted to just create my own sound driver, as I have discovered several weaknesses within the sound driver I currently use (and I have some theoretical pitch tuning code I could use with the help of a lookup table for multiplication and a constant to start with).

On my end, it's more along the lines of testing special features, such as pitch modulation and noise (I made special modifications in order to get this to work), and some unexpected side effects, especially the way SNESMod handles its envelopes. Plus, panning effects, under any circumstance, could be a challenge to get sounding good due to hardware limitations, since there's no automation for changing the panning within the hardware. In addition, I sometimes deliberately keep a glitched conversion of a sample to use in the song.

I have another note: if your attack is instant and you choose to start your sample immediately, take special precaution with the first few samples (the first 8 are what I note down). I usually do an 8-sample fade if I find my conversions getting a bit too much pop to tone down the effect.

I have a simple idea running through my head: why not create a WAV to SPC converter, with code that simply plays back the sample in question (you'll have to manually define a pitch)? It makes for a very quick test of your sample to see if it sounds correct to your ears.


Top
 Profile  
 
PostPosted: Sat Oct 21, 2017 8:24 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
KungFuFurby wrote:
I have another note: if your attack is instant and you choose to start your sample immediately, take special precaution with the first few samples (the first 8 are what I note down). I usually do an 8-sample fade if I find my conversions getting a bit too much pop to tone down the effect.

I have a simple idea running through my head: why not create a WAV to SPC converter, with code that simply plays back the sample in question (you'll have to manually define a pitch)? It makes for a very quick test of your sample to see if it sounds correct to your ears.

This almost makes me think there's some kind of bug in how SNESMod handles its BRR conversion. Everything I've fed into SNESGSS sounds just fine.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group