CAC Computer-Assisted Music Composition Environment in BBC BASIC

I want to announce the release of a piece of source code for a computer-assisted music composition program that composer Richard Emsley (https://en.wikipedia.org/wiki/Richard_Emsley) started writing in 1989. He’s used it throughout his career.

I was able to test Richard’s program on a raspberry pi 2 and raspberry pi 3. I put a GPLv2 license on it.

The heart of the functionality of CAC is in a BBC BASIC Procedure called PROCfunctionreception.

You can find the source code here:

https://github.com/CAC-Richard-Emsley

This is a mirror:

https://notabug.org/jgart/CAC

Here is a video of Richard using the program in his apartment:

https://archive.org/details/EmsleyVideoBbcBasic1

Any help on refactoring, adding tutorials, documentation, etc… would be greatly appreciated.

I haven’t summoned up the courage to actually run the program just yet, but I did notice one thing.

It looks like something (possibly Github) has slightly mangled the source code. All instances of the £ character have been replaced by a 3-byte sequence (&EFBFBD) that macOS displays as an inverse video question mark. You can see this for yourself by searching the text for “copydownwards%” and inspecting the nearby CASE statements.

Alternatively, look in PROCkeyboardshortcuts for the PRINT statement that contains the text “Display from which voice down”

Mojibake!

All instances of the £ character have been replaced by a 3-byte sequence (&EFBFBD)

This is the Unicode Replacement Character (&FFFD) in UTF-8 encoding.

Something has tried to interpret the program as UTF-8, found a non-compliant byte sequence (the ‘£’), and replaced it with the Replacement Character.

This is why fallback is so very important when working with legacy files.

This is why fallback is so very important when working with legacy files.

It’s also the fun of a world where some use Unicode, some don’t, and the glue holding the two together is more like splatters of faded chewing gum (like the public precinct in Aldershot… ;-) ).

Imagine our address is “Très joli” (it isn’t, but I need an accent). We often get mail to either “Tr?s joli” or “Tr~å@s joli” (something like that, I made up the characters).

I can forgive idiot British/American companies that wouldn’t know an accent if it punched them in the face, but it’s inexcusable for French companies.

We have a new clocking in system at work (amusingly called “eTemptation”!) and when Laëtitia clocks in… La?titia. I presume it’s the same for everybody with a wibbly bit in their name, which is probably half of them. Seriously, a “badgeuse” sold in France to a French company can’t handle French names. WTF.

Seriously, a “badgeuse” sold in France to a French company can’t handle French names. WTF.

eTemptation appears to be made by Horoquartz (French) who are part of the Amano group (Japanese) so I suppose you’re lucky it uses any variant of the Latin character set, but yes you’d expect a French company selling a system to a French company with an expectation that most of the users of the system would be French should be able to deal with accented characters.

Of course, if the managerial staff re-entered the name as Laetitia I’m sure that would display correctly and the unaccented version was good enough for one of my ancestors. Have I upset French readers yet :)

eTemptation appears to be made by Horoquartz

Yes, my pay slip that’s just been made up has a rubbish tutorial about how to request days off. One must log into the Horoquartz cloud server using the stupidest dumbest piece-of-crappiest username/password combinations imaginable – our name and our date of birth. Like nobody doesn’t have all of that on their Facebook profiles… <sigh>
Yes, I said Horoquartz cloud server. Which apparently has all my employee information for that to work. Funny, I don’t recall a GDPR request for that.

and the unaccented version was good enough for one of my ancestors

English people tend to say “la-tee-sha” or “le-tee-sha”.
I think Laëtitia says it more like “la-ay-ti-tee-a” (all run together, of course). David Feugey, you around? :-)

Then there’s Amélie, Céline, Aurélien, Céline, Solène, Céline, Zoé (yes, é not ë), Céline, Océane, Céline, Inès, Céline, Annaïg, Céline, Coréntin, Céline, Rozénn, Céline, Anaïs, Céline, Gaëlle, Céline, Mélanie, Céline, Héloïse, Céline, Maïwenn, Céline, and Noémie. And those are the people I remember from earlier today, never mind the 100 odd others.

The weirder looking ones are Breton (think “sort of Welsh”).
The Céline gag is because there are so many.

