rainwarrior wrote:
Sorry if this is confusing.
That's OK, thanks for clearing that up.
Quote:
1. Every interval is a different distance for each starting pitch, so if you use an envelope to make a slide from C-3 to E-3, you can't really use it for any other pair of pitches.
Well, I do plan on using tables to create a fixed number of steps between notes, which will allow me to address them linearly... That should take care of this problem, right?
Quote:
2. Determining the precise values needed for a targeted slide envelope is tedious.
This too shouldn't be such a big problem if notes can be addressed linearly, I guess.
Quote:
3. Slow pitch slides require very large envelopes.
That's true.
Quote:
4. The pitch slide effects all have configurable speed; each envelope only supports one speed.
Again, true.
Quote:
If you want to do it rarely, sure
That will probably be the case.
Quote:
There are other ways to handle pitch, too. You could create an expanded pitch table with 16 divisions of each semitone (like how MODs do fine pitch), allowing pitch envelopes to apply logarithmically so you could make a "5 semitone slide" envelope that could be used on any note of the scale.
Yes, that's exactly what I plan to do (I'm replying as I read, so I mentioned it before knowing you'd suggest it).
Quote:
I think the biggest problem with effects, is that each class of related effects requires RAM to maintain its state;
Yeah, I also though about this after my last post. If I can have 2 or 3 effects per channel, that could add up to a significant amount of RAM, and I really am trying to keep RAM requirements low.
Quote:
this is true whether or not you try to implement it as an envelope.
Well, I'm not so sure about that. For envelopes, all I have is a pointer to the current envelope step. If I add a second envelope I'll just need another pointer. My idea is to get the note from the song and the channel's volume, apply all the instrument modifiers, and on top of that apply all the effect modifiers, and then write the final result to the APU. I don't really need any state because each step of an envelope has all the info I need, so I can construct the final APU data from scratch every frame.
Quote:
I was saying that it's true that a few of the effects could in theory be implemented by reusing other envelope code, but in general I think the extra envelope data would end up being bigger than the code you saved, and RAM usage would be the same or worse.
I agree about the data being bigger, but I guess my approach here is like "I don't want to make the engine overly complex, and I probably won't need effects very often, but I also don't want to completely get rid of them", so this is a quick and simple way I found to allow effects if they are really necessary, but when I use them I'll know that the price is precious ROM space. If I don't use them, I don't lose anything.
As for RAM usage, 2 bytes for an extra pointer per channel sounds MUCH better than whatever I'd need for the states of combined effects (I'm guessing it would be at least 2 bytes per effect, but maybe some need more?). Unless I'm missing something here, but I'm fairly sure I can create the APU data from scratch every frame like I described above.
Quote:
This is why my answer to your OP question was that you don't really need effects; you've got tons of functionality already with just the 4 envelopes.
And I've been listening to some good examples of that.
Quote:
I dunno how much you want to go down the road of either modifying Famitracker, or giving your composer features they can only hear if they do an export and run in an emulator, but in general I'd avoid this.
I want to keep things simple on all fronts.
I'm not sure Famitracker will be involved at all, though.
Please note that I'm not trying to defend my choices or anything like that, I'm honestly looking for some good feedback so I'll end up with a sound engine that isn't too crippled but isn't so heavyweight either, and so far the replies have been very useful. If you think that things I say are stupid, or if you disagree with me on anything, please keep the replies coming. If you can validate my ideas too, that'd be great, so I know I'm not going forward with something completely weird. Audio is the thing I'm least experienced with when it comes to game programming, so I really need to be told that I'm going in the wrong direction if that's the case. Hopefully that'll make me better at this.
EDIT: I just realized I completely neglected to mention that the RAM requirements I mentioned (2 bytes per envelope) is only possible if the different types of envolopes aren't in separate reusable sequences, but instead pitch, duty and volume sequences are all packed together in the same sequence. I do realize that, again, this needs more ROM than separate combinable sequences each with their own loop points. This is not final though.