Open eleses opened 4 years ago
@eleses - thanks for spotting that, and you are right, they are obsolete and can actually be removed now.
For curiosity, I made a blend2 method which has left, right, sect, union merge modes, and runs ca 5x faster than blend does at the moment. Curious to hear your opinion on this one :-)
/* \freq.asSpec.blend(20, 2000); // 200
a = (freq: 20, amp: 0.5, dist: 23); b = (freq: 2000, pan: 0.2, dist: 12);
bench { 10000.do { a.blend2(b, 0.5, \left, nil, false) } } bench { 10000.do { a.blend(b, 0.5) } };
a.blend2(b, 0.5, \sect) a.blend2(b, 0.5, \right) a.blend2(b, 0.5, \union)
*/
ControlSpec { blend { |val1, val2, blend = 0.5| ^this.map( this.unmap(val1).blend( this.unmap(val2), blend ) ); } }
Dictionary { // mode is one of [ \left, \right, \sect, \union ] blend2 { |dict2, blend = 0.5, mode = \left, specs, warnIfSpecMissing = true| var res;
// if right, swap left <-> right
if (mode == \right) {
^dict2.blend2(this, blend, \left, specs, warnIfSpecMissing);
};
res = this.class.new;
this.keysValuesDo { |key, lval|
var newval;
var rval = dict2[key];
var spec = specs ? Spec.specs[key];
if (rval.isNil) {
if (mode != \sect) {
res.put(key, lval)
};
} {
// we have both values
newval = if (spec.notNil) {
spec.blend(lval, rval, blend)
} {
if (warnIfSpecMissing) {
"%: no spec for key % - blending linear.\n".postf(
thisMethod, key.cs);
};
lval.blend(rval, blend);
};
res.put(key, newval)
}
};
if (mode == \union) {
dict2.keysValuesDo { |key, rval|
if (res[key].isNil) {
res[key] = rval
}
}
};
^res
} }
I don't understand what is the point of
Dictionary.blendUni
inextDictBlend.sc
. It has the exact same implementation asblend
in the same file.Furthermore, looking at the default implementation of
Dictionary.blend
in SC 3.10+ (and might be true even in some earlier versions), the whole functionality ofextDictBlend
has apparently been merged in the SC mainline classlib. TheDictionary.blend
implementation in classlib is somewhat different as it relies onmerge
, but I don't see any big differences in functionality now between whatextDictBlend
provides and what classlib provides forDictionary.blend
.Actually, on closer look, there is one difference that I found, which is might be considered a bug in
extDictBlend
that's been removed in classlib (or a feature added in the latter).extDictBlend
does:which bombs with error for the (2nd) example from the current SC help page, copied below:
but this example works ok with the classlib
blend
implementation because the latter adds/does anasSpec
And there's one semantic difference too,
extDictBlend
does:so regardless of
fill
value at the extreme ends uncommon keys are added unconditionally but directionally. In contrast, withblend
from classlibThe classilib implementation is more consistent, but it only does inner (
fill
=false) and outer joins (fill=true
) in database terms.extDictBlend
does left- and right- joins at the extremes.