[PD] aAaA: any attributes and arguments in Pd vanilla (v. 0.1) Re: Feature Proposal

padovani zepadovani.lists at gmail.com
Mon May 29 18:30:21 CEST 2017


Found this thread (
https://lists.puredata.info/pipermail/pd-list/2016-08/115936.html) some
days ago... and then I have forked the IOhannes abstraction that Matt
Barber mentions to deal with any number of arguments and to implement the
attribute tag recognition.

This approach could be used to detect other kinds of "pseudo" types!

I hope it is usefull for other people!
http://git.nics.unicamp.br/nicspd/patchTools/AnyArgumentsAndAttributes

Cheers,
José

2016-08-18 13:08 GMT-03:00 Roman Haefeli <reduzent at gmail.com>:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170529/c6b07e5a/attachment-0001.html>


More information about the Pd-list mailing list