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!
- What feature(s) did you add?
When auditioning passes for a comp it could be tricky to keep track of which pass you were hearing and in what track, as all of it previously had to be done by ear. This update makes things more explicit and easy-to-deal-with in two ways.
First is in regards to which track the comping is taking place in. The default method of choosing a track for hotkeys, etc to affect has always just been the one to most recently reveive MIDI input and this was the way comping functioned as well. But being that most likely editing of the song like this will be taking place when you're not actually playing anything, it proved unintuitive and impractical to choose your track this way. Now the track to comp is chosen with the UP/DOWN arrow keys, in the same manner as when selecting specific cues to delete.
Second, a flashing rectangle appears on the UI on the track in question denoting the length of the loop. Useful information also appears in the rectangle, imparting the pass number as well as the audition number (which 2-9 hotkey was pressed to activate the audio for that pass). If no pass is playing (hotkey 1 or a hotkey with no association), the rectangle disappears, to show that the original recorded material is being heard.
You can watch the comping process in action below, but unfortunately I couldn't get the audio recording in the video.
- 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 present the work that was completed using images instead. Read the comments in those to get an idea of how the code works. I'll keep my description here about the process of writing that code.
These are the primary commits involved:
Alternate methods were contemplated, but it was settled upon to use the same functionality as when deleting specific cues to change tracks. This meant that the flashing cursor denoting the selected cue would also appear while comping, but this didn't seem detrimental enough to warrant another, more convoluted approach. In either case the flashing UI elements mean the process of editing has been engaged, so it makes some sense.
The track info during the cue removal process was being conveyed through
s ---prev/next_beat in the form of a list with first element the track integer and a second element of a string indicating movement of the cursor. Only the first element was relevant to this application, so everywhere the former
r midiChannel had been determining the comping track, it was replaced with
r ---prev/next_beat followed by an
In adding these UI elements and deciding how they should look, the opportunity was taken to renovate the appearance of the tracks and spans themselves. A light gray
panel was set in the background of each track and the spans were made to appear the same color as the background without borders. This makes them much less obtrusive for the text and menus on top of them, yet still conveys the same information. In contrast, the flashing border of an auditioning comp stands out prominently, as all user-alterable elements in the UI scheme are supposed to.
p comp_position, the new subpatcher in track.maxpat, and the added code in
p controls that shows/hides the UI elements as appropriate
I'm quite happy with the way the text looks as well, utilizing two
comments, one with bold size-12 font denoting the user-alterable control, the hotkey, that was pressed to audition that pass.
the UI objects involved
It became necessary for the auditions and their associated passes to be reassessed if the loop was altered, as the length of the flashing span as well as the present passes within it would not change to reflect visually what was being heard. Now the flashing rectangle moves in real time with the user dragging the
rslider and you can even use this functionality to "scan" an area for cues in any pass. If there are none in a certain area, the rectangle will disappear.
the section of code in GUI.maxpat concerning the loop's
rslider, reworked in this update
Cleanup and commenting