This is what happens when frogger doesn’t look both ways before crossing the street / pond:
gi_square ftgen 4, 0, 256, -7, 1, 128, 1, 0, -1, 128, -1
instr 1
idur = p3
iamp = p4
kenv line 0.00230, idur, 0.01978
a1 oscil iamp, 1 / kenv, gi_square
out a1
endin
...
i 1 0 0.96493 -0.707
Download: dead_frogger.csd
Thanks for this little tidbit. Now I’m going to play with making arcade sounds all day. I just have a small design question: Why did you choose to have the oscillator invert the kenv values, rather than using the real values in the envelope. i.e:
kenv line 434.78, idur, 50.55
a1 oscil iamp, kenv, gi_square
I can think of a few reasons, but I’m just curious as to why you did it.
@Mark: Thanks. I don’t remember why, exactly, as I made this example a couple of years ago. I think what I did was open up a recording of frogger’s demise in Peak and measured the period of the waveform for the start and end points. Which would explain the inversion.
If you come up with anything interesting, in Csound or otherwise, send a link. I practically grew up in an arcade, so I’m quite fond of these types of sounds.
Through testing, I discovered that your method gives a faster, more exponential decrease in the frequency, where as if you use the frequency values without inverting the period(as in my example), the downward frequency shift is much slower. I also tried using ‘expon’ in place of line with the frequency values like this:
kenv expon 434.7826, idur, 50.556
But this also gave a slower pitch shift than your version. So your version works best from a design standpoint.
You know, I think I vaguely remember going through the same process with expon. Either way, thanks for going through the trouble of identifying the reason. I should be making notes when I do this stuff.
I have some other video game sounds in my library. I’ll start releasing them starting this week.