[PD-dev] a new object/functionality similar to max's [if]

Alexandre Torres Porres porres at gmail.com
Tue Aug 6 07:43:23 CEST 2019


>
> Em ter, 6 de ago de 2019 às 01:30, Tsz Kiu Pang <osamupang at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20190806/fef44112/attachment-0001.html>


More information about the Pd-dev mailing list