Singing Stream's AUDIO STREAMS TREATED AS INDIVIDUAL INSTRUMENTS: a new feature for the open-source project The Amanuensis: Automated Songwriting and Recording

Repository

https://github.com/to-the-sun/amanuensis

The Amanuensis is an automated songwriting and recording system aimed at ridding the process of anything left-brained, so one need never leave a creative, spontaneous and improvisational state of mind, from the inception of the song until its final master. The program will construct a cohesive song structure, using the best of what you give it, looping around you and growing in real-time as you play. All you have to do is jam and fully written songs will flow out behind you wherever you go.

If you're interested in trying it out, please get a hold of me! Playtesters wanted!

New Features

• What feature(s) did you add?

The main upgrade the user will notice is that when interpreting audio streams into MIDI (via Singing Stream), each input on your audio driver is treated as an individual instrument. This means that they do not all have to share the same channel/track, generated pitch, etc. While other sources found by Singing Stream, such as external game controllers, treat the individual controls as part of one larger instrument, this is not generally the way you would like it to treat your audio interface, as each input is likely to have a single larger instrument plugged into it, i.e. a guitar, a microphone, etc.

This feature update also includes various other related renovations to the audio stream system, including the handling of larger audio drivers and a more robust way of saving and recalling your chosen settings.

• How did you implement it/them?

If you're not familiar, Max is a visual language and textual representations like those shown for each commit on Github aren't particularly comprehensible to humans. You won't find any of the commenting there either. Therefore, I will do my best to present the work done in images instead.

These are the primary commits involved:

• Commit #1

p audioin singingstream.maxpat was reworked, accounting for the possibility of no audio driver being selected firstly, and also removing a cycleobject which was causing drivers with large numbers of inputs to be mislabeled and otherwise misrepresented from that point forward.

Most of the changes made in this commit are no longer evident, as the lower half of this patcher was essentially removed and replaced with the audio_streamabstractions you see here (explained in the following commit)

• Commit #2

The audio_streamabstraction was created to more cleanly allocate audio from the various inputs. The fundamental difference was in utilizing multiple [adc~ #1]s (with a variable argument) rather than one large one with many fixed arguments. The use of these numbered abstractions allows for easier specialization of individual inputs.

The audio_streamabstraction and its subpatcher stream_name

• Commit #3

The first change involved in this commit was to specify each audio input as its own "device" in dict ---specs. In the preceding screenshot you can see that each audio_streamabstraction sends its individual stream name out its outlet. This is then sent to initialize the "device", whereas this had previously been sent from higher up the chain, prior to the combinein p audio, with the audio driver's name itself.

A second and more systemic issue was also rectified involving Singing Stream's settings being recalled improperly. Although the implications stretched beyond just audio streams, it was particularly aggravating in their case. This is because the deactivated state of the streams was not being recalled when it had been saved prior, so each stream was sending readings as soon as the patch loaded, triggering all sorts of notes to be played, etc. This was multiplied many-fold once inputs had been designated as their own devices and became a very pertinent issue to fix.

It was discovered that because of filepath default, singingstream.json among other things, was being saved in various locations and not just in the Amanuensis folder itself, as expected. The defaultargument apparently changes if you open other patchers beyond the one it's contained in. I still don't understand exactly how it works, but I circumvented the issue by saving the correct location in v ---filepath upon startup to be used as necessary later throughout the entire program.

this shows first the snippet of code that saves the correct path (in Amanuensis.maxpat) and then one example of its use in singingstream.maxpat

GitHub Account

https://github.com/to-the-sun