[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] SynthDef variant support for patterns

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/