A computer program that generates music. How quaint.
I remember when I first heard computer-generated music. My father showed me a book, “Music By Computers,” and we listened to some of the recordings of music generated by various kinds of programs.
That was in the 1980s. “Music By Computers” had been published in 1969, compiled from papers presented in 1966.
The recordings for the book were supplied as gramophone records. Thin, floppy, playable gramophone records, tucked in to an envelope at the back of the book.
This was quaint, old technology. The recordings were already twenty years old. The music sounded like it had been made by a computer... and yet it was tolerably pleasant or entertaining music, perhaps, depending on one's expectations and level of musical sophistication.
We dabbled with making our own programs... beep-booply-beep-boop... on our modern Sinclair ZX Spectrum.
People are still playing music, and still playing with music generators. Now folks are calling their music generator programs “AI” to ride the latest hype wave...
I'm glad to see people are still having fun with the idea.
An excerpt from “Music By Computers”:
Title Music to LINK, Side 2, Band 4
This short excerpt is the background music for the title and screen credits for the short documentary film LINK produced by the Argonne National Laboratory film group [3]. The film explains the operation of a computer program LINK, written by R. K. Clark of the Applied Mathematics Division at Argonne, for use in the automatic analysis of spark chamber photographs taken during experiments in high energy physics. Since it concerns a CDC-3600 computer program and includes com¬ puter-produced animation sequences which were photographed directly from the computer cathode-ray-tube display and which illustrate the program operation, it seemed only appropriate for the computer to provide the music with which to accompany and emphasize its accomplishments. Though the selection is only a minute long, it is in fact quite complex, accurately synchronized to the film (synchronization is a trivial problem) and contains some noteworthy illustrative effects.
An excerpt from a review of “Music By Computers” by a Mr Howe in 1970:
... [This work in recent years in computer synthesis of sound] involves the work of both scientists and composers, and thus raises both technological and aesthetic considerations. For people unfamiliar with this kind of research, the discussions in the book will seem very sophisticated and advanced, and it will appear that many rather general conclusions are now beginning to emerge out of quite disparate approaches to common problems. This impression, however, does not stand up under careful investigation...
Illustrations derived from scans of the title pages of the book, accessed through archive.org. First excerpt from the same. Second excerpt from a review by Hubert S. Howe, Jr. in Perspectives of New Music Vol. 8, No. 2 (1970), pp. 151-15, accessed through JSTOR.
I'm caught in a self-sovereignty self-hosting knot of ambition. Some days it seems everything I want to simplify or improve or upgrade is blocked by something else. I want to blog more from my WriteFreely instance, and for the time being I can, but it's bothering me that it's out of date, running on an out-of-date Yunohost-11. I'm proud to have set up staging copies of much of my infrastructure so I can try a test upgrade, but that reveals the upgrade is broken, so instead I want to migrate it either to a fresh Yunohost-12, but I discover that no longer supports exactly the same way of logging in with its SSO at my base-domain which is managed separately outside Yunohost (I'm skipping lots of details, they're beside the point here), and it reminds me WF is one of my last few “production” services still running in YNH. I want to get them out of YNH because for all its good points it's designed as a monolith, not to plug and compose with other infrastructure, so... I could migrate Writefreely instead to another hosting method outside Yunohost, like MASH, so I try that and find support for Mariadb isn't yet implemented in MASH-WriteFreely, so I could either add Mariadb support myself and then migrate the DB directly, or let it use another DB and instead try to migrate the posts and subscribers and metadata through WriteFreely's API... and so on for my other services. Ugh. I mean, I knew it would be like this. I chose this path, and I kind of like it. Sometimes I even find that software has been developed in the meantime that does indeed simplify and improve things for me, like when projects add support for SSO, and that's wonderful! But just so much still remains to do... And I'm trying to skip some of the nitty-gritty by looking ahead to better technologies: want to move infrastructure from Docker in VMs in Proxmox to mostly LXCs in Incus, eventually learn Nix and K8s, want to get involved in improving, unifying, standardising some of the best of small-medium scale hosting frameworks like Yunohost, Co-op Cloud, SelfHostBlocks/Skarabox, Fediversity. I realised at this stage any more tweaking I do to my private infra is more or less a waste, now that I've learnt from it. What matters is what I can contribute to projects that others share, so I'm aiming that way now. And thinking of some ways to “level up” this world of personal data self-sovereignty and make things that ordinary people can use, plug-and-play kit for family and friends and schools to store and easily manage their identity and data. Have (some) skills and (maybe good) ideas; lack money and time. Must get around to writing about the ideas at least. Is my WriteFreely still holding up for now? Whew.
An article about Building the Self-Agency Mobile Ecosystem: Push Messaging
Push messaging is the system that enables incoming messages to wake up and reach our apps, instantly and efficiently. But Who Cares Who Delivers Our Notifications? Our answer is: we care, and we do not like being locked in to depending on one mega-corp's system.
Therefore, in our libre mobile computing devices, we require a push-messaging infrastructure built from open standard technology that gives us freedom to choose our service providers and authority over them.
Should we consider standardising a UP client-server protocol so that a built-in distributor can work with several different server implementations and vice-versa?
Not necessarily, and I will attempt to explain why.
Another upgrade in my self-hosted IT infrastructure.
Nextcloud is a self-hostable platform centred around file storage, providing a plug-in framework expandable to a broad range of services. It is one of the older hosting platforms, and unfortunately showing its age in several respects. I consider few of its default and plug-in apps to be of high quality. However, due to its popularity, stability and support it seems to make a good base for file storage services and connecting other services.
I have been running Nextcloud for years but so far only using it for one core stable service (contacts and calendar) and some experiments. This is partly because my deployment is an old, stale configuration, stuck on an old version. I need to update to a maintainable deployment.
There are a few ways to deploy Nextcloud. For this I will use MASH. It is not one of the “official” methods; it's a self-hosting framework from the author of the popular Matrix self-hosting framework.
The MASH Nextcloud doc says, after running the initial installation, we need to intervene, with a second ansible run to print some credentials, then an interactive cut-and-paste session, then a third ansible run to finish installation:
After installation, follow Nextcloud's setup wizard... choose any username/password for your account... choose PostgreSQL with the credentials you see after running just run-tags print-nextcloud-db-credentials
Once you've fully installed Nextcloud, adjust its default configuration (URL paths, trusted reverse-proxies, etc.) by running: just run-tags adjust-nextcloud-config
But we want to do this non-interactively: Infrastructure as Code. Nextcloud supports Installing from command line. On our server we can run the in-container equivalent of the occ command shown there:
