We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-)
Cheers!
On 08/27/2013 12:56 PM, IOhannes m zmölnig wrote:
On 08/27/13 18:20, Ivica Ico Bukvic wrote:
to share a small but hopefully sweet teaser screenshot with everyone :-)
while it does look pretty, i hope you are not going to start teaching people to use fan-out rather than [trigger].
Fanout(1) = the order in which child chains are computed does not matter and doesn't need to be explicit Trigger(1) = the order in which child chains are computed does matter and is explicit Trigger(2) = the order in which child chains are computed doesn't matter but for aesthetic reasons is made explicit
Fanout(2) = the order in which child chains are computed does matter and is ambiguous.
When reading a patch, one may confuse Trigger(2) for Trigger(1), but that's no big deal because ordering is explicit either way.
When reading a patch, one may confuse Fanout(2) for Fanout(1), and that could cause a run time error.
Therefore, the user should never use Fanout(2).
In the png the chain stops at the fanned out number boxes, so the ordering cannot matter.
Therefore, the png must be an example of Fanout(1).
As such, the png cannot be an example of teaching people to use fanout instead of trigger _unless_ you mean Trigger(2) should _always_ be preferred to Fanout(1).
If Trigger(2) is always preferred to Fanout(1), then there is no way to visually signify when ordering doesn't matter.
Therefore, in cases where crossed wires or other ambiguities are not an issue, Fanout(1) is preferable to Trigger(2).
Conclusion: teach Fanout(1) and Trigger(2) for situations where ordering doesn't matter, and Trigger(1) for situations where it does. The end.
-Jonathan
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 28/08/13 04:34, Jonathan Wilkes wrote:
On 08/27/2013 12:56 PM, IOhannes m zmölnig wrote:
On 08/27/13 18:20, Ivica Ico Bukvic wrote:
to share a small but hopefully sweet teaser screenshot with everyone :-)
while it does look pretty, i hope you are not going to start teaching people to use fan-out rather than [trigger].
Therefore, in cases where crossed wires or other ambiguities are not an issue, Fanout(1) is preferable to Trigger(2).
Conclusion: teach Fanout(1) and Trigger(2) for situations where ordering doesn't matter, and Trigger(1) for situations where it does. The end.
also, in a potential future with some kinds of parallelism in pd, taking Fanout (rather than Trigger) as an explicit statement that the branches are not dependent on order of execution is quite interesting, and very consistent with the ideal that Fanout order is undefined. But that is a dream-space a long way off for pd as it is now.
Simon
On 28/08/13 11:36, Simon Wise wrote:
also, in a potential future with some kinds of parallelism in pd, taking Fanout (rather than Trigger) as an explicit statement that the branches are not dependent on order of execution is quite interesting, and very consistent with the ideal that Fanout order is undefined. But that is a dream-space a long way off for pd as it is now.
Of course interpreting Fanout as allowing asynchronous execution of the branches is somewhat stronger than taking Fanout to mean what it currently does, which is that the branches can be completed in any arbitrary sequence.
Simon
On 08/27/13 22:34, Jonathan Wilkes wrote:
Conclusion: teach Fanout(1) and Trigger(2) for situations where ordering doesn't matter, and Trigger(1) for situations where it does. The end.
only that many Fanout(2) problems originate in a Fanout(1) design, where at some point the patch was extended and branches where execution order did not matter suddenly are merged again in a way where execution order *does* matter.
i think that most patchers have heard about [trigger] and it's merits, it just doesn't occur to them that in their specific patch execution order does matter. i dare say that most of the buggy patches posted here (and elsewhere) are buggy exactly because a Fanout(1) mutated into a Fanout(2).
as for simon's asynchronous semantics of fan-out, it's probably better to start using it only *after* it has been implemented.
conclusion: always make execution order explicit, even if you currently don't care about it. the end.
fgmadrs IOhannes
On 08/27/2013 12:20 PM, Ivica Ico Bukvic wrote:
We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-)
Very cool. Is this using tkpath?
-Jonathan
Cheers!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 08/27/2013 04:09 PM, Jonathan Wilkes wrote:
On 08/27/2013 12:20 PM, Ivica Ico Bukvic wrote:
We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-)
Very cool. Is this using tkpath?
Yep :-)
It's been quite an overhaul, however, far from a simple drop-in replacement to get this but I think it's been totally worth it.
Best wishes,
Ico
-Jonathan
Cheers!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmölnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
Simon Wise