[approve, 3.3] Node:map backward compat fix

[James Harkins-2]

in Node.sc, right?

yes it appears to work..

thank you~

OK to check in then?

Sorry I didn't catch this earlier - if I realized compatibility would be broken on a basic feature, I would have spoken up before RC. I feel rather strongly we should not let 3.3 go out losing backward compat on what was, in 3.2, normal and expected usage (especially since the fix is simple and wouldn't break anything else).

Corner case: no arguments supplied. Should it fail with error on "bundle[0].isString" or fail silently?

aSynth.map; // die, or no-op?

Actually better -- bus = bus.asBus -- to allow polymorphic substitution. Then we wouldn't need the scalar branch, I think. (I just realized, in current svn, the usage "aSynth.map(\anArg, aGenericGlobalControl)" got broken [GenericGlobalControl is in my lib], where it would have worked in 3.3 betas. GenericGlobalControl can masquerade as a Bus using asBus, so this would fix that case.)

map { arg ... args;

var bundle = this.mapMsg(*args);

if(bundle[0].isString) {

server.sendBundle(nil, bundle);

} {

server.sendBundle(nil, *bundle);

};

}

mapMsg { arg ... args;

var krVals, arVals, result;

krVals = List.new;

arVals = List.new;

result = Array.new(2);

args.pairsDo({ arg control, bus;

bus = bus.asBus;

switch(bus.rate)

{ \control } {

krVals.addAll([control.asControlInput, bus.index, bus.numChannels])

}

// maybe we don't need this anymore

// { \scalar } {

// if(bus.isNumber) { krVals.addAll([control.asControlInput, bus, 1]) };

// }

{ \audio } {

arVals.addAll([control.asControlInput, bus.index, bus.numChannels]);

};

// no default case, ignore others

});

if(krVals.size > 0, { result = result.add(["/n_mapn", nodeID] ++ krVals) });

if(arVals.size > 0, { result = result.add(["/n_mapan",nodeID] ++ arVals) });

if(result.size < 2, { result = result.flatten; });

^result;

}

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

[Josh Parmenter]

What do the rest of you think? Does this warrant a new RC if this is the only change?

Josh

On Apr 23, 2009, at 8:24 PM, James Harkins wrote:

in Node.sc, right?

yes it appears to work..

thank you~

OK to check in then?

Sorry I didn't catch this earlier - if I realized compatibility would be broken on a basic feature, I would have spoken up before RC. I feel rather strongly we should not let 3.3 go out losing backward compat on what was, in 3.2, normal and expected usage (especially since the fix is simple and wouldn't break anything else).

Corner case: no arguments supplied. Should it fail with error on "bundle[0].isString" or fail silently?

aSynth.map; // die, or no-op?

Actually better -- bus = bus.asBus -- to allow polymorphic substitution. Then we wouldn't need the scalar branch, I think. (I just realized, in current svn, the usage "aSynth.map(\anArg, aGenericGlobalControl)" got broken [GenericGlobalControl is in my lib], where it would have worked in 3.3 betas. GenericGlobalControl can masquerade as a Bus using asBus, so this would fix that case.)

map { arg ... args;

var bundle = this.mapMsg(*args);

if(bundle[0].isString) {

server.sendBundle(nil, bundle);

} {

server.sendBundle(nil, *bundle);

};

}

mapMsg { arg ... args;

var krVals, arVals, result;

krVals = List.new;

arVals = List.new;

result = Array.new(2);

args.pairsDo({ arg control, bus;

bus = bus.asBus;

switch(bus.rate)

{ \control } {

krVals.addAll([control.asControlInput, bus.index, bus.numChannels])

}

// maybe we don't need this anymore

// { \scalar } {

// if(bus.isNumber) { krVals.addAll([control.asControlInput, bus, 1]) };

// }

{ \audio } {

arVals.addAll([control.asControlInput, bus.index, bus.numChannels]);

};

// no default case, ignore others

});

if(krVals.size > 0, { result = result.add(["/n_mapn", nodeID] ++ krVals) });

if(arVals.size > 0, { result = result.add(["/n_mapan",nodeID] ++ arVals) });

if(result.size < 2, { result = result.flatten; });

^result;

}

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

