The use of MMC5 PCM absolutely DOES NOT mute other channels. Perhaps you are mistaken because the one game that uses the MMC5 PCM happens to make no other sounds while it uses PCM.
Really, the MMC5 PCM channel is very much like the 2A03 PCM channel, except it is 8-bits wide instead of 7-bits. Also it's unsupported by almost all NSF players, but that's another issue.
Anyhow, this all comes back to the old issue with PCM. It's extremely CPU intensive for the NES to do, and it's difficult to write a sensible playback engine that can use the other sound hardware and keep up with the PCM at the same time. Trying to use a second PCM channel while doing this actually makes the problem worse; because you'll need twice as much CPU, you'd have to cut your samplerate in half. It's generally better to accept one less bit of effective resolution and maintain a higher samplerate, mixing all your sounds into one PCM channel (see SuperNSF).
Now, you could use the MMC5 to play PCM samples at the same time as using the 2A03 to play DPCM samples, and that might be slightly worthwhile, but again, not really appropriate for Famitracker for the same reason that 2A03 PCM is not really appropriate for it. It's just not a practical technique for games, which (with very few exceptions) tend to just stop everything they're doing when PCM sounds are being played.
But not everyone is making music for games necessarily. We can already see this with the multi-chip .ftm. I feel like famitracker should at least try to mimic the NES exactly. Thus, it should include these bizarre features. Yet again considering that JSR has another life other than famitracker, I can see why these features could possible never be supported.
I feel that it's silly to justify not emulating a core feature of the hardware "because it would allow techniques that are not feasible for games"...an overwhelming majority of the projects you'll come across are written for an expansion chip, zero of which were available outside of the japanese market, and were only utilized for a handful of games.
It's kind of a bunk argument anyways, why exclude PCM sampling and the MMC5's sample abilities because they're "not feasible for games", when the justification for including the n163 multiplexer hiss is "hardware accuracy"?
Emulate the hardware accurately, and allow us to determine what is or is not appropriate for our projects.
To answer the original questions: no it's not possible to hack a FTM to contain more than one DPCM channel, the reason is that the sound interface in the tracker is modeled strictly after a real NES. The only way to get around it is to change the tracker rather than the FTM.
The reason mult-chip is allowed is entirely because I've added support for it, but I didn't intend it to be available before it was complete. I thought it would be safe to leave it in the code only with no option to enable it, but that was a mistake :D
But as I said earlier: be careful, as there might be things I need to change before it's complete. (if ever, it's on low priority)
tadpole: Doesn't goattracker allow full speed songs? But I don't think it would be as useful as on the NES because there is no way to disable the ADSR-envelope in the SID, to my knowledge.
Regarding the MMC5 PCM channel, it's a "software only" channel just like the way DPCM can be used, and offer no more than 1 additional bit of sample resolution.
I feel that it's silly to justify not emulating a core feature of the hardware "because it would allow techniques that are not feasible for games"...an overwhelming majority of the projects you'll come across are written for an expansion chip, zero of which were available outside of the japanese market, and were only utilized for a handful of games.
It's kind of a bunk argument anyways, why exclude PCM sampling and the MMC5's sample abilities because they're "not feasible for games", when the justification for including the n163 multiplexer hiss is "hardware accuracy"?
Emulate the hardware accurately, and allow us to determine what is or is not appropriate for our projects.
It's not a hardware accuracy/emulation problem. PCM playback isn't a hardware feature, it's a software feature. The problem is one of software design.
Famitracker's NSF driver is designed a lot like a normal NES music engine, and it's actually fairly usable as one if you're so inclined. Designing an NSF driver that can do PCM playback among the other channels is usually in conflict with this.
A PCM playing NSF driver has to have carefully timed code to feed the PCM samples to the DAC, and this code needs to run constantly. If this ever gets interrupted, the PCM gets gaps/pops in it. This means a normal playback engine would insert a nasty 60hz buzz along with other harmonic distortion into your PCM stream as it gets interrupted every frame.
The NSF drivers that play PCMs smoothly, like SuperNSF work very differently. They discard the 60hz hardware update entirely, and design their playback from the ground up to do all the music engine tasks in short, carefully time segments that fall between PCM samples. SuperNSF's engine is only good for making PCM capable music, and not at all usable as an in-game music engine.
This is the problem. Nobody has actually written a nice PCM engine like SuperNSF that is versatile enough to also be a game music engine. (I don't want to say it's impossible, but it would be very hard to say the least.)
For reference, here are all the actual games I know of that had PCM playback with music:
1. Battletoads: title screen only, samples are dropped mid-song when cutscene requires more animation. There is no NSF compliant PCM rip for this game, because of lack of interrupt support in NSF. There's a hack rip that only works in GME.
2. Ultimate Stuntman: this game actually did have PCM mixed with gamepaly. There are lots of ugly gaps in the PCM sound where gameplay code needs to run, but it at least works. Again, there is no NSF PCM rip for this game due to lack of interrupts. There is a hacky RIP that replaced the PCM samples with DPCM samples.
3. Skate or Die 2: title screen only. The NSF rip actually works, but like with stuntman there are ugly gaps in the PCM where other code has to interrupt it constantly. It actually sounds quite horrible.
Games that use MMC5 PCM sample:
1. Shin 4 Nin Uchi Mahjong. Only uses it for voice samples that are not played during active gameplay or music. This actually could have been done just fine with the DMC channel and would have sounded almost identical. (The MMC5 PCM is an almost useless feature, and was only used in this one game, hence the lack of emulator/player support for it.)
The NSF2 standard actually has interrupt timer support, and would make PCM playback fairly feasible. With interrupts, PCM could be done without having do design your entire playback driver around it. It would allow a proper NSF rip to be made for Battletoads, for instance.
There are no NSF2 players yet though. (I'm working on one.)
Now this might be very stupid thinking but could developers have added even the shittiest tiny little processor to carts to get the PCM samples to the DAC or is that impossible due to the pin structure of the carts?
rainwarrior sums it up well, it's not the accuracy that's the problem but the efforts it takes to write a music player that utilizes PCM playback. It would probably be easier to rewrite the current driver from scratch than trying to add timed code to it, and then all the trouble it would mean to maintain it...
NSF v2 would make things easier though.
za909: It would indeed be possible, but then it would be a lot more feasible with the DAC on the cart instead (think MMC5 with automatic sample playback).
PCM playback isn't a hardware feature, it's a software feature.
So wait... You're saying 7-bit PCM playback wasn't really a feature of the hardware, but was rather a finagling of the hardware that was only available to programmers savvy enough to figure it out?
Please excuse me if I've completely misunderstood you.
_______________________
The only things certain in life are death and uncertainty.
More or less, yes. The square channels are capable of 4-bit PCM output in the same way that the DMC channel is capable of 7-bit PCM output. (B00daW made a test of this, actually.) All it takes is updating the volume/Zxx with precise rapid timing. The timing is the tricky part, because the NES doesn't have any built-in timers (except the 60hz vsynch). To time things, you have to know how long every instruction in your code lasts. This is why NSF2 interrupts would make it much easier to do: you can put timer hardware in the cartridge and connect it to the interrupt line.
tadpole: Doesn't goattracker allow full speed songs? But I don't think it would be as useful as on the NES because there is no way to disable the ADSR-envelope in the SID, to my knowledge.
Yes you can do 4x speed in GoatTracker which can actually go much faster than 60hz/row. But the new SID-Wizard looks to be much more powerful a tool than GoatTracker.
Going that fast isn't as useful as it would be in famitracker, mainly because when you rapidly change the volumes it makes a lot of clicking noises or even skips notes.
And sorry, guys, that this is a bit off topic for this thread.