Never mind renaming anything. There’s zero excuse for a clocking in system with a bitmapped display¹ (not an internal character generator like those 16×02 LCDs) not being capable of handling accented characters which has been a part of written French depuis quand existe la lumière…

¹ I know, because they seem to play with how it looks on a weekly basis. This week it says my name big and bold, but omits to bother mentioning if I’m coming or going. Duh.

I can forgive idiot British/American companies that wouldn’t know an accent if it punched them in the face, but it’s inexcusable for French companies.

I’ve received mojibake in a printed packing slip from Amazon.co.jp. Even they can’t get it right!

I think Laëtitia says it more like “la-ay-ti-tee-a” (all run together, of course)

I think I’d normally be somewhere with a mix of that and a “sha” ending,

The Céline gag is because there are so many.

Just call them all “Bob” because :)

The weirder looking ones are Breton (think “sort of Welsh”).

My memory says there’s some linguistic connection, but I’m probably wildly wrong. BTW. I think the ladies may not like being called “the weirder looking ones” :)

Seeing activity in this thread (albeit for a side issue) reminded me that I never did report back on the CAC program itself.

To be honest I didn’t get that far. The program allows you to create music in a manner that is superficially similar to Maestro, but has several extra features (e.g. the pitch of a note can be specified in units of one quarter of a semitone).

Problems I encountered were:

1. The program wants a relocatable module called “WFS” (Wave Filing System). Getting hold of a 32-bit version of WFS isn’t too much bother, but as all of the “voice” files are missing this doesn’t get you very far.
2. The program shows several signs of having been modified on a Raspberry Pi. For example, most of the COLOUR and GCOL commands assume 64 available colours, but the screen modes used have only 16 colours (e.g. MODE 12, MODE 31). This can cause unwanted effects (the entire screen flashing) when used on a Risc PC or similar hardware.
3. It expects to be in directory $.CAC, and also expects directories $.CAC.CACvar and $.CAC.Files to exist. If these are missing, the program will still run but certain features (e.g. loading or saving a file) won’t work.
4. Numerous unnecessary mentions of SDFS::RISCOSPi. The file/directory specifications need to be reworked as relative paths.
5. The main program loop consists of PROCdisplay and PROCpostdisplay calling each other. This results in (what amounts to) a memory leak, although it is slow enough that it won’t affect program operation in any realistic composition session.

Changes required to get it to run:

1. REM out the *RMLoad of WFS, at or near line 9683. This will restrict you to the default voices (e.g. WaveSynth-Beep).
2. Dispose of the assorted *CONFIGURE statements (e.g. at or near lines 19 and 5225). For a start they’re not needed on modern hardware, and in any case using *CONFIGURE to modify settings for a single program could lead to other problems.
3. The *DIR statements scattered through the program will need amending (at the very least to remove “SDFS::RISCOSPi”).
4. Replace the MODE 12, MODE 16 and MODE 31 statements with the corresponding 256-colour mode (i.e. MODE 15, MODE 24 or MODE 32). Affected lines are 18, 121, 3842, 5226 and 15101.
5. Various lines need modifying to replace the “Unicode Replacement Character” (&EFBFBD) with the £ sign. The first of these is at or near line 6450; there are 14 to replace.

Running the program:

• Set the Wimp “Next” slot to something substantial. I used 40MB, which was probably overkill, but you can never have too much overkill :-)
• The program asks you a bunch of questions at the start. For initial testing I was using:
  • 10 bars
  • 8 notes per bar
  • 2 voices
  • Use default voices
  • 4 beats to the bar
  • 2 beams on the beat
• ESC is trapped, so you can’t easily exit from the program.
• To exit (once you’ve given it some starting parameters), press M then Q.
• Press O to display a run-down of available options.
• Press K for a list of keyboard shortcuts.

Hi Stuart,

Thank you for the extensive feedback on the program. The issue with the pound symbols being mangled was due to not having “commitencoding = ISO-8859-1” enabled in the .git/config when I made the first commit.

I fixed it just today in both repositories. I also uploaded a user’s manual that should help clarify aspects of CAC. I will be uploading a further updated version of the manual sometime at the end of this week. Richard is adding in more details.

It is great to hear that you tried to run the program.

“The program allows you to create music in a manner that is superficially similar to Maestro, but has several extra features (e.g. the pitch of a note can be specified in units of one quarter of a semitone).”

