--------
>>Have you considered creating your own waveforms?
>
>Yes. Sorry I left out the juicy bits about the design of the sound engine.
>I figured I would tinker with it first, but I haven't updated it since my
>original post so I might as well describe what it is as of now.
Hmmm. I didn't mean *fancy* waveforms. Just squarewaves. That leaves more
time for other stuff, but can be expanded if desired. If you're doing a
squarewave playback, then you only have to deal with note information, not
waveform re-creation.
>The "fancy" part of this table lookup is that the frequency is a 16 bit
>fixed point
>value, with the lower 8 bits as the fractional part.
>The position is also a 16 bit fixed value. The top half is used to index the
>wavetable. The bottom half is used to keep track of a "fractional" position.
[other stuff deleted]
This describes one of my 6.111 (Digital Death Lab) projects from last semester.
We took an audio signal in and dynamically changed the frequency, but NOT the
tempo of whatever was playing. As you note, lowering a frequency is much
cleaner than raising it. :)
>> This allows you to use any
>>frequency you want. If you only update the sound registers once per line,
>>you get 0 to 15.7kHz, or 8 (resonable) octaves. If you update every other
>>scanline, you get a top end of 7.85kHz...still not bad.
>
>A synthesis model like mine requires 1 to 2 lines of compute time.
>A strictly 2 chan. wavetable sample model can be pulled off in 1 line (I
>think).
Yeah, I was assuming squarewaves only. It was unclear exactly what you were
trying to do.
>>Also, let's assume that no voice ever jumps more than an octave. If you
>>use relative motion, with chromatic scales, you need 3.5 bits of storage
>>for each voice, and you give each voice a total range of 4 octaves
>
>Can you explain this? Assume you stay the same, that's "0"
Well, I told you I was tired when I sent this. But who needs voices to move
DOWNWARD? Just keep building the tension. And building...and building... :)
So 4.5 bits is correct. Sorry. :(
>>(conservative 2-scanline approach). Also, since (I assume) you're doing
>>2 voices per channel, if you're just re-writing the volume data for each
>>channel, you can store the information in terms of channels instead of
>>voices. Doing this gives double the storage resolution, or 1.75 bits
>>per voice, per beat.
>
>Are you confusing the wavetable sample with note information?
>I don't see how I can combine the musical information for two voices
>into one channel. (Other than wavetable precomputation, which is a
>different matter than musical note data for a song).
Again, I was not thinking is terms of samples. So assuming you just have
a SW synth, you still get 2:1 compression, or 2.25 bits/voice. You can just
add them together. This works (I think) for any waveform. But if the 2
waveforms are different, then it gets ugly. Won't work without precomputation.
Which isn't a bad idea, BTW. If you're just doing a composition tool. But
if you want it to work in a game, I think you'd want to precompute the entire
soundtrack, and store it in the rom. I think you mentioned this somewhere.
>Or maybe it's time to think about a different problem, like a more samples
>oriented engine as described above. But thank you for posting it and please
>help me understand some of your ideas on this.
Yeah, I think we were speaking 2 different languages. :)
We should get together and brainstorm this. I don't think well in front of
a keyboard. Or maybe because it's almost 3:00am. I dunno...probably both. ;)
-Chris
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
