[PD] DIY GSoC: getting those projects done

[Mathieu Bouchard]

On Thu, 26 Mar 2009, Jonathan Wilkes wrote:
> --- On Wed, 3/25/09, Mathieu Bouchard <matju at artengine.ca> wrote:
>> I mean, what do you do with a language that has no builtin [demux] 
>> (that's called an if-else anywhere else)
> Does [expr~ if ( $f2 == 0, $v1, 0 ); etc.] fill that role?

When processing just pd signals, a real conditional execution is done by 
[switch~] or [block~] and can only be applied on full subpatches. The 
[expr~ if] does compute both clauses of the "if", and then discards one of 
the results. This means that if a clause whose result gets discarded would 
cause an error, it will. The only difference between that and just 
multiplying one of the results by 0, is when one of the clauses is 
"infinite" or "NaN", then multiplying it by 0 won't cancel it. And then, 
that if() can only happen inside of [expr~]'s world, and so has no direct 
impact on other objects.

But I was more thinking of the message-system. In that case, [spigot] is 
an if-statement in which execution is really conditional: a "block of 
code" being a connection from an outlet to a bunch of objects that do 
something when you send them a message, then [spigot] decides whether 
something happens or not, in a generic way. [select], [route] and [moses] 
are special-case if-statements.

The if-else statements require a pair of [spigot]s and a [==]. This could 
be put in an abstraction, a total of six objects, and named demux2.pd or 
spigot2.pd, but no, Pd bundles absolutely no abstractions, and though the 
code for this very common case is just a few lines away from [spigot], Pd 
is still without it.

> (If so, it certainly strengthens your following point.)
>> , in which hot-vs-cold is troublesome (else [expr] wouldn't be *so* 
>> attractive), etc.

No, this was about how [expr] can be a replacement for even a small 
network of objects. If you make an abstraction that does 
($f1-$f2)*($f5-$f4)/($f3-$f2)+$f4, with just [+] [-] [*] [/] for example, 
then if you change some things in the cold inlets, the changes might not 
propagate to the bottom. This means you have to add a [pack 0 0 0 0 0] of 
the whole thing and [unpack 0 0 0 0 0] to ensure every hot-inlet is 
retriggered in the proper order. Actually, in this pack/unpack dance, 
maybe you can skip the hot-inlet of the abstraction (?), but apart from 
that, you're pretty stuck using pack/unpack if you want life to be simple. 
Else you can weave a mess of [t b f] objects like a spider on caffeine. 
That's what I mean.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec