Hi all,
porres@gmail.com Alexandre has recently requested a new object/functionality similar to max's [if] on github: https://github.com/pure-data/pure-data/issues/663
So I was looking it for a while, and came up with a list of things that have to be modified/added in order to accommodate the new object, as discussed on github.
I guess the main question is that I feel like this is quite a big change to the expr family since no class has been added to it for the past 19/20 years, so I am just wondering whether my approach (adding a new class to the [expr], [expr~], [fexpr~] mix) is correct, and whether this functionality is something that we need.
I will probably put in a pull request soon if there is no objection...
Kind regards, TK
On 31/07/2019 09:31, Tsz Kiu Pang wrote:
Alexandre has recently requested a new object/functionality similar to max's [if] … I am just wondering whether my approach (adding a new class to the [expr], [expr~], [fexpr~] mix) is correct, and whether this functionality is something that we need. I will probably put in a pull request soon if there is no objection
Dear TK and Alexandre
I have no objection, but I do have a couple of naïve questions:
[a] In the message case, I am struggling to see the point, as all you need to do is control a [spigot] with the truth value of the test. Or you can assign the false condition a value unused in the true case (if there is any such) and feed the output to [route] or [select]. Or … well doubtless there are many — and likely better — ways to skin this cat. Is it just for convenience, then, or am I missing something?
[b] If a parallel audio case is envisaged, what would it do?
Best
m
Em qua, 31 de jul de 2019 às 08:46, matthew brandi mfbrandi@outlook.com escreveu:
On 31/07/2019 09:31, Tsz Kiu Pang wrote:
Alexandre has recently requested a new object/functionality similar to max's [if] … I am just wondering whether my approach (adding a new class to the [expr], [expr~], [fexpr~] mix) is correct, and whether this functionality is something that we need. I will probably put in a pull request soon if there is no objection
Dear TK and Alexandre
I have no objection, but I do have a couple of naïve questions:
[a] In the message case, I am struggling to see the point
yup, the point is convenience, and I'd say part of the convenience is that all the ground is already laid out. In fact, my firs suggestion was to add a new "ifthen" function to the expr family, but got an objection that closed the request https://github.com/pure-data/pure-data/issues/662
[b] If a parallel audio case is envisaged, what would it do?
there'd no [if~] object
On 31/07/2019 17:25, Alexandre Torres Porres wrote: yup, the point is convenience, and I'd say part of the convenience is that all the ground is already laid out.
Thanks for the clarification.
Best
m
-- matthew brandi
Both Shahrokh (who wrote expr, and whose office is 15 feet from mine) and I keep thinking about how to extend expr to add more control flow, which should include looping, conditionals, perhaps some sort of block structure, etc. The problem we always hit is that there's no way to figure out where to stop. And if you keep on not stopping, you end up inventing a programming language. There seems to be no "correct" way to do it.
cheers Miller
On Wed, Jul 31, 2019 at 04:50:09PM +0000, matthew brandi wrote:
On 31/07/2019 17:25, Alexandre Torres Porres wrote: yup, the point is convenience, and I'd say part of the convenience is that all the ground is already laid out.
Thanks for the clarification.
Best
m
-- matthew brandi
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Fri, 2 Aug 2019 at 07:53, Miller Puckette msp@ucsd.edu wrote:
Both Shahrokh (who wrote expr, and whose office is 15 feet from mine) and I keep thinking about how to extend expr to add more control flow, which should include looping, conditionals, perhaps some sort of block structure, etc. The problem we always hit is that there's no way to figure out where to stop. And if you keep on not stopping, you end up inventing a programming language. There seems to be no "correct" way to do it.
It seems though the proposed [if] object would be like a slight modification on the existing "if" operator. Instead of having "if" as an operator, I guess the proposal is to turn it into an object, because an expression has to always output a value (?), but if we are implementing "if", "else", "then" operators, an outlet does not have to necessarily output anything, which I guess is the main difference between the existing "if" operator and the proposed [if] object. In my ill-informed opinion, I think this is quite a big step away from inventing a programming language, but again, I am quite new to this community, so pardon me if this is not making sense.
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em ter, 6 de ago de 2019 às 01:30, Tsz Kiu Pang osamupang@gmail.com escreveu: I think this is quite a big step away from inventing a programming language
I do consider the [expr] object a great tool that opens a little door for us to work more like as in "C". Since it deals pretty well with variables, I love that I can call a variable, then update it, then use in the next expression and stuff.
It's not that it is a programming language on its own, but it's quite handy and stands out in that way under Pd.
In that sense, I have to confess and say I also wondered if if could be expanded to work with something as a for loop along with the expressions, that would be sweet and I can totally see how that would come to mind. But for that matter in particular, I never could really see how it'd go, and the situation is that it would open the discussion "Do we really need and want Pd to be more of a script language"? So I get it!
And for loop I just have an object called [else/loop] (pretty similar to [cyclone/uzi]) that handles it well, and is just more convenient than using [until], so it's kinda covered...
As for an [if] object, like the one in Max, I once thought seriously about including it in the "cyclone" library, cause I think it'd be awesome to have something like that. What stopped me is basically that I think I'm done adding objects to cyclone, I kinda let it go. And before thinking about getting it into the ELSE library, I really thought this could belong to vanilla, since the situation is that the expr family already settles the ground for it.
It seems though the proposed [if] object would be like a slight modification
on the existing "if" operator.
Exactly, so I'd basically have to use all the code from expr, edit it just a bit, so it'd be kinda silly...
Hence I opened the request, first as a only a new function to [expr], but then IOhannes pointed that.
an expression has to always output a value (?), but if we are implementing
"if", "else", "then" operators, an outlet does not have to necessarily output anything,
so yeah, maybe a new class creator with a different orientation is all we need.
I am quite new to this community, so pardon me
if this is not making sense.
Don't worry, it's all pretty cool around here :) you can propose anything, it doesn't hurt to ask, the worst it can happen is that after some discussion it doesn't really happen ;)
cheers
On Tue, 6 Aug 2019 at 15:43, Alexandre Torres Porres porres@gmail.com wrote:
Em ter, 6 de ago de 2019 às 01:30, Tsz Kiu Pang osamupang@gmail.com
escreveu:
an expression has to always output a value (?), but if we are implementing "if", "else", "then" operators, an outlet does not have to necessarily output anything,
so yeah, maybe a new class creator with a different orientation is all we need.
Not sure if this is related, but I was just looking at the class creator
of expr in the file x_vexp_if.c, and in the function expr_setup, there is a section commented as "expr initialization". I notice that apart from creating the class "expr", the class "exprproxy" also has to be created.
/* * expr initialization */ expr_class = class_new(gensym("expr"), (t_newmethod)expr_new, (t_method)expr_ff, sizeof(t_expr), 0, A_GIMME, 0); class_addlist(expr_class, expr_list); exprproxy_class = class_new(gensym("exprproxy"), 0, 0, sizeof(t_exprproxy), CLASS_PD, 0); class_addfloat(exprproxy_class, exprproxy_float); class_addmethod(expr_class,(t_method)expr_version, gensym("version"), 0);
These two classes seem to be created using the class_new function separately, and at the moment I can't seem to find the "glue" that connects exprproxy_class and expr together, it would be great if someone could please shed some light on this...
Cheers, TK
On 8/24/19 8:17 AM, Tsz Kiu Pang wrote:
at the moment I can't seem to find the "glue" that connects exprproxy_class and expr together, it would be great if someone could please shed some light on this...
[https://github.com/pure-data/pure-data/blob/master/src/x_vexp_if.c#L336]