Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
A couple features that I requested of jsr in IRC a few years ago that people are really starting to use now:
1.) The ability to import a WAV, tune it to C, >B, and #A. Then map the samples to the descending "octaves" of your choice. That way exporting tuned DPCM sample octaves is easy and quick. A good use for this would be in One Hour Battles or One Hour Competitions.
2.) The ability to use "bitcrushing" on DPCM samples. I posted a proof of concept on the technique a few years ago here before RushJet1 put the technique in RJDMC. Basically once the DPCM sample is imported, you can edit it by increasing the value of every other (or every Y) byte(s) by X. This can make a clean guitar sample sound like a distorted guitar sample or many other neat sounded effects.
This could also be made into a tracker command since the NSF mapper could edit the sample values and keep a copy of it somewhere in RAM to revert back. If it is to be exported to a hardware mapper, MMC5 is able to turn ROM space into RAM space. DPCM could be edited on the fly for some really interesting effects.
3.) The ability to set up $4011 instrument macros that has a channel preference priority. This could allow for triangle volume macros and/or some very interesting effects at higher refresh rates.
4.) Sample loop mode. To quote Jarhmander on the NESdev thread (http://nesdev.parodius.com/bbs/viewtopic.php?p=97184&sid=47f984c2e857eaafe2d19aa572bc2290#97184): " The "weird hack" is only a change of the meaning of "IRQ DPCM mode" : it plays the sample in looped mode, but then immediately rewrite $4012 and $4013 with the last two bytes of the sample (added to that purpose) to change the loop points in the sound. Works on real hardware, but is likely not useful to anybody else. I can explain it more and post a demo of it in action when I have the time."
This could allow for playing samples and adding a loop point to them; like many modern trackers do for samples today. It could be used in the DPCM edit column, and should be able to be used en masse with feature request #1. This could make a lot of nice string vibrato or organ etc. samples. :D
In the NSF spec, if FDS is enabled, the DPCM area is considered RAM, actually (well, 8000-FFFF is RAM the disk gets loaded into). I'm not sure how many players support this, but it was important to make FDS game rips easier. I don't think any games used it to runtime-edit DPCM, but it was a capability of the FDS.
For doing your "bit crushing" operation, though, now that Famitracker has DPCM bank switching you can crush your samnples offline and just upload a whole set of them.
I've been wondering about DPCM loop points for a long time. I think jsr might have thought about them at one point, but probably never got around to it, but yeah, start playing the sample, and you can immediately change $4012/4013 to set a loop point. Lots of people could use this, I think, though I haven't seen any original game that did it. The only problem I know about with this is that the loop points are really granular; addresses are aligned to 64 bytes, so this means you can only set a loop point every 512 samples.
B00daW: I find strange that you quoted my ppMCK stuff here. I think the hack is cool after all.
Note that the DPCM IRQ mode is specific to ppMCK; it's the last parameter to the @DPCM macro definition. I think FT does not have such a playback mode because it is useless with ".nsf"s, as you can't write IRQ code unlike a ".nes".
I don't think the $4012/$4013 rewrite hack will be on FT because of its too "specific" nature: usage of looped samples (for melodic purpose) is very rare in the first place.
rainwarrior: yep, it is difficult to get good sounding looped samples with the low resolution address and length of sample playback; this is why I made my own DPCM converter and a Lua script to find the length of the loop for several notes within a tuning tolerance. [url=https://dl.dropbox.com/u/5476016/dmcfreqs.txt]Here what my script outputs for example. The script simply tests several harmonics of the DPCM repetition rate (length) and check if it gives a note tuned enough, and prints all results twice: ordered by length and ordered by note.
My DPCM converter then is capable of changing the scale, octave and tuning of the output sample (simple sample stretching, but using very good sinc resampling) and is "interactive" so I can listen to the result at the same time. It simulates the non-linear mixing so I can hear the DPCM getting quieter when the DAC gets high, and I can test my loop points in it, so I know how it will sound at the end.
Some may think it would be cool to get that DPCM converter but, while being efficient, it is roughly as user-friendly as [url=http://en.wikipedia.org/wiki/Vi]vi, if not less, so it's not targeted to "normal users" (I just didn't want to make a nice command-line interface after all), plus I did it on Ubuntu, so I don't have an executable ready for Windoze, and finally it requires a C++11 capable compiler.
Xyz_39808: Sure you can do it with Xxx and Yxx, but is very tendious too; my hack to ppMCK does that automagically based on information appended to the sample, so it's far nicer to use.
rainwarrior: Very good to know about the FDS. I wasn't aware of that ability. Also regarding the bankswitching, I was pleasantly surprised to find that out a few months ago. However I stand determined believing it would be easier and more effective to do everything within the tracker. Bitcrushing could be done in the sample editor and on-the-fly as a command. With the bankswitching, there should be enough RAM to keep a lot of template samples around.
Necrophageon: Pretty much.
Jarhmander: NSF2 supports IRQs. NSFPlay and FamiTracker can hopefully get this started. All NSF2 needs is a standard of track/author/copyright/etc that could be loaded on hardware. That is Kev's only requirement. We could use a basic compression algorithm like LZSS. http://membler-industries.com/tokumaru/
Currently we have multi-track NSFs. If NSF2 is able to name the author, title, copyright, etc of each track, genre... Basically able to document everything there is about the tracks. Is it a song, a jingle, SFX? Be able to have the ability to do very long track names or author names. We can basically cram as much information as possible into the header for documentation sake. NSF2 is ready to ship except for one person or the community as a whole deciding on how to get it all down.
For example, people didn't like NSF so they made NSFE. Some people still don't like NSFE. With the added features and capabilities, it would be best to have the both worlds and an upgrade in one. Compression and a simple format seems the best route.
NSF/NSF2 have a 1MB ROM size limit anyway; I'm not sure what you'd be planning to store in there that warrants compression... not like most hardware can even handle NSFs that large to begin with... (powerpak has a 252k limit I think).
The ROM data doesn't seem to need compression (it's easy to zip an NSF, and hardware players generally don't want compressed ROMs), and if NSF2 is to retain backward compatibility for NSF2s that don't use the new features, the ROM can't be compressed anyway. The other data besides the ROM isn't expected to be that large-- if we compressed just that we'd be saving a very tiny amount of data; unless there's something big and cool you want to stick in there (but why?).
1.) I've thought about an automatic way to do this for some time, but haven't had the time to add it so far. Maybe later!
2.) Editing samples in real time would be possible with the FDS expansion, as that's the only case where RAM is available in the sample area, at least according to the NSF specification. I don't know how feasible it is, as even a simple edit will easily take more than one full frame @ 60 Hz for a full sized sample (4 kB). Still that should be no problem if it isn't done too often.
I haven't tested that command in RJDMC but I'll look it up.
3.) I'll think about this too. Easiest would probably be to use the unused volume macro for the triangle channel to accomplish this.
4.) I've known about this trick for some time, I remember Jarhmander wrote about it a while ago. I tried it and it seems to work fine on most NSF players too. I believe this could be useful, but I haven't added it yet due to lack of time.
If you plan to implement Triangle volume control via DPCM, you should probably make a separate "expansion" named "2A03 Tri. volume" and completely hide the DPCM channel since you wouldn't be able use it for anything else really if your triangle instruments used ramps (I assume you wouldn't just Zxx with the macros) in the song all the time.
DPCM could be edited on the fly for some really interesting effects.
