Replace [seq~] with Gen
to-the-sun opened this issue · 4 comments
Repository
https://github.com/to-the-sun/amanuensis
Details
Currently all playback cues are stored in a seq~, but I have found discrepancies in timing this object. Basically it has to do with the fact that it cannot be known where in the current vector its read or write heads are compared with other objects relying on that same signal, causing some things to occur out of order on rare occasions. So for example, it's possible for a cue to be added and then immediately played as the seq~ reaches that point a split-second later.
The most ideal way for the program to operate would actually be to handle all of this in Gen instead, allowing for sample-accurate control over recording and playing. It could potentially even speed things up.
All of the relevant information for an audio cue could be stored in a buffer, with a channel for each element of the cues. This buffer could be referenced and manipulated from outside of Gen as well as from within. The functions of seq~ could be replicated in this manner, with a sample of the buffer for each audio cue stored. The most efficient strategy for cleaning up empty samples once audio cues are deleted (and consolidating space in the buffer) can be discussed.
Components
The main area of revamping would be p midiPallete in organism.maxpat, the location of the seq~. Actually this subpatcher would probably be removed entirely. Importing and exporting functionality would need to be replicated for a buffer, as well as the seq~ itself, but once done these components could probably be moved anywhere, most likely near or directly connected to the gen~ progression in p brain.
Other than that, one would need to look for the places where audio cues are added or deleted. All audio cues are currently added in p add_cues
and are currently deleted in cueCleanup of machine.maxpat as well as various places in theCrucible of organism.maxpat, however, with a buffer all deletions will need to be handled via the method in cueCleanup because searching for specific cues will not be so easy. In other words, cues will need to be deleted as the song comes upon them for playback, based upon whether or not they still lie within an active span (of coll A_tracks).
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
Gen~'s lookup buffer can just be a small queue continually reloaded externally as each new cue is is played and removed from it. All that has to be in this buffer is a reference number to to an external coll which will actually store the cues. The reasoning here is that there is no good way in gen to sort or find the lowest number in a buffer, but this can be easily done with a coll. Also there is existing functionality on either side of the gen (record and play) that is already at control rate. Cues can be moved based on the lowest bar index from a "unplayed" coll, to the queue buffer, to a "played". The "played" and "unplayed" collections will need to be switched once there are no more cues to be queued up in the progression of the song. Enough cues should be queued (for each channel) to account for if they are deleted at the filter.
When a span is captured, the queue should be cleared and reloaded otherwise if it was toward the end and already ready for cues back at the beginning, the song would have a gap of silence where the new span laid if it was one that extended the song.
One position number only should need to be loaded at a time and look for in gen. If the reload command takes too long to execute, it will just be played immediately, as the gen ramp will play any cues it is already passed, not just once it comes immediately upon. The danger of this latency growing excessive already exists, but I suppose it would remain to be seen whether seq~ handles this problem more gracefully than switching back and forth between schedulers.
Verify that this is still an issue. Issue #4 may have already solved it