« Return to Thread: [approve, 3.3] Node:map backward compat fix
Re: [approve, 3.3] Node:map backward compat fix
by nescivi
::
Rate this Message:
On Friday 24 April 2009 03:55:43 Scott Wilson wrote:
> 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?
I think it could be a mix of the two.
Have a mapa method for if people want to explicitly map to an audio bus (and
they can use an integer for it too).
And have map also check for the rate and delegate to mapa in case it finds an
audio bus.
then we would also need to keep a mapn and a mapan, in case people want to
specify explicitly the number of channels of a bus, instead of inferring it
from the Bus object.
> 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.
hmmm... not sure about that...
> >>>> 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.
Yes, it should definately throw an error, as it makes no sense to call with no
args.
sincerely,
Marije
_______________________________________________
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/
> 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?
I think it could be a mix of the two.
Have a mapa method for if people want to explicitly map to an audio bus (and
they can use an integer for it too).
And have map also check for the rate and delegate to mapa in case it finds an
audio bus.
then we would also need to keep a mapn and a mapan, in case people want to
specify explicitly the number of channels of a bus, instead of inferring it
from the Bus object.
> 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.
hmmm... not sure about that...
> >>>> 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.
Yes, it should definately throw an error, as it makes no sense to call with no
args.
sincerely,
Marije
_______________________________________________
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/
« Return to Thread: [approve, 3.3] Node:map backward compat fix
| Free embeddable forum powered by Nabble | Forum Help |
