On Dec 28, 2008, at 7:16 PM, Julian Rohrhuber wrote:
have you tested efficiency? This is important, because we use
events in granular synthesis.
The efficiency of #1 has been tested. The current msgFunc performs
about the same regardless of how many synth args exist in the event
(all or just a few). My proposal performs only very slightly worse
in the worst case (all arguments in the event) and significantly
faster with fewer arguments in the event.
yes, this makes sense, also as a possibility of acceleration.
SynthDesc lookup with the match method would definitely be slower,
possibly not worth it. I haven't benchmarked.
A better approach might be to use \instrument for the def name
without variant, and another key \variant for the variant name
(allowing \none to bypass the variant, since nil isn't an
acceptable return value for a Pbind child stream).
this seems a better solution. if there is a variant, its name can be
cheaply added to the instrument name and just sent off.
Then, put the variant defaults into the event's proto level. But
this could be icky because Event protos are not copied and probably
there would be garbage from one variant left over after the event
played.
I think it would be enough if the variant name was sent over, not
caing about overriding of common parameters, which we would expect
to be overridden anyway. Probably one would prefer to use special
parameters for variants anyway. (Not sure..).
Sorry to be so bold: What are the variants good or if you have
events anyway? I don't see the utility. I would rather find it
interesting to dynamically combine ugen graphs and store their
synthdefs implicitly than just support another layer of
parameterisation.
For myself, I don't really care about variants. It's just they are
a feature of synthdefs that is currently useless with patterns, and
I thought it might be nice to have a better answer than "it's just
not supported."
I don't recall who added variants.
James McCartney did, if I remember correctly.
In hindsight I'm not sure it was a good idea to put them in. I
don't see any evidence that it's a widely used feature, but there
is a maintenance cost in deciding where it will and will not be
usable. Either that, or there is inconsistency in having a feature
that works in only in basic parts of the platform but not in some
important, higher-level areas.
yes, you are right, either support it everywhere or nowhere.
--
.
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/