Code Golf - The Reboot #8

[Juju]

Hey, it's me again, Juju, hosting the eighth iteration of Code Golf: The Reboot. This week, the output will be... sound. Yep, you heard right. Pun intended.

The assignment today is a simple A4 sine wave, sample rate of 8000 Hz, in raw wave format. But first, you'll want to understand at least a little how to make one. First, know you'll have to output 8000 bytes to make one second, but you don't have to output all that in exactly one second. To make a simple A4 (frequency of 440 Hz), look at the graph for sin(x). Map the y from [-1,1] to [0,255] (don't forget to round it to remove the decimals!) and try to fit the wave you get ([0,2π[) 440 times in those 8000 bytes. Then just output the bytes you just generated, no header or anything. On calc, if you can output those bytes through the link port with the timing, that would be great (no Freq(), you Axe people!), otherwise, you can just output a list with the 999 first numbers you get (makes for about 1/8 of a second) or an infinite loop that disps the numbers (if you output on screen, you don't need the timing), or whatever the easiest for you. On PC, you can output the raw bytes in an infinite loop or the 8000 first ones (makes for one second) so I can pipe them through aplay.

tl;dr you have to output a very specific sin() function with specific parameters. Should be simple enough.

The rules are still the same, if you have any questions, please ask. Have fun!

Ranking
@3298 - SysRPL - 53 bytes

[lirtosiast]

Can we have the first few bytes of expected output to check our work?

May we start the sine wave at some point other than 128?

May we truncate instead of round?

[Juju]

I wrote the topic at 4am, was too tired to do a fancy post.

Can we have the first few bytes of expected output to check our work?

Here's the first 64 bytes (0.008 seconds) of output of a script I wrote, piped through od -t u1.

0000000 127 170 208 237 252 253 239 211 174 131  88  49  19   3   1  13
0000020  40  76 119 163 202 232 250 254 242 217 181 139  95  55  24   5
0000040   0  10  34  69 111 155 195 228 248 254 246 223 188 147 103  62
0000060  29   7   0   7  29  62 103 147 188 223 246 254 248 228 195 155

Of course, your mileage may vary.

May we start the sine wave at some point other than 128?

Of course. It does not matter anyway, it's cyclic. You probably even can use cos().

May we truncate instead of round?

Of course. That's what I did as well.

[3298]

Oh, Code Golf is back. I rarely visited Omnimaga for a while now because my standard browser doesn't like the available HTTPS encryption modes (time for an upgrade...), but if you look at the entries in JWinslow's original series, you may see a few entries written by me.
I just submitted  a SysRPL program for this one, measuring 53 bytes - SysRPL tends to be pretty small. Unfortunately it's quite slow, more than 2 minutes for the entire output (may depend on available memory due to the way the garbage collection works; right now I have a lot of memory available on my calculator). It simply dumps the 8000 numbers to the stack, one by one, and leaves them there so the user can examine them.
I may also participate with Java, XTend and Haskell like last year, we'll see. Maybe even with C.

[TIfanx1999]

Oh hey, good to see you around. i remember you having some pretty small entries. Good to see you around again.

[3298]

Thanks, it's always nice when someone says "welcome back". And it's kinda hilarious when a member with >5000 posts says "hey, I recognize you" to a member with <50 posts.
I also wrote and submitted Java and C entries with 127 and 122 bytes. For general-purpose languages that's a more reasonable size.
SysRPL is extremely compact, probably because when HP's programmers wrote the 48/49/50 operating system, they were notoriously short on memory. ("Life is short and ROM is full." - William C Wickes) The system is implemented in a mix of SysRPL and plain ASM, so when the ASM code was as compact as possible, they squeezed every nibble they could out of the SysRPL parts. Thus there are tons of little code snippets called from all over the ROM (to reduce code duplication), and they are usable for user-written SysRPL programs as well, reducing my program sizes. On some occasions I've even seen code in the ROM which is decompressed on the fly, but mostly for parts rarely used during normal operation.

[TIfanx1999]

Haha, that's a fun little quote. I'll have to remember that one. I looked at RPL before, but it looked a bit weird to me back then. Maybe I'll have to look at it again. I hear a lot of people really love it.