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@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
--
Patrice Colet
fr: 0632660357
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
