Hi!
I have a question about Zexy (2.1) object urn. I think there is a bug in the second outlet. In the help patch this is writen:
"when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet"
But this is not true. Bang is emitted not on the last number from the pool (list) but on the first number of the next cycle! Hm. I'm using this object in my patch and it took me cca 2 hours to find why patch doesn't work:)
Zexy is one of my favorite externals. For me probably most useful. I would be glad if this could be solved.
Thanks
Bosko
Don't just search. Find. Check out the new MSN Search! http://search.msn.com/
Bosko Milakovic wrote:
Hi!
I have a question about Zexy (2.1) object urn. I think there is a bug in the second outlet. In the help patch this is writen:
"when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet"
But this is not true. Bang is emitted not on the last number from the pool (list) but on the first number of the next cycle! Hm. I'm using this object
you are right.
in my patch and it took me cca 2 hours to find why patch doesn't work:)
but why did your patch refuse to work because of this? it would be good to have an example that proves that the behaviour should really be fixed (probably i am just to tired to think of one...)
are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is)
mfga.dr. IOhannes
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
Bosko Milakovic wrote:
I have a question about Zexy (2.1) object urn. I think there is a bug in the second outlet. In the help patch this is writen:
"when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet"
But this is not true. Bang is emitted not on the last number from the pool (list) but on the first number of the next cycle! Hm. I'm using this object
you are right.
in my patch and it took me cca 2 hours to find why patch doesn't work:)
but why did your patch refuse to work because of this? it would be good to have an example that proves that the behaviour should really be fixed (probably i am just to tired to think of one...)
are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is)
There are two (maybe more) conflicting [urn] objects: zexy, Cyclone and maybe maxlib. In RTC-lib I solved the problem of different behaviour regarding the time, when the urn is refilled, by writing another one, but as a pure abstraction. I called it urne and it's attached as well as in CVS as part of RTC-lib.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi!
From: IOhannes m zmoelnig zmoelnig@iem.at To: Bosko Milakovic bmilakovic@hotmail.com CC: pd-list@iem.at Subject: Re: [PD] Zexy object urn bug? Date: Tue, 27 Mar 2007 15:37:32 +0200
Bosko Milakovic wrote:
Hi!
I have a question about Zexy (2.1) object urn. I think there is a bug in
the
second outlet. In the help patch this is writen:
"when all the numbers have been drawn from the pool, the system is reset (the numbers are put back) and a bang is emitted via the second outlet"
But this is not true. Bang is emitted not on the last number from the
pool
(list) but on the first number of the next cycle! Hm. I'm using this
object
you are right.
in my patch and it took me cca 2 hours to find why patch doesn't work:)
but why did your patch refuse to work because of this? it would be good to have an example that proves that the behaviour should really be fixed (probably i am just to tired to think of one...)
It's an important part of the patch where after urn generates n unique random numbers (n is always different) another abstraction expects bang to move forward and do some work... But it's important that bang comes after the last generated number from the pool, and not on the first of the new cycle. Then it's too late.
are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is)
I expected to be like second outlet from textfile object: on the end of sequence you get bang. That what I expected from urn because it was writen in help patch. Now I had to add counter to urn that counts every generated number and when it gets to n number, number is selected with [sel] which send bang.... It's not problem for me but I thought it would be good to have object like that.
Thanks
Bosko
FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Bosko Milakovic wrote:
Hi!
are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is)
I expected to be like second outlet from textfile object: on the end of sequence you get bang. That what I expected from urn because it was writen in help patch.
obviously, if it's described in the help-patch it has to behave like that (that is why i don't describe features in the help-patches ;-))
would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])?
e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again.
this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet)
it would be interesting to know whether there are objections from other users of this object.
mfa.dr IOhannes
On 3/27/07, IOhannes m zmoelnig zmoelnig@iem.at wrote:
would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])?
e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again.
this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet)
I think it would definitely be good for it to bang when it's done (not when it sends the first new number), but for me, any specific implementation would work that provides such a bang.
~David
Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
obviously, if it's described in the help-patch it has to behave like that (that is why i don't describe features in the help-patches ;-))
would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])?
e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again.
IMO it would be best and most flexible, if the urn would not automatically refill when it's empty. And actually that's the way, two of the three (I checked it: Cyclone, maxlib and zexy have one) [urn]s work and I based my urne.pd abstraction on that approach as well. The right "EOF" outlet always can be used to refill the urn, so no functionality would be missed, if needed.
this is somewhat weird, as banging the object 40 times will only give you 30 random numbers
Like in Lotto: Playing 60 of 45 will only give you 45 numbers as well, but at least you always win!
(but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet)
it would be interesting to know whether there are objections from other users of this object.
Which one? ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
From: IOhannes m zmoelnig zmoelnig@iem.at
would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])?
e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again.
this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet)
Hm. Is it possible that when it's done urn will just bang to second outlet without empty bang?
Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Bosko Milakovic wrote:
Hm. Is it possible that when it's done urn will just bang to second outlet without empty bang?
technically it is simple. the problem is rather from a "philosophical" point of view: i rather not have objects trigger outlets from left to right.
unless i have some simple and consistent idea how to deal with that, i won't change the current behaviour.
fmgasdr IOhannes
On Tue, 27 Mar 2007 20:14:17 +0200 IOhannes m zmoelnig zmoelnig@iem.at wrote:
Bosko Milakovic wrote:
Hi!
are there any built-in objects that behave like you are expecting [urn] to behave? (apart from outputting unique random numbers, that is)
I expected to be like second outlet from textfile object: on the end of sequence you get bang. That what I expected from urn because it was writen in help patch.
obviously, if it's described in the help-patch it has to behave like that (that is why i don't describe features in the help-patches ;-))
would be ok (for everybody, not just you) if the empty bang had to be triggered separately (just like in [textfile])?
e.g. [urn 3] would output 3 random numbers; when banged a 4th time, it would (only) output a bang at the right-hand side; when banging a 5th time it would output a random number again.
this is somewhat weird, as banging the object 40 times will only give you 30 random numbers (but for those who don't care about the wraparound but really want 40 numbers instead, they could just feedback the 2nd outlet to the left inlet)
it would be interesting to know whether there are objections from other users of this object.
I must say i rather like [urn] as it is. I agree that it's weird to have the bang inserted into the random number stream when it already has it's own specific outlet.
Andy
mfa.dr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
padawan12 wrote:
it would be interesting to know whether there are objections from other users of this object.
I must say i rather like [urn] as it is. I agree that it's weird to have the bang inserted into the random number stream when it already has it's own specific outlet.
well, it would still come out of the specific (right-hand) outlet. however, the left outlet (where the number come out) would remain silent when the wraparound occurs.
mf.arsd IOhannes
-
Bosko Milakovic -
David Powers -
Frank Barknecht -
IOhannes m zmoelnig -
padawan12