[ronald kuivila]

Hi Josh,

 Maybe we should declare a one week feature freeze and add it as a bug fix after that.

RJK

On Apr 24, 2009, at 12:33 AM, Josh Parmenter wrote:

What do the rest of you think? Does this warrant a new RC if this is the only change?

Josh

On Apr 23, 2009, at 8:24 PM, James Harkins wrote:

in Node.sc, right?

yes it appears to work..

thank you~

OK to check in then?

Sorry I didn't catch this earlier - if I realized compatibility would be broken on a basic feature, I would have spoken up before RC. I feel rather strongly we should not let 3.3 go out losing backward compat on what was, in 3.2, normal and expected usage (especially since the fix is simple and wouldn't break anything else).

Corner case: no arguments supplied. Should it fail with error on "bundle[0].isString" or fail silently?

aSynth.map; // die, or no-op?

Actually better -- bus = bus.asBus -- to allow polymorphic substitution. Then we wouldn't need the scalar branch, I think. (I just realized, in current svn, the usage "aSynth.map(\anArg, aGenericGlobalControl)" got broken [GenericGlobalControl is in my lib], where it would have worked in 3.3 betas. GenericGlobalControl can masquerade as a Bus using asBus, so this would fix that case.)

map { arg ... args;

var bundle = this.mapMsg(*args);

if(bundle[0].isString) {

server.sendBundle(nil, bundle);

} {

server.sendBundle(nil, *bundle);

};

}

mapMsg { arg ... args;

var krVals, arVals, result;

krVals = List.new;

arVals = List.new;

result = Array.new(2);

args.pairsDo({ arg control, bus;

bus = bus.asBus;

switch(bus.rate)

{ \control } {

krVals.addAll([control.asControlInput, bus.index, bus.numChannels])

}

// maybe we don't need this anymore

// { \scalar } {

// if(bus.isNumber) { krVals.addAll([control.asControlInput, bus, 1]) };

// }

{ \audio } {

arVals.addAll([control.asControlInput, bus.index, bus.numChannels]);

};

// no default case, ignore others

});

if(krVals.size > 0, { result = result.add(["/n_mapn", nodeID] ++ krVals) });

if(arVals.size > 0, { result = result.add(["/n_mapan",nodeID] ++ arVals) });

if(result.size < 2, { result = result.flatten; });

^result;

}

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

[Josh Parmenter]

I think that makes LOTS of sense. Especially since so far today, the number of bug reports today has been on the small side.

James - sound good?

Josh

On Apr 23, 2009, at 9:37 PM, ronald kuivila wrote:

Hi Josh,

 Maybe we should declare a one week feature freeze and add it as a bug fix after that.

RJK

On Apr 24, 2009, at 12:33 AM, Josh Parmenter wrote:

What do the rest of you think? Does this warrant a new RC if this is the only change?

Josh

On Apr 23, 2009, at 8:24 PM, James Harkins wrote:

in Node.sc, right?

yes it appears to work..

thank you~

OK to check in then?

Sorry I didn't catch this earlier - if I realized compatibility would be broken on a basic feature, I would have spoken up before RC. I feel rather strongly we should not let 3.3 go out losing backward compat on what was, in 3.2, normal and expected usage (especially since the fix is simple and wouldn't break anything else).

Corner case: no arguments supplied. Should it fail with error on "bundle[0].isString" or fail silently?

aSynth.map; // die, or no-op?

Actually better -- bus = bus.asBus -- to allow polymorphic substitution. Then we wouldn't need the scalar branch, I think. (I just realized, in current svn, the usage "aSynth.map(\anArg, aGenericGlobalControl)" got broken [GenericGlobalControl is in my lib], where it would have worked in 3.3 betas. GenericGlobalControl can masquerade as a Bus using asBus, so this would fix that case.)

map { arg ... args;

var bundle = this.mapMsg(*args);

if(bundle[0].isString) {

server.sendBundle(nil, bundle);

} {

server.sendBundle(nil, *bundle);

};

}

