[PD] Feature Proposal

[patrice colet]

Hello,

  All those ideas are really neat, that would require many tricky 
changes in sources, adding a new type like A_BRACE, allowing $bla,

almost everything in m_binbuf.c would have be recoded, it looks like an 
hard job, but sounds very good at a patching point of view.

Le 18/08/2016 à 18:08, Roman Haefeli a écrit :
> Hey all
>
> After having worked with Python a bit, I'm very intrigued by the many
> useful data containers it provides (tuples, lists, sets,
> dictionaries).
>
> At the same time, I am sometimes troubled by the inflexibility of
> arguments in Pd. Writing abstractions that deal with a variable number
> of arguments is hard. Even retrieving the number of specified arguments
> inside the abstraction is hard. Also, if you have fixed argument part
> and a variable part, you need to make sure that the variable part is
> put at the end of the argument list, otherwise there is no way to
> distinguish them.
>
> I'm just thinking loud here and do not have any idea, how hard it would
> be to implement in Pd. I'm just trying to raise a discussion about the
> topic. Here some (probably not very thought-through) ideas:
>
>
> == GROUPING IN ABSTRACTION ARGUMENTS ==
> Allow grouping of atoms, so that you can pass a whole list to one
> single argument like this:
>
> [myabs ( one two 3 ) 4 five]
>
> inside the abstraction:
>
> $1 would evaluate to 'list one two 3'
> $2 would evaluate to '4'
> $3 would evaluate to '5'
>
> == GETTING NUMBER OF ARGS ==
> With the same example:
>
> [myabs ( one two 3 ) 4 five]
>
> inside the abstraction:
>
> $# would evaluate to '3' (number of arguments given)
>
> == GROUPING IN MESSAGES ==
> [1 2 ( 97 98 99 ) 4 5(
> |
> [$2 (
>
>
> would give '97 98 99'
>
> == NAMED ARGUMENTS ==
>
> [myabs freq=440 vol=1]
>
> inside the abstraction:
>
> $freq would evaluate to '440'
> $vol would evalute to '1'
>
> If a certain argument is not specified as creation argument, it would
> evaluate to '0' (similar to existing behavior).
>
>
> == USE CASE ==
> [oscformat] takes an arbitrary number of arguments to create an OSC
> address. While I find this the cleaner and more pd-like way than
>   /one/two/three, this has big draw-back. You currently cannot pass the
> OSC address (containing an arbitrary number of address fields) to an
> abstraction when using [oscformat]. The number of arguments must known
> beforehand when using this format. With [packOSC] from the osc library,
> you can do:
>
> [myabs /base/address]
>
> and therein:
>
> [packOSC $1/freq]
>
> which evaluates to /base/address/freq.
>
> By allowing grouping of arguments, one could achieve the same without
> resorting to long symbols (which has other drawbacks). In the main
> patch you could create:
>
> [myabs ( base address )]
>
> and therein:
>
> [oscformat $1 freq]
>
> and [oscformat] would actually see 'base address freq'.
>
> There are many other cool things you could do. It would allow to create
> lists of lists, which can be easily split again later (which is
> currently very hard to do and involves a lot of serializing and using
> delimiters or prepended number-of-elements). Generally, it would allow
> to create much more flexible abstractions.
>
> Any feedback welcome.
>
> Roman
>
>
>
>
>    
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

-- 
Patrice Colet
fr: 0632660357