CAC stands for Computer-Assisted Composition. It’s purpose is similar in spirit to programs like Open Music , PWGL , and abjad. Richard started working on this program in 1989 to assist him in composing music. He was first interested in generating accelerating and decelerating passages in a procedural manner as he was previously creating these musical passages by hand with graph paper and then translating them into music notation. CAC allowed him to automate this. He went on to extend CAC by adding more functions that model his own compositional techniques. The newly uploaded manual explains these techniques and their implementation. I am interested in this program from a historical and pedagogical perspective. I am also curious to see if the program can be used by others to help them compose in risc os open. I am interested in the possibility of implementing new functions for generating music. If anyone is interested in collaborating, fixing bugs in CAC, or making a pull request for any new feature please get in touch.

Here are some further ideas for extensions to the program:

1. a python or bbc basic script to export the generated music to either lilypond" , abcmusic , and/or musicxml formats

2. Functions to generate twelve tone rows would also be interesting to implement. Retrograde, Inversion, Retrograde-Inversion, Multiplication (Mod 5/7), etc…

3. This racket lisp function would be nice to implement into CAC/BBC BASIC. It generates randomly octaviating chromatic scales of any length in lilypond markdown

Some more responses to your comments follow:

“The program wants a relocatable module called “WFS” (Wave Filing System). Getting hold of a 32-bit version of WFS isn’t too much bother, but as all of the “voice” files are missing this doesn’t get you very far.”

Richard has the sound files. Can you point me in the right direction of acquiring a 32-bit version of WFS for the raspberry pi? Do I have to compile one or is there an available binary somewhere?

We are looking into whether we can publish these as they were under copyright in 1989. I am not sure if the copyright is still in effect. I am looking into either publishing the sound files so that a user can load them or to remove those blocks of code that call on these audio files. If anyone has suggestions for an alternative sound font for risc os open that is available under a free software/open source license, the recommendation would be greatly appreciated. If anyone would like to contribute new sound fonts please get in touch.

“The program shows several signs of having been modified on a Raspberry Pi. For example, most of the COLOUR and GCOL commands assume 64 available colours, but the screen modes used have only 16 colours (e.g. MODE 12, MODE 31). This can cause unwanted effects (the entire screen flashing) when used on a Risc PC or similar hardware.”

Richard recently modified the source code to fix some issues with it running on the raspberry pi.
Does anyone know if there is a way to load one command or another depending on the architecture it is loaded on?

We will be publishing the version for RISCOS before the raspberry tweaks were made in the next week or so. I will report back when I have that one in a repository.

“It expects to be in directory $.CAC, and also expects directories $.CAC.CACvar and $.CAC.Files to exist. If these are missing, the program will still run but certain features (e.g. loading or saving a file) won’t work.”

Any suggestions on a way to refactor these statements to allow a simpler initial setup?

Numerous unnecessary mentions of SDFS::RISCOSPi. The file/directory specifications need to be reworked as relative paths.

I will look into refactoring this to use relative paths. Thank you for making the suggestion.

“The main program loop consists of PROCdisplay and PROCpostdisplay calling each other. This results in (what amounts to) a memory leak, although it is slow enough that it won’t affect program operation in any realistic composition session.”

Any suggestions for a way to fix this memory leak?

“REM out the *RMLoad of WFS, at or near line 9683. This will restrict you to the default voices (e.g. WaveSynth-Beep).”

“Dispose of the assorted *CONFIGURE statements (e.g. at or near lines 19 and 5225). For a start they’re not needed on modern hardware, and in any case using *CONFIGURE to modify settings for a single program could lead to other problems.”

Thank you for this suggestion.

“The *DIR statements scattered through the program will need amending (at the very least to remove “SDFS::RISCOSPi”).”

“Replace the MODE 12, MODE 16 and MODE 31 statements with the corresponding 256-colour mode (i.e. MODE 15, MODE 24 or MODE 32). Affected lines are 18, 121, 3842, 5226 and 15101.”

“Various lines need modifying to replace the “Unicode Replacement Character” (&EFBFBD) with the £ sign. The first of these is at or near line 6450; there are 14 to replace.”

This has been fixed in this commit 06fd9362e26fbc9a9dc6bdc2ee5e56dd553f8bb6