mapMsg { arg ... args;

var krVals, arVals, result;

krVals = List.new;

arVals = List.new;

result = Array.new(2);

args.pairsDo({ arg control, bus;

bus = bus.asBus;

switch(bus.rate)

{ \control } {

krVals.addAll([control.asControlInput, bus.index, bus.numChannels])

}

// maybe we don't need this anymore

// { \scalar } {

// if(bus.isNumber) { krVals.addAll([control.asControlInput, bus, 1]) };

// }

{ \audio } {

arVals.addAll([control.asControlInput, bus.index, bus.numChannels]);

};

// no default case, ignore others

});

if(krVals.size > 0, { result = result.add(["/n_mapn", nodeID] ++ krVals) });

if(arVals.size > 0, { result = result.add(["/n_mapan",nodeID] ++ arVals) });

if(result.size < 2, { result = result.flatten; });

^result;

}

hjh

: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

******************************************

/* Joshua D. Parmenter

http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono

*/

[Scott Wilson-3]

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/

[nescivi]

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/

[Scott Wilson-3]

On 24 Apr 2009, at 15:28, nescivi wrote:

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

Sorry, but isn't that potentially a little confusing? If there're two  
methods it'd be nicer if it was clearly divided, or?

I suppose really mapk and mapa would make sense, but then the number  
of methods proliferates, unless we deprecate map.

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

Yeah, me neither. Just an idle daydream...

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/

[James Harkins-2]

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.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[Josh Parmenter]

On Apr 24, 2009, at 7:28 AM, nescivi wrote:

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


This wouldn't work. Even if there is an AudioControl as a SynthDefs  
arg, you can still map a control bus to it (and the values are  
linearly interpolated for you).

Best,

Josh

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
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/

[James Harkins-2]

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.

Third option for the future:

Part of the SynthDef refactoring could be to retain metadata in memory
for EVERY synthdef (without having to explicitly store them in the
SynthDescLib). Then we would know the rate for each control name. If
the integer is associated with an AudioControl, map it as audio etc.

SynthDesc probably doesn't (yet) track controlname rates. It should.
Probably too late to do that for 3.3.

The typical throwaway use of SynthDefs in the client (by which I mean,
build>send>garbage collect) imposes some limitations that would not be
issues if the client retained more intelligence about the available
defs.

Josh's comment:

>This wouldn't work. Even if there is an AudioControl as a SynthDefs arg, you can still map a control bus to it (and the values are linearly interpolated for you).

Cross-mapping buses could be considered a special case. The assumption
would be, if you give an integer bus number and no other information,
then match the rate. If you want to map a kr bus to an ar input, you
need to be explicit about it.

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.shtml
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/

[nescivi]

On Friday 24 April 2009 10:57:32 Josh Parmenter wrote:

> On Apr 24, 2009, at 7:28 AM, nescivi wrote:
> > 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.
>
> This wouldn't work. Even if there is an AudioControl as a SynthDefs
> arg, you can still map a control bus to it (and the values are
> linearly interpolated for you).

check for the rate of the bus, not the control.

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/

[Josh Parmenter]

On Apr 24, 2009, at 8:12 AM, nescivi wrote:

> On Friday 24 April 2009 10:57:32 Josh Parmenter wrote:
>> On Apr 24, 2009, at 7:28 AM, nescivi wrote:
>>> 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.
>>
>> This wouldn't work. Even if there is an AudioControl as a SynthDefs
>> arg, you can still map a control bus to it (and the values are
>> linearly interpolated for you).
>
> check for the rate of the bus, not the control.

Ah - in the bus class... I see. Sorry about the confusion.

josh

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

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/


_______________________________________________
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/

[Scott Wilson-3]

On 24 Apr 2009, at 15:57, Josh Parmenter wrote:

> On Apr 24, 2009, at 7:28 AM, nescivi wrote:
>
>> 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.
>
>
> This wouldn't work. Even if there is an AudioControl as a SynthDefs  
> arg, you can still map a control bus to it (and the values are  
> linearly interpolated for you).
>

It works fine already in the current code. The distinction is between  
audio and control busses, not controls.

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/

[Scott Wilson-3]

On 24 Apr 2009, at 15:54, James Harkins wrote:

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

Well the real special case will be mapping an audio bus specified by  
an Integer, which is the only case that will need some extra work.  
That I think is unlikely to see much use even if ar mapping is the new  
sliced bread.

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/