[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