hi,
just discovered a very small bug with cyclone's "coll" object. it isn't even a real bug since it doesn't do anything but reporting an error message. but as this can lead to unwanted confusion for the patcher (i.e. me) - here it is:
if a [send] object and a [coll] have the same name, "coll" seems to be getting all messages put into the [send] object as a message and thus reporting an error on the command line.
i'm using cyclone 0.1, 54th build and (still) PD 0.37.2
this small example patch reproduces the error:
#N canvas 669 602 345 216 10; #X obj 58 68 s test; #X obj 170 67 coll test; #C restore; #X floatatom 58 48 5 0 0 0 - - -; #X obj 60 115 r test; #X floatatom 61 139 5 0 0 0 - - -; #X connect 2 0 0 0; #X connect 3 0 4 0;
ciao
oliver
oliver wrote: ...
if a [send] object and a [coll] have the same name, "coll" seems to be getting all messages put into the [send] object as a message and thus reporting an error on the command line.
this is very unfortunate, but using a separate symbol table for colls would break compatibility, because Max does not allow to reuse coll names in sends and receives. The error message should state this explicitly, though...
k
On Sun, 23 Apr 2006, Krzysztof Czaja wrote:
oliver wrote:
if a [send] object and a [coll] have the same name, "coll" seems to be getting all messages put into the [send] object as a message and thus reporting an error on the command line.
this is very unfortunate, but using a separate symbol table for colls would break compatibility, because Max does not allow to reuse coll names in sends and receives.
I don't understand why this is very unfortunate, and what do you mean that Max doesn't allow it. By "reuse" you mean use that symbol for a different purpose? So the compatibility issue would be because people do send messages to a coll using [s] with the name, as is commonly done with [table]s? am I getting this right?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote: ...
this is very unfortunate, but using a separate symbol table for colls would break compatibility, because Max does not allow to reuse coll names in sends and receives.
I don't understand why this is very unfortunate, and what do you mean that Max doesn't allow it. By "reuse" you mean use that symbol for a different purpose? So the compatibility issue would be because people do send messages to a coll using [s] with the name, as is commonly done with [table]s? am I getting this right?
if there is a [coll x] created already, Max will create a dummy object instead of [s x] or [r x] (this is similar to a dashed-out Pd object of an unknown class). If an [s x] or [r x] was created first, [coll x] would be dummy. I consider it a bad design that neither should nor could be emulated in cyclone. Hence, there is just a warning.
Krzysztof
On Sat, 29 Apr 2006, Krzysztof Czaja wrote:
if there is a [coll x] created already, Max will create a dummy object instead of [s x] or [r x] (this is similar to a dashed-out Pd object of an unknown class). If an [s x] or [r x] was created first, [coll x] would be dummy. I consider it a bad design that neither should nor could be emulated in cyclone. Hence, there is just a warning.
Well, I'd rather not have a warning at all, and instead that everything that uses a user-specified receive-symbol deals with "s_thing" correctly. This is done by using pd_bind and pd_unbind, which automatically deals with dispatching to several receivers. With that system, you still just use s_thing as a receiver, but you must not assign (=) nor compare (==) because s_thing might refer to a [bindlist] if there is more than one object that wants to use that symbol.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote: ...
Well, I'd rather not have a warning at all, and instead that everything that uses a user-specified receive-symbol deals with "s_thing" correctly. This is done by using pd_bind and pd_unbind, which automatically deals with dispatching to several receivers. With that system, you still just
which is how coll does it, but it is not the issue here. Putting max-compatibility aside, look how [v x]s handle sharing of their value: what is bound to 'x' is an auxiliary 'vcommon' class, which has no methods declared. Whatever is sent to 'x', there will be an error message printed. Same story about coll.
Krzysztof