Hi IOhannes,
Thanks for your reply. I don't understand your answer... I mean I do know that one has to use triggers to connect to multiple inlets, but I don't see where I did something wrong in my patch. Do you mean that the prints attached to two outlets should be attached to triggers ? Even then I don't understand how this could cause the entire sequence of counter values to be upside down. Have your tried it, first manually, then with the [sel 0] attached to the counter ? Do you get the same behaviour as what I described ?
Cheers,
Pierre.
2015-06-03 9:30 GMT+02:00 IOhannes m zmoelnig zmoelnig@iem.at:
On 2015-06-02 23:10, Pierre Massat wrote:
I am probably very tired and I must be missing something obvious. But
right
now this looks like aliens have hacked into Pd and are playing with my nerves.
afaict¹, you are violating the first rule of patching:
*never* do a fan-out without a trigger. *always* use a trigger if you want to connect a single outlet with multiple inlets. *always*.
fgmasdr IOhannes
¹ i was pretty sure that this would be the answer before i looked at your patch; it usually is; but this also means that i'm very biased and might have missed something else.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/03/2015 02:34 PM, Pierre Massat wrote:
Thanks for your reply. I don't understand your answer... I mean I do know that one has to use triggers to connect to multiple inlets, but I don't see where I did something wrong in my patch. Do you mean that the prints attached to two outlets should be attached to triggers ? Even then I don't understand how this could cause the entire sequence of counter values to be upside down.
well, i do think that you should use [trigger] even for [print]s, but you are right that this doesn't make a difference.
however, your counter has a fan-out to three(!) inlets, and only one of them is a [print].
use trigger.
gfmadsr IOhannes
Hi IOhannes,
I modified my patch accordingly (see attachement), but this doesn't make any difference. It is still behaving as described in my first message. If I remember correctly Miller doesn't use a trigger after a counter in the help files and examples (using a [f ] and a [+1] side by side). The same outlet (from f) is connected to the inlet of the [+ 1] and to the object receiving the counter's value. I agree with you that the use of a trigger would be the proper way of doing it, but if it were plain wrong not to use one I suppose that Miller wouldn't do it this way (for instance in the control example, 05.counter.pd).
I understand the use of triggers very well I think, and I use them practically everywhere. But here the problem seems beyond my understanding of execution order.
Have you (has anyone) tried my patch ? I have tried in 0.46.6 on both Linux and Win 7 and I get the same baffling results.
Pierre.
2015-06-03 14:57 GMT+02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 06/03/2015 02:34 PM, Pierre Massat wrote:
Thanks for your reply. I don't understand your answer... I mean I do know that one has to use triggers to connect to multiple inlets, but I don't
see
where I did something wrong in my patch. Do you mean that the prints attached to two outlets should be attached to triggers ? Even then I
don't
understand how this could cause the entire sequence of counter values to
be
upside down.
well, i do think that you should use [trigger] even for [print]s, but you are right that this doesn't make a difference.
however, your counter has a fan-out to three(!) inlets, and only one of them is a [print].
use trigger.
gfmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 06/03/2015 03:52 PM, Pierre Massat wrote:
Hi IOhannes,
I modified my patch accordingly (see attachement), but this doesn't make any difference. It is still behaving as described in my first message. If I remember correctly Miller doesn't use a trigger after a counter in the
this doesn't mean much.
my point was that you were sending data to the counter from both branches of the fan-out (once the ordinary count-down; then the reset). which is usually the cause for much confusion (and probably something not found in miller's help files).
anyhow.
Have you (has anyone) tried my patch ? I have tried in 0.46.6 on both Linux and Win 7 and I get the same baffling results.
i did, but and i noticed that the counter was counting backward or not, depending on the (missing) [trigger].
i though that was your problem. obviously not.
i now think that your problem is, that you are indeed missing a [trigger] for the [print output] object¹.
if [print output] get's connected after the [== 47], then entire loop will go on the stack, and [print output] will only produce output when unwinding the stack: which is in the reverse order.
-> noweirdo-1.pd
in general it is better to use iterative structures rather than recursive structures. for one thing, they don't get you into weird stack unwinding (since you don't use the stack excessively). for another thing, Pd's stack depth is pretty limited (400 or so), so a recursive version of your patch only works for short texts.
-> noweirdo-2.pd
gsamdr IOhannes
¹ ha! i told you: *always* use [trigger] :-)
-
IOhannes m zmölnig -
Pierre Massat