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