ps

Here are a few compositions by Richard Emsley that were composed with the aid of CAC:

1. For Piano 2
2. Finnissy’s fifty
3. For Piano 13
4. For Piano 15
5. Still/s 5
6. Still/s 6

7. …des tactiques de lenteur…

This composition for electronic sound was created using CAC and riscos’ SOUND operating system module.

Here is an interview with Richard Emsley that shows him using CAC in RiscOS.

Richard using CAC starts @7:40

There is a mention of this EMR Creations Disk selling for 20 pounds in this volume of BBC Acorn User from 1989.

Here is pdftotext conversion of the original WFS version info on the software packaging that Richard was using with CAC:

EMR CREATIONS DISK

1

USING THE WFS

The Waveform Filing System (WFS) is an RM fite on disk 1 that allows sound
samples to be loaded and installed (up to 82 maximum) and played from BASIC
or M/Code Arc SOUND commands (EMR programs do this automaticaily).
First load the WFS from BASIO or SUPERVISOF, by typing ‘RMLOAD wFS space where space
=
total space for WFS to be allocated in the RMA. Eg.space=a1 9000 will give l00K for internal sounds.
Next, sounds can be loaded using’WLOAD until the space allocabd is full. Once loaded, the sounds
have to be installed using’WINSTALL. The samples are now ready for playback from Acorn’s Music
Editor (including the new Maestro version) or from SOUND commands issued from BASIC or

WCode orectly. When using BASIC it is possible to use the following statements to set up

samples: 10 ’WFS

& 19000

20 REM load and install sounds (SoundNamel,2,etc)

g0’WLOAD SoundNamel
40’WLOAD SoundName2
50’WINSTALL SoundNamel
60’WINSTALL SoundName2
Up to 8 sounds may be installed at any one time on the sound channels.
Summary of WFS Commands

’WLOAD

Can you point me in the right direction of acquiring a 32-bit version of WFS

According to this post at JASPP it’s bundled with ADFFS – you may wish to have a word with Jon Abbott (who runs that site) as I think he used to work for EMR and may be able to suggest what to do regarding the “voice” files. Jon should also be able to help with the changes to WFS defaults – if any – in the latest version.

Richard recently modified the source code to fix some issues with it running on the raspberry pi. Does anyone know if there is a way to load one command or another depending on the architecture it is loaded on?

There is, but I think you may be introducing complexity when it isn’t needed. The issue isn’t that the Raspberry Pi and the RiscPC are different, it’s down to a quirk of the Raspberry Pi video system itself.

The Raspberry Pi supports only 3 colour depths: 256, 64 thousand and 16 million. If a screen mode with fewer than 256 colours is requested, RISC OS will supply the corresponding 256-colour mode instead. In other words, if you ask for MODE 29 (800×600, 2 colours) what you actually get is MODE 32 (800×600, 256 colours). This is to allow older programs to run without producing a “Bad screen mode” error on the Raspberry Pi.

The easy fix to this problem is to change the program to use 256-colour screen modes throughout. It will then run on most (if not all) RISC OS hardware targets without you needing to worry about the hardware architecture.

Any suggestions on a way to refactor these statements to allow a simpler initial setup?

The easiest way is to rename the CAC directory to !CAC (i.e. convert it into an application). An application usually needs a bunch of other things such as sprite files, but for this proof-of-concept all you’d need is an Obey file called !Run:

WimpSlot 10240K
set CAC$Dir <Obey$Dir>
<CAC$Dir>.CAC-i

Save the above 3 lines of code as a file called !Run inside !CAC (as this is now an application you have to shift-doubleclick to see its contents). Set the file type to “Obey” (&FEB). When you double-click on !CAC, the program (CAC-i) should now run, but the important change is that the system variable “CAC$Dir” now contains the path to the program, which you can use to construct relative paths:

<CAC$Dir>.Files would point at !CAC.Files
<CAC$Dir>.CACvar would point at !CAC.CACvar

So, for example *Dir SDFS::RISCOSpi.$.CAC.CACvar.Voices would become *Dir <CAC$Dir>.CACvar.Voices

Reworking the program so that it doesn’t need to do *Dir at all (you can make every individual file operation relative to <CAC$Dir>) is also a possibility.

