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
Hello Roman,
have you tried Thomas Grill's [py] object??
you can load scripts in it and create "externals" even for audio.
On Thu, Aug 18, 2016 at 5:08 PM, Roman Haefeli reduzent@gmail.com wrote:
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
Hi Roman,I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too. Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'? In other words, what would be the rule for flattening a list atom into a series of atoms?
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself. Anyhow, this is another parser change (in m_binbuf).
== 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).
What would $1 and $2 evaluate to in this case? What would [$freq( expand to?
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR. How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily-deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it 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.
Does [text] address some of this?
Any feedback welcome. Roman
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Jonathan,
On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
Hi Roman, I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
Thanks for the insight. That doesn't like realistic thing to do, then.
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too.
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
Oh, yes. Sorry for that.
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
I think it should be up to the user to decide whether to stay compact or expand. So, [$3 3( would give you the expanded version '97 98 99 3', while [ ( $3 ) 3 ( would output '( 97 98 99 ) 3'.
In other words, what would be the rule for flattening a list atom into a series of atoms?
You have to put something explicitly in between parentheses to stay compact.
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself.
I'm no proponent for spaces, but I assumed it would make the idea easier to realize (which is moot now) and would be more Pd-like.
Anyhow, this is another parser change (in m_binbuf).
== 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).
What would $1 and $2 evaluate to in this case?
In order to stay backwards compatible, I think they should have the same behavior like now:
$1 -> 'freq=440' $2 -> 'vol=1'
What would [$freq( expand to?
It would not expand to anything, it would just output '$freq'. I don't see why there should be any expectation that $-args in message boxes would expand to creation arguments. Named arguments really only make sense as creation arguments. I don't see how this could be useful for message boxes.
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR.
How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily- deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it see '(base address) freq'?
No. As I said above, to be really flexible, the user should make it explicit whether they want to expand or stay compact. So:
[oscformat $1 freq]
evaluates to:
[oscformat base address freq]
However, if we want the nesting to go one level deeper, we would create:
[myabsabs ( $1 voice1 )]
and therein:
[oscformat $1 freq]
which would evaluate to:
[oscformat base address voice1 freq]
This kind of nesting is currently not possible with [oscformat] and [oscparse]. That is the one single reason I have to stick with [packOSC] and [unpackOSC] (not that it's bad to stay with those, they work great. I do have a slight preference for internals, though).
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.
Does [text] address some of this?
I think it does to some degree, since you gain one additional dimension with the concept of lines. And it makes it easy to create something like dictionaries / key-value stores.
Roman
Reminder that IOhannes came up with a solution for variable args quite a while ago. See attached, which allows up to 10. It can be extended to whatever you think the maximum is, or if you really feel like it it's easy to dynamically patch.
On Fri, Aug 19, 2016 at 6:13 PM, Roman Haefeli reduzent@gmail.com wrote:
Hi Jonathan,
On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
Hi Roman, I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
Thanks for the insight. That doesn't like realistic thing to do, then.
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too.
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
Oh, yes. Sorry for that.
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
I think it should be up to the user to decide whether to stay compact or expand. So, [$3 3( would give you the expanded version '97 98 99 3', while [ ( $3 ) 3 ( would output '( 97 98 99 ) 3'.
In other words, what would be the rule for flattening a list atom into a series of atoms?
You have to put something explicitly in between parentheses to stay compact.
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself.
I'm no proponent for spaces, but I assumed it would make the idea easier to realize (which is moot now) and would be more Pd-like.
Anyhow, this is another parser change (in m_binbuf).
== 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).
What would $1 and $2 evaluate to in this case?
In order to stay backwards compatible, I think they should have the same behavior like now:
$1 -> 'freq=440' $2 -> 'vol=1'
What would [$freq( expand to?
It would not expand to anything, it would just output '$freq'. I don't see why there should be any expectation that $-args in message boxes would expand to creation arguments. Named arguments really only make sense as creation arguments. I don't see how this could be useful for message boxes.
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR.
How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily- deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it see '(base address) freq'?
No. As I said above, to be really flexible, the user should make it explicit whether they want to expand or stay compact. So:
[oscformat $1 freq]
evaluates to:
[oscformat base address freq]
However, if we want the nesting to go one level deeper, we would create:
[myabsabs ( $1 voice1 )]
and therein:
[oscformat $1 freq]
which would evaluate to:
[oscformat base address voice1 freq]
This kind of nesting is currently not possible with [oscformat] and [oscparse]. That is the one single reason I have to stick with [packOSC] and [unpackOSC] (not that it's bad to stay with those, they work great. I do have a slight preference for internals, though).
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.
Does [text] address some of this?
I think it does to some degree, since you gain one additional dimension with the concept of lines. And it makes it easy to create something like dictionaries / key-value stores.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
>On Friday, August 19, 2016 6:15 PM, Roman Haefeli <reduzent@gmail.com> wrote:
Hi Jonathan,
On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
Hi Roman, I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
Thanks for the insight. That doesn't like realistic thing to do, then.
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too.
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
Oh, yes. Sorry for that.
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
I think it should be up to the user to decide whether to stay compact or expand. So, [$3 3( would give you the expanded version '97 98 99 3', while [ ( $3 ) 3 ( would output '( 97 98 99 ) 3'.
Well, there's an additional issue here: you're speaking specifically about abstractions, but I'm speaking on the language level. If you only mean to have a way to group abstraction args, either Pd-l2ork or Pd Vanilla plus iemguts will give you a way to build your own abstraction to parse those arguments. In that case requiring the space between parentheses is indeed useful as it makes it much easier to parse the creation arguments from within Pd.
In other words, what would be the rule for flattening a list atom into a series of atoms?
You have to put something explicitly in between parentheses to stay compact.
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself.
I'm no proponent for spaces, but I assumed it would make the idea easier to realize (which is moot now) and would be more Pd-like.
It would if you're just looking for a way to build an abstraction library to do this for abstraction arguments. But if you want it to be a language feature (as it becomes in Gridflow) that's no longer an issue.
Anyhow, this is another parser change (in m_binbuf).
== NAMED ARGUMENTS ==
[myabs freq=440 vol=1]
inside the abstraction:
$freq would evaluate to '440' $vol would evalute to '1'
Parsing that in a Pd patch would be a pain. You basically have toreimplement the C code that Pd uses to convert a string into atoms (well, slightly modified, but same idea). Then you also need to reimplement the C function that converts an array of ASCII values to a floating point number.
If a certain argument is not specified as creation argument, it
would
evaluate to '0' (similar to existing behavior).
What would $1 and $2 evaluate to in this case?
In order to stay backwards compatible, I think they should have the same behavior like now:
$1 -> 'freq=440' $2 -> 'vol=1'
What would [$freq( expand to?
It would not expand to anything, it would just output '$freq'. I don't see why there should be any expectation that $-args in message boxes would expand to creation arguments. Named arguments really only make sense as creation arguments. I don't see how this could be useful for message boxes.
If this were implemented on the language level, you'd basically get message box expansion of A_DOLLVAR for free because msg and obj both share the same code for converting their content into Pd atoms.
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR.
How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily- deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it see '(base address) freq'?
No. As I said above, to be really flexible, the user should make it explicit whether they want to expand or stay compact. So:
[oscformat $1 freq]
evaluates to:
[oscformat base address freq]
However, if we want the nesting to go one level deeper, we would create:
[myabsabs ( $1 voice1 )]
and therein:
[oscformat $1 freq]
which would evaluate to:
[oscformat base address voice1 freq]
This kind of nesting is currently not possible with [oscformat] and [oscparse]. That is the one single reason I have to stick with [packOSC] and [unpackOSC] (not that it's bad to stay with those, they work great. I do have a slight preference for internals, though).
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.
That's starting to sound like more of a language feature than a feature merely to make abstractions more flexible. If it generalizes for abstractions, it would probably be useful for Pd messages, too.
Does [text] address some of this?
I think it does to some degree, since you gain one additional dimension with the concept of lines. And it makes it easy to create something like dictionaries / key-value stores.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Maybe instead of changing the existing parsing it would be easier to create a second class of variables which can be defined from within the patch.
So
[30 20(
|
[#define vol]
defines #vol as "30 20", and then "#vol" is replaced with "30 20" wherever it is encountered.
Most of Roman's suggestions, and many more things, could then be achieved by iterating and routing the creation arguments (obtained either by $@ or iemguts/canvasargs]).
I don't know how easy it would be to have # variables undated in real time, rather than only once when the patch loads. [expr] seems to achieve this by integrating [v] values.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Jonathan Wilkes via Pd-list pd-list@lists.iem.at Sent: 20 August 2016 02:15 To: Roman Haefeli; Pd list Subject: Re: [PD] Feature Proposal
On Friday, August 19, 2016 6:15 PM, Roman Haefeli reduzent@gmail.com wrote:
Hi Jonathan,
On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
Hi Roman, I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
Thanks for the insight. That doesn't like realistic thing to do, then.
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too.
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
== GROUPING IN MESSAGES == [1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
Oh, yes. Sorry for that.
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
I think it should be up to the user to decide whether to stay compact or expand. So, [$3 3( would give you the expanded version '97 98 99 3', while [ ( $3 ) 3 ( would output '( 97 98 99 ) 3'.
Well, there's an additional issue here: you're speaking specifically about abstractions, but I'm speaking on the language level.
If you only mean to have a way to group abstraction args, either Pd-l2ork or Pd Vanilla plus iemguts will give you a way to build your own abstraction to parse those arguments. In that case requiring the space between parentheses is indeed useful as it makes it much easier to parse the creation arguments from within Pd.
In other words, what would be the rule for flattening a list atom into a series of atoms?
You have to put something explicitly in between parentheses to stay compact.
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself.
I'm no proponent for spaces, but I assumed it would make the idea easier to realize (which is moot now) and would be more Pd-like.
It would if you're just looking for a way to build an abstraction library to do this for abstraction arguments. But if you want it to be a language feature (as it becomes in Gridflow) that's no longer an issue.
Anyhow, this is another parser change (in m_binbuf).
== NAMED ARGUMENTS ==
[myabs freq=440 vol=1]
inside the abstraction:
$freq would evaluate to '440' $vol would evalute to '1'
Parsing that in a Pd patch would be a pain. You basically have to reimplement the C code that Pd uses to convert a string into atoms (well, slightly modified, but same idea). Then you also need to reimplement the C function that converts an array of ASCII values to a floating point number.
If a certain argument is not specified as creation argument, it
would
evaluate to '0' (similar to existing behavior).
What would $1 and $2 evaluate to in this case?
In order to stay backwards compatible, I think they should have the same behavior like now:
$1 -> 'freq=440' $2 -> 'vol=1'
What would [$freq( expand to?
It would not expand to anything, it would just output '$freq'. I don't see why there should be any expectation that $-args in message boxes would expand to creation arguments. Named arguments really only make sense as creation arguments. I don't see how this could be useful for message boxes.
If this were implemented on the language level, you'd basically get message box expansion of A_DOLLVAR for free because msg and obj both share the same code for converting their content into Pd atoms.
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR.
How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily- deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it see '(base address) freq'?
No. As I said above, to be really flexible, the user should make it explicit whether they want to expand or stay compact. So:
[oscformat $1 freq]
evaluates to:
[oscformat base address freq]
However, if we want the nesting to go one level deeper, we would create:
[myabsabs ( $1 voice1 )]
and therein:
[oscformat $1 freq]
which would evaluate to:
[oscformat base address voice1 freq]
This kind of nesting is currently not possible with [oscformat] and [oscparse]. That is the one single reason I have to stick with [packOSC] and [unpackOSC] (not that it's bad to stay with those, they work great. I do have a slight preference for internals, though).
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.
That's starting to sound like more of a language feature than a feature merely to make abstractions more flexible. If it generalizes for abstractions, it would probably be useful for Pd messages, too.
Does [text] address some of this?
I think it does to some degree, since you gain one additional dimension with the concept of lines. And it makes it easy to create something like dictionaries / key-value stores.
Roman
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Monday, August 22, 2016 9:14 AM, Liam Goodacre liamg_uw@hotmail.com wrote:
Maybe instead of changing the existing parsing it would be easier to create a second class of variables which can be defined from within the patch.
So
[30 20( | [#define vol]
I've got a prototype for something like this up and running in with data structures. There's a [field] object
that lets you get and set the values for a scalar. Unlike [set], the [field] object is used on a canvas that
lives _inside_ a scalar. So you don't need pointers to get and set the values.
In practice, it's mostly useful as a way to "parameterize" drawing instructions. For example, I can have a
[field rotation] object and associate the "rotation" variable with an affine transform of a shape (or group
of shapes). Then any time I send a new value to [field rotation], the scalar drawing will automatically be
redrawn to reflect the new rotation value.
defines #vol as "30 20", and then "#vol" is replaced with "30 20" wherever it is encountered.
It's not going to be particularly expressive unless you can refer to it inside [expr]. Then you're back to
adding features to the parser.
Most of Roman's suggestions, and many more things, could then be achieved by iterating and routing the creation arguments (obtained either by $@ or iemguts/canvasargs]).
I don't know how easy it would be to have # variables undated in real time, rather than only once when the patch loads. [expr] seems to achieve this by integrating [v] values.
Not sure what you mean here. Are you still talking about abstraction arguments?
-Jonathan
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Jonathan Wilkes via Pd-list pd-list@lists.iem.at Sent: 20 August 2016 02:15 To: Roman Haefeli; Pd list Subject: Re: [PD] Feature Proposal
On Friday, August 19, 2016 6:15 PM, Roman Haefeli reduzent@gmail.com wrote:
Hi Jonathan,
On Don, 2016-08-18 at 19:28 +0000, Jonathan Wilkes wrote:
Hi Roman, I'll try to address the question of how difficult each of these is to implement. [...]
== 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'
This would require changes to t_atom because there is no "list" atom type. That's a fairly involved change, especially given that plenty of internal and external classes do "lazy" type checking (if it isn't a float it must be a symbol, etc.).
Thanks for the insight. That doesn't like realistic thing to do, then.
== 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)
This requires changes to the parser, which requires extensive testing and bug fixing, too.
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
== GROUPING IN MESSAGES ==
[1 2 ( 97 98 99 ) 4 5( | [$2 (
would give '97 98 99'
Did you mean [$3(?
Oh, yes. Sorry for that.
If so, what would [$3 3( give you? '97 98 99 3' or '(97 98 99) 3'?
I think it should be up to the user to decide whether to stay compact or expand. So, [$3 3( would give you the expanded version '97 98 99 3', while [ ( $3 ) 3 ( would output '( 97 98 99 ) 3'.
Well, there's an additional issue here: you're speaking specifically about
abstractions, but I'm speaking on the language level.
If you only mean to have a way to group abstraction args, either Pd-l2ork
or Pd Vanilla plus iemguts will give you a way to build your own abstraction
to parse those arguments. In that case requiring the space between
parentheses is indeed useful as it makes it much easier to parse the creation
arguments from within Pd.
In other words, what would be the rule for flattening a list atom into a series of atoms?
You have to put something explicitly in between parentheses to stay compact.
Regarding parentheses-- Gridflow adds a syntax like that for handling nested message data. I don't like the idea in general, but I like Gridflow's implementation better than your example because it doesn't require space in between the parentheses and the data itself.
I'm no proponent for spaces, but I assumed it would make the idea easier to realize (which is moot now) and would be more Pd-like.
It would if you're just looking for a way to build an abstraction library to
do this for abstraction arguments. But if you want it to be a language
feature (as it becomes in Gridflow) that's no longer an issue.
Anyhow, this is another parser change (in m_binbuf).
== NAMED ARGUMENTS ==
[myabs freq=440 vol=1]
inside the abstraction:
$freq would evaluate to '440' $vol would evalute to '1'
Parsing that in a Pd patch would be a pain. You basically have to reimplement the C code that Pd uses to convert a string into atoms (well,
slightly modified, but same idea). Then you also need to reimplement the
C function that converts an array of ASCII values to a floating point number.
If a certain argument is not specified as creation argument, it
would
evaluate to '0' (similar to existing behavior).
What would $1 and $2 evaluate to in this case?
In order to stay backwards compatible, I think they should have the same behavior like now:
$1 -> 'freq=440' $2 -> 'vol=1'
What would [$freq( expand to?
It would not expand to anything, it would just output '$freq'. I don't see why there should be any expectation that $-args in message boxes would expand to creation arguments. Named arguments really only make sense as creation arguments. I don't see how this could be useful for
message boxes.
If this were implemented on the language level, you'd basically get message
box expansion of A_DOLLVAR for free because msg and obj both share
the same code for converting their content into Pd atoms.
I'm not actually sure what changes this would require. At the very least you'd need a new case in the parser for handling dollar signs that don't match the A_DOLLAR or A_DOLLSYM. It seems like you'd need a new atom type, too. Let's call it A_DOLLVAR.
How does A_DOLLVAR interact with A_DOLLSYM and A_DOLLAR? Can it be concatenated with them? (The case for "$@" is that it doesn't concatenate.) But you also have to account for A_DOLLVAR expanding to arbitrarily- deeply-nested lists because it's going to work inside message boxes, too.
== 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'.
Wouldn't it see '(base address) freq'?
No. As I said above, to be really flexible, the user should make it explicit whether they want to expand or stay compact. So:
[oscformat $1 freq]
evaluates to:
[oscformat base address freq]
However, if we want the nesting to go one level deeper, we would create:
[myabsabs ( $1 voice1 )]
and therein:
[oscformat $1 freq]
which would evaluate to:
[oscformat base address voice1 freq]
This kind of nesting is currently not possible with [oscformat] and [oscparse]. That is the one single reason I have to stick with [packOSC] and [unpackOSC] (not that it's bad to stay with those, they work great. I do have a slight preference for internals, though).
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.
That's starting to sound like more of a language feature than a feature
merely to make abstractions more flexible. If it generalizes for
abstractions, it would probably be useful for Pd messages, too.
Does [text] address some of this?
I think it does to some degree, since you gain one additional dimension with the concept of lines. And it makes it easy to create something like dictionaries / key-value stores.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 20/08/16 06:13, Roman Haefeli wrote:
Pd-l2ork uses "$@" to expand to all the arguments, which you can then shoot to a [list length] to get the equivalent of "$#". It's based off a patch submitted originally submitted to Pd Vanilla by IOhannes which is probably still hanging around on the sourceforge patch tracker.
$@ alone would be already quite a cool feature. I hope it'll get accepted once in Pd-vanilla, too.
I also hope for this.
https://www.youtube.com/watch?v=sZrgxHvNNUc
Cheers,
Chris.
Hi,I dug as much as I could into past posts on this topic, like these https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html but I yet have to find the answer to: How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the two communicate together nicely? So far I have only managed (on Mac OS X) to - start the regular Pd- start a process with -guiport 5400 which connects to the existing GUI- kill the DSP process that came with the GUI, the GUI still runs- at this point, patching in the GUI is very slow and blocks are very small and the text is outside the box- if I try to create [dac~] or [adc~] I get a "couldn't create" There must be a better (and working) way of doing this.Once I get it to work on one computer, I believe it should just work when using two computers, right? Thanks,Giulio
I am re-upping this as I did not get any response.
From: Giulio Moro <giuliomoro@yahoo.it>
To: Pd list pd-list@lists.iem.at Sent: Monday, 22 August 2016, 12:33 Subject: Once again, -guiport -nogui
Hi,I dug as much as I could into past posts on this topic, like these https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html but I yet have to find the answer to: How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the two communicate together nicely? So far I have only managed (on Mac OS X) to - start the regular Pd- start a process with -guiport 5400 which connects to the existing GUI- kill the DSP process that came with the GUI, the GUI still runs- at this point, patching in the GUI is very slow and blocks are very small and the text is outside the box- if I try to create [dac~] or [adc~] I get a "couldn't create" There must be a better (and working) way of doing this.Once I get it to work on one computer, I believe it should just work when using two computers, right? Thanks,Giulio
I think this was once possible to do but apparently it isn't possible any longer. On the other hand, if you'e trying to connect a pd process on one computer with a GUI process on another one, that should be doable using something like pd -guicmd "ssh machine-name wish /home/msp/pd/tcl//pd-gui.tcl 5400"
To get this to work you'll need a connection to an ssh agent with permission to login to the other machine (which should work as long as you can type "ssh machine-name" on a shell and not have to type the password). And the machine you're connecting to mustn't firewall off port 5400, tcp protocol.
One remaining stupid problem: if you hit "open" or "save as" the dialog will be run from the GUI machine so you'll see all the wrong files on offer unless you've carefully mirrored the filesystem someho.
cheers Miller
On Sun, Sep 04, 2016 at 01:01:38PM +0000, Giulio Moro via Pd-list wrote:
I am re-upping this as I did not get any response.
From: Giulio Moro <giuliomoro@yahoo.it>To: Pd list pd-list@lists.iem.at Sent: Monday, 22 August 2016, 12:33 Subject: Once again, -guiport -nogui
Hi,I dug as much as I could into past posts on this topic, like these https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html but I yet have to find the answer to: How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the two communicate together nicely? So far I have only managed (on Mac OS X) to - start the regular Pd- start a process with -guiport 5400 which connects to the existing GUI- kill the DSP process that came with the GUI, the GUI still runs- at this point, patching in the GUI is very slow and blocks are very small and the text is outside the box- if I try to create [dac~] or [adc~] I get a "couldn't create" There must be a better (and working) way of doing this.Once I get it to work on one computer, I believe it should just work when using two computers, right? Thanks,Giulio
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
thanks,this works for me. Giulio
From: Miller Puckette <msp@ucsd.edu>
To: Giulio Moro giuliomoro@yahoo.it Cc: Pd list pd-list@lists.iem.at Sent: Sunday, 4 September 2016, 16:21 Subject: Re: [PD] Once again, -guiport -nogui
I think this was once possible to do but apparently it isn't possible any longer. On the other hand, if you'e trying to connect a pd process on one computer with a GUI process on another one, that should be doable using something like pd -guicmd "ssh machine-name wish /home/msp/pd/tcl//pd-gui.tcl 5400"
To get this to work you'll need a connection to an ssh agent with permission to login to the other machine (which should work as long as you can type "ssh machine-name" on a shell and not have to type the password). And the machine you're connecting to mustn't firewall off port 5400, tcp protocol.
One remaining stupid problem: if you hit "open" or "save as" the dialog will be run from the GUI machine so you'll see all the wrong files on offer unless you've carefully mirrored the filesystem someho.
cheers Miller
On Sun, Sep 04, 2016 at 01:01:38PM +0000, Giulio Moro via Pd-list wrote:
I am re-upping this as I did not get any response. From: Giulio Moro giuliomoro@yahoo.it To: Pd list pd-list@lists.iem.at Sent: Monday, 22 August 2016, 12:33 Subject: Once again, -guiport -nogui Hi,I dug as much as I could into past posts on this topic, like these https://lists.puredata.info/pipermail/pd-list/2007-08/052611.html and this https://lists.puredata.info/pipermail/pd-list/2008-05/061978.html but I yet have to find the answer to: How do Ia) start the GUI with no DSP ?b) start the DSP with no GUI ?c) have the two communicate together nicely? So far I have only managed (on Mac OS X) to - start the regular Pd- start a process with -guiport 5400 which connects to the existing GUI- kill the DSP process that came with the GUI, the GUI still runs- at this point, patching in the GUI is very slow and blocks are very small and the text is outside the box- if I try to create [dac~] or [adc~] I get a "couldn't create" There must be a better (and working) way of doing this.Once I get it to work on one computer, I believe it should just work when using two computers, right? Thanks,Giulio
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
On Mon, 2016-08-22 at 21:24 +0200, IOhannes m zmölnig wrote:
On 08/18/2016 06:08 PM, Roman Haefeli wrote:
[myabs ( one two 3 ) 4 five]
omg, i always thought about using {curly braces} for such a feature - this way it wouldn't break any existing patches that happen to use parentheses for whatever reasons.
By thinking of Pd's lists as equivalent to Python's tuples I was somehow forced to think parentheses, but yeah, curly braces wouldn't break anything for sure.
Roman
By thinking of Pd's lists as equivalent to Python's tuples I was
somehow forced to think parentheses, but yeah, curly braces wouldn't break anything for sure. They would break the inter-process message parser. Also, the curly-bracket filter would need to be removed from the key eventhandler in g_editor.c. Plus any other places in m_binbuf.c or other places where curlies are filtered. -Jonathan
On 08/22/2016 10:27 PM, Jonathan Wilkes via Pd-list wrote:
break anything for sure. Also, the curly-bracket filter would need to be removed from the key eventhandler in g_editor.c. Plus any other places in m_binbuf.c or other places where curlies are filtered.
exactly, that's the idea. because they are forbidden now, they can be used for new features.
They would break the inter-process message parser.
how so? it's not like every tcl/tk application prevents the use of {}. (there's obviously a reason why Pd does forbid it; however, i doubt that the unerlying problem cannot be solved)
gfadrs IOhannes
On Monday, August 22, 2016 7:14 PM, IOhannes m zmölnig
zmoelnig@iem.at wrote: On 08/22/2016 10:27 PM, Jonathan Wilkes via Pd-list wrote:
break anything for sure. Also, the curly-bracket filter
would need to be removed from the key eventhandler in g_editor.c.
Plus>> any other places in m_binbuf.c or other places where curlies are filtered.
exactly, that's the idea. because they are forbidden now, they can be used for new features.
Yes.
They would break the inter-process message parser.
how so?
line 15 of pd_connect.tcl (in pd-0.46-7): # TODO figure out how to escape { } properly
it's not like every tcl/tk application prevents the use of {}.
(there's obviously a reason why Pd does forbid it; however, i doubt
that > the unerlying problem cannot be solved)
I obviously agree. The motto of Purr Data could probably be,
"I doubt underlying problems cannot be solved."
-Jonathan
gfadrs IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Chris McCormick -
Giulio Moro -
IOhannes m zmölnig -
Jonathan Wilkes -
José Rafael Subía Valdez -
Liam Goodacre -
Matt Barber -
Miller Puckette -
patrice colet -
Roman Haefeli