On Fri, Apr 24, 2009 at 3:55 AM, Scott Wilson <
s.d.wilson.1@...> wrote:
> Making audio busses mappable definitely makes the existing semantics murkier
> if we're going to allow integers in map. So I think we have two choices:
> Either we go back to the idea of separate mapa method, or do as James
> suggests below and just make it crystal clear that ints always become
> control busses.
...snip...
> Given the desire to continue to allow Integers, I think maybe the first
> option is cleaner. Opinions?
Another argument in favor of the second option is that audio-rate
mapping is a special case, and it's likely to remain so for the
foreseeable future. (Admittedly we don't have a way to measure yet how
popular ar mapping will become.) So, we could make the basic case as
easy as it was in 3.2; if a little extra syntactical weight is
required for a special case, it's justifiable.
>>>>> Corner case: no arguments supplied. Should it fail with error on
>>>>> "bundle[0].isString" or fail silently?
>>>>>
>>>>> aSynth.map; // die, or no-op?
>>>>>
>
> I think this sort of thing should always fail noisily, unless there is a
> performance penalty incurred in checking for it. aSynth.map or with nil args
> is nonsensical, and allowing this would sooner or later cost someone a lot
> of debugging time.
Just doublechecked this -- we would need to add an extra test for an
empty result. I mistakenly thought mapMsg would return nil if both kr
and ar lists were empty, but actually it returns []. So bundle[0] is
nil and isString is false.
I'm OK to add the check, e.g. below. Also better to have a human-readable error.
mapMsg { arg ... args;
var krVals, arVals, result;
if(args.size > 0) {
...rest of method...
} {
MethodError("Node:map / Node:mapMsg require an argument list, but
none was supplied.", this).throw;
}
}
hjh
--
James Harkins /// dewdrop world
jamshark70@...
http://www.dewdrop-world.net"Come said the Muse,
Sing me a song no poet has yet chanted,
Sing me the universal." -- Whitman
_______________________________________________
sc-dev mailing list
info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtmlarchive:
http://www.listarc.bham.ac.uk/marchives/sc-dev/search:
http://www.listarc.bham.ac.uk/lists/sc-dev/search/