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__