Re: [approve, 3.3] Node:map backward compat fix

Ah, the mixture of object and messaging styles rears its head once  
again.

Sorry this is my fault. I had meant when updating Node:map to use  
asBus. I think what happened is that I got a little hung up on the  
rate issue with asBus, and forgot to resolve it in the end.

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.

The former idea has the advantage that it makes it clear what will  
happen to ints, and gets rid of the slight ugliness of a possible  
double message from mapMsg. The latter has the convenience of allowing  
for mapping both audio and control busses in the same call.

Given the desire to continue to allow Integers, I think maybe the  
first option is cleaner. Opinions?

Of course in an ideal world Object style would have been worked out at  
the start to only allow Bus objects if you're referring to a bus.

Actually in an ideal world you wouldn't need map at all, and could do  
everything with set. The only reason we still need map really is  
because of In and Out UGens. I'm not sure if there is a way of  
cleaning that up that would allow backwards compatibility, but that  
might be worth thinking about for 3.4.


>>>>
>>>> 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.

S.

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/