SEPARATE READ/WRITE HEADS: a task request for the open source project The Amanuensis: Automated Songwriting and Recording
utopian-io·@to-the-sun·
0.000 HBDSEPARATE READ/WRITE HEADS: a task request for the open source project The Amanuensis: Automated Songwriting and Recording
#### Repository https://github.com/to-the-sun/amanuensis #### Details Currently recording and playback follow the same loop; where the playback is being heard at any given time is the same place where new recording will occur. However there could be some significant advantages in utilizing separate read and write heads. This would mean that the song would not extend until _after_ a new recording has been captured, rather than the playback following along in silence with the write head as it records beyond the bounds of the song, extending it in real time. The read head could loop on what's already been recorded while the write head records off into space, giving the user a continual backing track without big gaps of silence. Not having to extend the total length of the song in real time would simplify a lot of code as well. It could potentially even make things run faster, considering certain things would only update at broad intervals rather than in a continual fashion. It also alleviates a major complexity dealing with the fact that every note has a variable delay as it waits for the UDP round-trip to the Python script and back before the analysis associated with it can be used. There are bugs that have still not been worked out caused by that lag spanning the loop point between end and beginning of song. But if the playback is on its own loop, it doesn't matter when the analysis (and therefore the command to start or stop recording) comes back. #### Components Most if not all of the changes would take place in the untitled [gen~] object located in the [p brain] subpatcher of organism.maxpat. The codebox within it is responsible for generating the ramp which specifies the current position in the song. The "ramp" variable there as well as [send~ ---phasor] and the continually updated fifth index of the "stats" buffer that it feeds would be the affected points. It remains to be seen whether anything beyond that scope would need to be altered.  #### Deadline There is no deadline, but we can discuss how long it might take to execute. #### Communication Reply to this post or contact me through Github for more details. #### Proof of Work Done https://github.com/to-the-sun