[PD] settable receive again
Jonathan Wilkes
jancsika at yahoo.com
Sat Jun 9 20:21:38 CEST 2012
----- Original Message -----
> From: Cyrille Henry <ch at chnry.net>
> To: Jonathan Wilkes <jancsika at yahoo.com>
> Cc: Roman Haefeli <reduzent at gmail.com>; "pd-list at iem.at" <pd-list at iem.at>
> Sent: Saturday, June 9, 2012 12:55 PM
> Subject: Re: [PD] settable receive again
>
>
>
> Le 09/06/2012 18:36, Jonathan Wilkes a écrit :
>> ----- Original Message -----
>>
>>> From: Cyrille Henry<ch at chnry.net>
>>> To: Jonathan Wilkes<jancsika at yahoo.com>
>>> Cc: Roman Haefeli<reduzent at gmail.com>;
> "pd-list at iem.at"<pd-list at iem.at>
>>> Sent: Saturday, June 9, 2012 7:08 AM
>>> Subject: Re: [PD] settable receive again
>>>
>>>
>>>
>>> Le 08/06/2012 19:15, Jonathan Wilkes a écrit :
>>>
>>>>> anyway, if you really in need for a settable send and a
> settable
>>> receive, you
>>>>> can always use prepends and route that are both settable.
>>>>> see small attached abstraction.
>>>>
>>>> I think you are stuck for two reasons
>>>> 1) [r setable_send_receive] is global. I want the parent $0 in
> front of it
>>> so that
>>>> my abstraction symbols don't clash with other abstractions.
>>>
>>> i don't understand this point : just ignore the
> settable_send_receive stuff
>>> that is hidden inside ss and sr.
>>
>> What if some other abstraction somewhere uses that symbol? The
>> whole point of $0 is that you don't need to worry about this.
> the risk can be reduce using this symbol instead :
> This_symbol_is_use_for_the_ss_and_sr_object_and_should_not_be_use_elsewhere
>
> if you still think it's dangerous, then think of someone using 1000-foo in
> it's patch.
> $0-foo is not 100% safe either!!!
>
>
>>
>>> this 2 abstractions work exactly like a real settable send and receive,
> at least
>>> for the local / global send.
>>
>> No, they don't. They have an additional feature/bug of filtering lists
> that have a
>> symbol as the first element. "list foo bar" comes out "foo
> bar" at the other end.
> yes, my sentence was an answer to your 1st point : local / global send. not an
> answer to your 2nd point.
>
> this patchs was a prof of concept, not a final answer.
>
>>
>> Like I wrote, it's possible to hack around this problem. But
> that's much uglier
>> than, say, sending a symbol to an inlet.
>
> yes, i agree.
> having a settable receive is one of the 1000 things that can be improve to make
> user life easier.
> i just wanted to point that it's far from being a show stopper, since simple
> workaround can be find.
999 if you use pd-l2ork. :)
A roadblock isn't a showstopper. But if you have enough roadblocks it makes it
very difficult to get where you want to go.
-Jonathan
>
> cheers
>
> Cyrille
>
>
>>
>> -Jonathan
>>
>>> i.e. if you want a local only send/receive, just use $0-bla, like you
> would have
>>> done with "real" send / receive.
>>>
>>> that the route that filter content of different abstraction. the only
> problem is
>>> CPU overload, but that should really be minor.
>>>
>>>
>>>> 2) Your example filters messages in a way that s/r doesn't.
> It's
>>> possible to hack
>>>> around this using three extra objects.
>>> yes, right. but that is a minor problem. not a show stopper.
>>>
>>> cheers
>>> c
>>>
>>>> It is also possible to get the arguments of
>>>> an abstraction in Pd Vanilla. With the former, I'd rather
> send a
>>> single message to
>>>> an inlet and be done.
>>>>
>>>> -Jonathan
>>>>
>>>>>
>>>>> cheers
>>>>> c
>>>>>
>>>>
>>>
>>
>
More information about the Pd-list
mailing list