To pick up on what scztt was saying:
The \lag
keyword is not a pattern problem. The pattern system is 100% agnostic about this keyword.
It’s also not an event problem. (The minimum requirement for an event is that it should understand play
, and delta
, and playAndDelta
methods… I think there are a few other methods like isRest
but the surface area of the baseline Event interface is very small.)
\lag
is defined in the default event prototype.
You can use patterns, and events, without using the default event prototype at all. Or, as scztt correctly notes, you can use the default event prototype, but define an event type function that uses \lag
however you want. We commonly use the default event prototype’s built-in event types with events and patterns, but there is no inherent binding between those.
(However, in this case, Pmono and PmonoArtic specifically use event types \monoNote
and \monoSet
– you can’t override the \type
so easily for these patterns, because the node-tracking requirement is more difficult than the usual case. But, you could define a completely separate event prototype that defines these two event types differently.)
~~
The major advantage of events is that they separate data production from data performance.
So you have a routine that plays notes in the way you want. Now you think, I’d like to spit these notes out over MIDI to, say, VCV Rack, or hardware. Probably you had just written Synth(something)
embedded in routine… so now you have no choice but to hand-edit the manner of performance… in every affected routine… a potentially large and error-prone job.
The documentation should (but doesn’t) recommend using helper functions to play the notes.
~playNote = { |... parameters ...|
... do stuff to play the note ...
};
r = Routine {
loop {
... make data...
~playNote.(... data ...);
delta.wait;
}
};
Then you can just replace the function in order to change the routine’s performance behavior – data production and usage are abstracted away from each other, and you gain the benefit of easy extensibility.
Then someone will think, gosh, it would be great if there were a library of data-performance functions. But… there already is a library: the default event prototype. And it’s easy to add functions to this library: Event.addEventType
.
It’s true that the provided data-performance functions bring with them a lot of assumptions, and not every user likes those assumptions. But then that leads to a handful of wrong conclusions. For example, “I prefer routines” seems to assume tacitly that the way to have control over the process is to do away with note-playing functions altogether. Well, no… the fact that the default \note
event type defines \lag
in a way that you don’t like doesn’t mean that the idea of a \note event type is a bad one. It’s actually a very good idea, for extensibility. It just means that this particular note-performance function is not a good fit for your use case, and that another one would be a better fit.
I’m soapboxing a bit, but I’m skeptical of the tendency to pitch out the baby with the bathwater where Events are concerned.
hjh