Old computers had hardware synths (ICs like the C64s SID) or piezo speakers which where simple to interface with. But you can do this, you just need to use a DSL made for synthesis like SuperCollider.
Edit: You could actually do this on pre ALSA linux and can possibly do this on modern BSD, OSS created a DSP device which you could write directly too, even from a shell. Assuming memory serves here, I remember writing to /dev/dsp from the shell but it is possible there was some intermediary which I am forgetting about.
I had a TRS-80 Color Computer which, like the Apple ][, had no hardware synth and the CPU would be tied up generating sound with a primitive output. You could type
SOUND tone, duration
and there was also a
PLAY program-in-some-DSL
that could play a sequence of notes. As I recall the C64 had a sound chip that was better than anything else at the time but there weren't commands to use it from BASIC so you would have to use a few POKE commands to control it directly. That was still pretty efficient because you could write a few bytes to a memory-mapped I/O port and it would play w/o the CPU having to do anything.
Radio Shack came out with more than one "sound card" for the CoCo which worked roughly the same as the SID chip in the C64 though.
I'd say today people have higher standards. The PLAY command on the CoCo was monophonic, "real" music involves multiple notes at the same time (polyphonic) and would have a more complex API to specify. Whether you are using MIDI or FM synthesis or samples the range of configuration you could apply to get the notes you want is vast.
Certainly you could make some library that would let you bang out notes in Python with very little code, but for most people who want to add music to a program I think they'd much rather play an MP3.
Apple had 1bit sound, forgot about that, so just a square wave, was thinking it was a piezo. Think the piezo came a bit later, I remember it on DOS machines but I was quite young back them. C64s SID chip/MOS 6581 was a decent little 8 bit synth limited in the sounds which could be created compared to a real synth but the best built in computer synth of the time hands down.
It’s up to you really. Plenty of game frameworks support sound but the API is going to be a little more complex than the Coco. I mean people make games with sound with PyGame and Phaser all the time.
Always found it a bit amazing when a way was discovered to fake three voice sound on the CoCo's stock hardware. The add on sound cards were pretty neat but most cost almost as much as the CoCo itself. Since much of that cost likely came from making it into a ROM pack and a boxed SKU, I am a bit surprised that Tandy didn't include one of them on the motherboard of the CoCo 3, but they also passed on the chance to add sprites to the CoCo 3, so the twin principles of the CoCo being relatively low cost and the 6809 (somewhat of an extravagance for 8-bit computing) doing all the work seems to have kept those extra functions from being added.
Because everything is orders of magnitude more complicated now.
In the early 80s, the computer had approximately 1 sound making device, and you could make it do its thing by writing some bytes to some memory address or whatever.
Now, "in iOS for example", there's a speaker, possibly any number of bluetooth devices, maybe some docking sound device too, so you need some mixer to control them individually, and maybe the phone is in silent mode or vibrate in which case it (probably?) shouldn't play a note, but maybe it should vibrate instead? or maybe not, depending on what the note means...
So now... you need to either deal with all this stuff yourself, or have some complex framework that tries to hide some or all of it from you... but it's probably a leaky abstraction at best, and the framework requires some number of lines of code much greater than one to set up.
8 comments
[ 3.8 ms ] story [ 36.3 ms ] threadEdit: You could actually do this on pre ALSA linux and can possibly do this on modern BSD, OSS created a DSP device which you could write directly too, even from a shell. Assuming memory serves here, I remember writing to /dev/dsp from the shell but it is possible there was some intermediary which I am forgetting about.
SOUND tone, duration
and there was also a
PLAY program-in-some-DSL
that could play a sequence of notes. As I recall the C64 had a sound chip that was better than anything else at the time but there weren't commands to use it from BASIC so you would have to use a few POKE commands to control it directly. That was still pretty efficient because you could write a few bytes to a memory-mapped I/O port and it would play w/o the CPU having to do anything.
Radio Shack came out with more than one "sound card" for the CoCo which worked roughly the same as the SID chip in the C64 though.
I'd say today people have higher standards. The PLAY command on the CoCo was monophonic, "real" music involves multiple notes at the same time (polyphonic) and would have a more complex API to specify. Whether you are using MIDI or FM synthesis or samples the range of configuration you could apply to get the notes you want is vast.
Certainly you could make some library that would let you bang out notes in Python with very little code, but for most people who want to add music to a program I think they'd much rather play an MP3.
In the early 80s, the computer had approximately 1 sound making device, and you could make it do its thing by writing some bytes to some memory address or whatever.
Now, "in iOS for example", there's a speaker, possibly any number of bluetooth devices, maybe some docking sound device too, so you need some mixer to control them individually, and maybe the phone is in silent mode or vibrate in which case it (probably?) shouldn't play a note, but maybe it should vibrate instead? or maybe not, depending on what the note means...
So now... you need to either deal with all this stuff yourself, or have some complex framework that tries to hide some or all of it from you... but it's probably a leaky abstraction at best, and the framework requires some number of lines of code much greater than one to set up.