Frank,
I was working with some of the RTC stuff over the weekend and I had a question about the abstraction 'xrandom'. While I understand that you were probably basing this on the 'xrandom' from the Max version of this, I would think that as is, 'xrandom' is a little different from similar objects.
As this is based on the 'urne' abstraction, and it seems to follow the same premise as the 'textfile' and 'qlist' objects, I would think that 'xrandom' would do this as well.
Basically, the difference that I see is that each of these other objects ('urne', 'textfile', etc.), all produce an output on the left as long as there is more to output, and bangs on the right outlet after the list is done, and does NOT output anything on the right.
'xrandom', on the other hand, DOES produce an output on the LEFT at the same time it is outputting a bang on the right to indicate that the list of objects is complete. This seems a little cumbersome, as this output on the LEFT is actually the first element from the next iteration of the set. This gives a false indication as to where the list of numbers ends. On the first iteration through the list, it would send out one more item than is in the list, and each subsequent iteration is "shifted" by one element.
While I can see that this would not really be an issue if you are not using the 'end of list' bang on the right outlet, but if you are, it doesn't break the list at the real boundries.
To change this behaviour, I removed the 'bang' from the [clear, bang( message that gets sent at the end of the iteration.
So, is what I am describing better done using other means? Is 'xrandom' expected to be used as a "bang as much as you want" type of abstraction? Is this behaviour based on the RTC/Max version? Does any of this make sense?
Mike McG
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
I was working with some of the RTC stuff over the weekend and I had a question about the abstraction 'xrandom'. While I understand that you were probably basing this on the 'xrandom' from the Max version of this, I would think that as is, 'xrandom' is a little different from similar objects.
As this is based on the 'urne' abstraction, and it seems to follow the same premise as the 'textfile' and 'qlist' objects, I would think that 'xrandom' would do this as well.
Basically, the difference that I see is that each of these other objects ('urne', 'textfile', etc.), all produce an output on the left as long as there is more to output, and bangs on the right outlet after the list is done, and does NOT output anything on the right.
'xrandom', on the other hand, DOES produce an output on the LEFT at the same time it is outputting a bang on the right to indicate that the list of objects is complete.
This is true, however the bang on the right outlet is sent before the new number is sent to the left outlet (right-to-left ordering as in [trigger float bang]. I based [xrandom] on the RTC-Max object, where every bang will produce a number without any breaks in between.
So, is what I am describing better done using other means? Is 'xrandom' expected to be used as a "bang as much as you want" type of abstraction? Is this behaviour based on the RTC/Max version?
Yes, it's that kind of object in the Max version of RTC:
Outputs random numbers <int> that are never repeated unless all numbers have been generated (series-principle).
The right outlet's bang is more a convenience outlet, not like the one in [textfile].
If you don't what the new value directly after all number have been generated, you should probably use [urne] directly where you just send [clear( from the right outlet, but no bang automatically.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Thanks, Frank. I kind of figured that this was to mimic the Max version.
Mike McG
On 4/16/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Mike McGonagle hat gesagt: // Mike McGonagle wrote:
I was working with some of the RTC stuff over the weekend and I had a question about the abstraction 'xrandom'. While I understand that you were probably basing this on the 'xrandom' from the Max version of this, I would think that as is, 'xrandom' is a little different from similar objects.
As this is based on the 'urne' abstraction, and it seems to follow the same premise as the 'textfile' and 'qlist' objects, I would think that 'xrandom' would do this as well.
Basically, the difference that I see is that each of these other objects ('urne', 'textfile', etc.), all produce an output on the left as long as there is more to output, and bangs on the right outlet after the list is done, and does NOT output anything on the right.
'xrandom', on the other hand, DOES produce an output on the LEFT at the same time it is outputting a bang on the right to indicate that the list of objects is complete.
This is true, however the bang on the right outlet is sent before the new number is sent to the left outlet (right-to-left ordering as in [trigger float bang]. I based [xrandom] on the RTC-Max object, where every bang will produce a number without any breaks in between.
So, is what I am describing better done using other means? Is 'xrandom' expected to be used as a "bang as much as you want" type of abstraction? Is this behaviour based on the RTC/Max version?
Yes, it's that kind of object in the Max version of RTC:
Outputs random numbers <int> that are never repeated unless all numbers have been generated (series-principle).
The right outlet's bang is more a convenience outlet, not like the one in [textfile].
If you don't what the new value directly after all number have been generated, you should probably use [urne] directly where you just send [clear( from the right outlet, but no bang automatically.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Mike McGonagle