That isn’t true.
I thought I’d give a short implementation of what I suggested.
PrEventBase {
var rollingEvent;
*new { |...kvs|
^super.newCopyArgs(kvs.asEvent);
}
asEvent { ^rollingEvent }
add {|k, v|
rollingEvent[k.asSymbol] = v;
^this
}
dur {|v| ^this.add(\dur, v) }
}
NoteEvent : PrEventBase {
var rollingEvent;
*new { |...kvs|
^super.newCopyArgs(kvs.asEvent ++ (\type : \note));
}
asEvent { ^rollingEvent }
instrument { |v| ^this.add(\instrument, v) }
}
…and how it should be used …
Pbind(NoteEvent(
\instrument, \synthA,
\dur, 1,
\freq, Pwhite()
))
It is just a wrapper, same syntax.
This way you can add the documentation for each key in the event and there are no restrictions on what else can be added, the methods are really only there to provide examples of what the default keys do. There should also be a ++ operator which gobbles the keys on the left, expect the \type key. There would have to be a little preamble explaining that, whilst the methods can be used, the intended purpose is that they are supplied in the constructor.
Also, no need for any other implementation, whilst the implementation of \callback (for example) should be mored into this class, it doesn’t have to be immediately. This makes it compatible with the existing version and allows for it to be implemented gradually.
If you consider the class system as a type system instead, I think this makes even more sense given the key that varies is \type.
Is this still ugly?
Sorry, could you elaborate on what the difference is? I don’t understand.
Except from all the scheme functions which are often left out or missing argument descriptions. It think this is a similar kind of problem here where there is a different type of code/data that the docs where not originally designed for and has been neglected as a result. The only way to write custom callbacks in lilypond is to search through the source code to understand what scheme functions exist and how to use them.