logo by @camiloferrua
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?
Two new upgrades have been implemented concerning the synths (VSTs) the system utilizes.
The first is simply that it can now handle VSTs found in subfolders, so the user does not need to put all of their plug-ins in the same folder.
The second has been a big stumbling block for new users since the beginning. Previously each VST you used needed to have its number of presets manually entered into a text file called synthTaste.txt in a very specific format. Now whenever a new VST is encountered, the system automatically counts the number of presets it has so it will be ready to use without problems no matter what.
The thing about this process is that each VST is different: some don't have presets, some have presets you can use but register as though they don't and some act like they have a large number of presets but most of them are actually just "Empty" (and perhaps can be filled with user-defined presets). So, although now any VST you offer to the system will be usable, the auto detect function will not always allow you access to the exact number of presets you were expecting. If this happens, you can always still manually enter what you know to be the right number and it will use that.
Rather than needing to create a separate text file, you can now do this simply by opening Amanuensis.json (the file where all of your saved settings are stored), finding dict[2] and editing the number that appears after the VST in question.
SIDE NOTE: I have been unable to figure out how to rename this dictionary as it appears in this file. I've named the pattr object, the dict object and given it a scripting name, but no luck. Anyone with any insights is welcome to comment.
You can also open up the new preset_counting_vst~.maxpat abstraction on its own if you need to test exactly how many usable presets your VSTs have (see the screenshot of it below).
- 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:
Getting the system to handle VSTs in subfolders was deceptively tricky. VST names are referenced throughout the system and in order to keep these references robust it is necessary to store and recall based only on the file name (without path), so that if settings are changed or files moved around the same VST will still be recognized as that VST. However, there is one place that needs the full path and that's when the actual VST is loaded. At that time the path cannot be concatenated from your specified synth folder and the file name without losing any subfolders in between.
At first I tried always sending the full path when the menu of available synths is populated, then simply chopping off the path from the file name when it was not desirable, but this caused problems because synth names are stored and recalled from elsewhere as well, namely with each project's sound settings. In the end it became necessary to create a reference when the menu is populated (and their locations identified), which could be used anywhere else in the program to find the full path from just the VST file name.
the new create_reference subpatcher in synth.maxpat, complete with commenting
In implementing the preset auto-count functionality, the vsti.maxpat abstraction was almost completely reworked and a new abstraction, preset_counting_vst~.maxpat, was created for loading within it. Rather than creating vst~ objects dynamically via scripting and connecting them up to outlets, etc., I have been finding good success with creating entire abstractions by scripting. The results are much cleaner and easier to understand.
the reworked portion of code in vsti.maxpat responsible for creating your suite of VSTs, complete with commenting (notice the use of the aforementioned reference coll)
It became necessary to rework the way the messages were sent to the vsts, which had previously relied on scripting as well (messages cannot be sended directly to abstractions via scripting).
the reworked portion of code in vsti.maxpat responsible for sending messages to VSTs, complete with commenting
Below is the brand-new abstraction preset_counting_vst~.maxpat. It instituted a new dict, vst_presets, which was hooked up to the pattr system elsewhere.
the new preset_counting_vst~ abstraction, complete with commenting
Previously the code seen below was utilized once in vsti.maxpat and audio was routed from each vst~ by actually connecting patch cords with scripting. This was much messier, so the functionality was moved within each abstraction and the audio routed closest to its source. Doing so required the reworking of some code however, in order to determine track number from within multiple abstractions.
p route~ in preset_counting_vst~.maxpat, complete with commenting
GitHub Account
To see a full history of updates, blog posts, demo songs, etc., check out my Steemit blog @to-the-sun.
Until next time, farewell, and may your vessel reach the singularity intact
To the Sun