I have several other reasons for suggesting you rework it as an application.

1. Many RISC OS users will be expecting a RISC OS application rather than a standalone program.
2. You can move !CAC (and its contents) anywhere in the directory structure and you would not need to modify the program further. This would allow a user to install !CAC in whatever directory (or on whatever drive) they wanted.
3. You could add a “launcher” front end that multitasks on the desktop and allows the user to (e.g.) select which file they wish to open by dragging the file icon to the “launcher” window, or set the initial parameters (number of bars, beats to the bar) – these parameters would then be passed to CAC itself by additional system variables (e.g. CAC$LoadFile, CAC$BeatsToBar – you get the general idea).
4. The CAC program is quite large (>500k) and could probably do with being divided into its constituent components held as BASIC library files. You might want to do this even if you weren’t converting it to an application.

Running as an application does have its disadvantages:

1. To have the program multitask on the desktop requires a substantial rework of the program. For a start, RISC OS uses cooperative multitasking so the program has to cede control at frequent intervals to allow other Wimp tasks to run alongside it.
2. Following on from the previous point, the cooperative multitasking feature can cause problems with sound playback unless you are particularly careful/lucky (delete as applicable).
3. Displaying text to a window on the desktop is done in a different way. You don’t use MODE commands, for example.
4. Rather than having the entire machine to itself, the program has to request sufficient memory for its needs (that is the purpose of the “WimpSlot” command above). The program can request additional memory after it has started, but for a BASIC program this is easiest to do at the very beginning.

We have avoided most of these for the time being because the program isn’t (yet) multitasking: when you run the program all other desktop tasks are suspended for the duration of the program run.

P.S. I have other suggestions to make regarding the program, but I’ll be raising those as issues on the GitHub page rather than listing them all here.

Just a small note for whoever wrote the user guide – the wibbly Chinese hat character ¹ prefixing a letter is understood pretty much everywhere as meaning to press the Control key, not the Shift key.

It’s not a RISC OS thing, it is pretty ubiquitous in systems that don’t actually write the word Ctrl or Control (now that screen output is graphical and can do such a thing without taking too much space). I suspect the use of ^ to mean control might have begun with something like WordStar ². At any rate, using things like ^L to mean Shift-L is likely to confuse people…

¹ Circumflex or Caret to the pedants.

² CP/M screenshot https://upload.wikimedia.org/wikipedia/commons/f/f5/WordStar.png

You don’t need to do that stuff with the System Sprite Area (there hasn’t really been a need for that since Arthur). To save the current screen as a sprite, OS_SpriteOp 2 will do the job – https://www.riscosopen.org/wiki/documentation/show/OS_SpriteOp%202

That CASE structure in PROCplay. Wow. I gotta go lie down…

I suspect the use of ^ to mean control might have begun with something like WordStar 2.

I’m more inclined to think it comes from the mainframe and terminal era, but most definitely always associated with a control modifier.

The unambiguous shift symbol:

• Unicode 21E7 ⇧
• WindowManager character 139 (when not in UTF-8 alphabet)

The confusion over ^ dates back to the original ASCII standard which had an up arrow in this location (this changed in the 50s), but it was resurrected by the Teletext standard. So all Beebs, Masters, Arcs and RO machines have &5E = ↑ (up arrow) in MODE7.

The vertical bar | is unambiguously “ctrl” in the GSInit/GSRead standard that dates back to the Beeb. The use of ^ to mean control and ⇧ to mean shift is built into the WindowManager’s menu handling of course.

it comes from the mainframe and terminal era,

I think I’ve traced references to the ^ back to the DEC manuals of the late ’60s, bit no PDFs. Certainly pressing control keys in the console (not RISC OS!) is likely to get stuff like ^D printed.

So, yes, we’re back to mainframes and terminals and stuff…

unambiguous shift symbol

Or for a document where you don’t want to faff with Selwyn (or some other symbol typeface), just prefix with “Sh”.

I think I’ve traced references to the ^ back to the DEC manuals of the late ’60s, bit no PDFs.

Yup, that would be the stuff I remember. I think the earliest ones I worked on (repairs) were a couple of VT00’s although there may have been another which was older. Been to sleep a lot of times since those days.
Certainly the majority of the kit that went through was VT220 ‘emulation’ rather than genuine DEC.