First off: I really like the Namco chip and including it in Famitracker is the greatest thing since lemon ice cream
But I've got a problem: The address where the waves are stored are only determined by what you input when creating the instrument. This limits the anount of flexibility this chip has by a great deal since only so many waves (4 x 32-Step, 8 x 16-Step, ect. and/or mixing types) can be loaded into the Wave RAM at once.
Now, I get that this memory space limitation is a hardware limitation and this is the way it's supposed to work. My Idea now is that we might introduce a new effect that changes where the wave is stored in memory, essentially giving a pointer for the N163 to store the wave dynamically instead of assigning it inside the instrument data. This way, one could use an instrument in combination with other instruments that would usually take up the same space without cloning the instrument just to change where it'll be loaded.
Let me give you an example:
The Namco N163 internal Wave RAM has a capacity of 128 wave steps. We're observing the first 64 steps right now (for this example, the rest is used already.)
Let's say I've got a 32-Step instrument, Ins_0 @00-1F, playing alternating with another Instrument, Ins_1 @00-1F. Another Instrument, Ins_2 @20-3F, is playing simulataneously. No problem here, Ins_0 and Ins_1 just overwrite each other's data at every alternate turn and Ins_2 isn't affected. Now, when I want to change this up, halt Ins_2 and want Ins_0 and Ins_1 playing simultaneously, I'd have to copy either one of those and change the address to 16.
If I had the Mxx effect, I could reconfigure where Ins_0 or Ins_1 are being stored on the fly.
By the way, this example was pulled out right between my buttocks without a track having this problem, so any classic solution for this is nice and welcome, but ultimately wouldn't be nessecary
Thank you for reading and I hope some people will like this Idea / Request ^.^
_______________________
The purpose of a programming language is to protect the computer against the programmer.
I've been trying to come up with a more elegant solution for N163 wave memory management since before it was even supported. This might be the best way to approach it.
Edit: Oh - jrlepage postet while I was typing ... so:
@DalekSam:
Oh, really?
TBH I never looked past my horizon and experimented with different FT versions, but I think I'll for now stick with thr regular JSR Famitracker since I'd like to refrain from posting FTMs incompatible with the standard-Faitracker.
But yeah, good to know it already is possible in another version ^.^
Thanks!
@jrlepage:
Yeah, since automatic wave memory management might be a living hell to implement, shifting the way to manually determine the wave position to a better place might be the best solution.
I see it as changing the position of the shift stick in a car from in the luggage space to next to the driver ^_^"
_______________________
The purpose of a programming language is to protect the computer against the programmer.
I also suggested a command like this in the early days of N163 support. It would be especially handy once the official build supports waves longer than 32 steps, in which case it allows a lot more possibilities to use the unused channel registers area for waves with less than 8 channels.
Well, the problem with the auto-solution is that the flexibility would be diminished by a big chunk. For example, when an instrument is playing on more that one channel, it'd take up more chunks of memory than nessecary.
Anyways, I'd really love to see a way to manage wave positions maually and an automated solution may be welcome for people new to the N163. Thank you, JSR! :D
_______________________
The purpose of a programming language is to protect the computer against the programmer.
