pack vs pak
i recently found out that pak works actually different from pack/list, which turned my whole world view upside down.
when you feed a [pak 0 0 0 0] with a number at one of the inlets it spits out "list 0 7 0 0" which of course in this form can not be understood by the first inlet of another object such as pack or expr. to fix it, i am helping myself by inserting a [t l], which removes the "list" as exspected.
is that intended that pak works different than pack here, and if yes, what is the explanation for this?
-110
I can't replicate what you describe. This patch works exactly as I'd expect. Max 7.3.1, 64-bit, Mac OS 10.8.5.
yes i checked after posting; it happens up to 513 and seems to be fixed with version 6.
akward that. i think when i continue to use version 4 for another 15 years i will end up with a list of 100% buggy objects.
oh fun, in windows it works in 4.5, too. on mac PPC and intel it doesnt in v5 :)