Is there a method to send a gate 0 to a pattern in the middle of a long sustained note short of explicitly freeing the node or group on the server? So if I have
(
Pdef(\test, Pbind(\dur, Pseq([5]))).play
)
and I want to release the note after 2 seconds, ie. 3 seconds before it is scheduled to release. Is there something like Pdef(\test).methodToSendGateOff?
What I really want is for the dur the be = inf, in other words a pattern which can work both as pattern and as a normal sustaining synth depending on the circumstance.
Yes, that would be nice to have. I think the only place that could meaningfully know about that synth would be the EventStreamPlayer. The outEvent in prNext is hidden, but if it were an instance variable, it could be released. But there is the issue that several events may be running at the same time, and may equally deserve a gate off. This looks like a case for a dedicated pattern.
If your pattern is simple, and not using features like strum, Ppar, Pspawner, etc, one approach is to use a hybrid Pattern/Routine approach. By this, I mean getting the Events with Pattern:asStream and using a Routine or Task to turn the Events into server commands. This gives you transparency and control in how the events are played while still letting you use the terse Pattern syntax for the sequences themselves.
These concerns are correct – and highlight that the original question seems simple but is more complicated in reality. It would take careful design to get it right (which I mention only because there are plenty of examples in SC of hasty additions that turned out to carry technical debt).
outEvent as an instance variable would give access only to the latest event. If the penultimate event had a long sustain but the most recent event is short, this would not help.
In the multiple-sustaining-events case, what rule decides how to proceed? A simple rule is likely to limit the number of cases where an adhoc release pattern would be useful; more complexity would make the class harder to use.
I did implement infinite-sustain logic in my live coding system, for slurs (legato portamento in traditional synths). It was not easy. At minimum, it requires node state tracking, for cases such as, the event requests an infinite sustain but the synth ended on its own power. Is it the event’s job to handle this? (Drawback: the event prototype is already complicated.) Or a wrapper pattern? (How to distinguish note events from others that should just pass through?) Or perhaps there could be a note-manager class that would be generally useful, not only for patterns, and the event would go through this object to create synths. (That’s the approach I took, since I already have a note manager = Voicer.)
Nathan’s suggestion has the advantage of high flexibility (easily adaptable to edge cases).
In sum, this is harder than it seems. Don’t gloss over the hard design decisions because, if you don’t, they will bite you later.