wow! didnt know that one can do this...
if you say the first [pak] creates a list "x y" then the second [pak]
gives "(x/y) x"
the "2." in the [/ 2.] has no toher function than putting the object to
calculate with float precision
i guess you know what the route does ;)
It's not obvious to me at all that inputting a list into the left input 'sprays' the list, even for very basic objects. I only found out a couple months ago that this can even be used for things like 'gate'. But things like these get messy real fast, they make your patch hard to read. And why would you need float input for a route in that example?
Came across something strange here, can anyone explain?
Jln, what you describe is expected behaviour as far as i can see, isn't it? The list input is processed from right to left, that's why it lags output. Of course this isn't a feature, but it could be used theoretically if you want to allow for one more input after current...
-> input 1 34
input 34 is blocked
then gate opens
-> input 1 34
input 34 is sent through
gate stays open
-> input 0 35
input 35 is sent through
-> input 0 35
input 35 is blocked
gate stays closed
And as pure says, only symbols don't seem to work correctly. Not that i would ever use anything like this in a patch, but i'm just wondering what could cause this. I'd expect a gate to not even look at the type of input, but apparently it does...?
Quote: Bas van der Graaff wrote on Mon, 10 December 2007 02:42
> Came across something strange here, can anyone explain?
> right inlet of 'gate' is not picky about input type , right? Why doesn't this work?;
This is just a guess, but maybe objects that automatically "spray" a list from the left inlet only do so for list elements that are of a type compatible with the left inlet? A gate's left inlet doesn't support symbol, so it just gets ignored. I don't think I would count on any of these behaviors in a "real" patch.
This is also pretty interesting and not what I expected:
If an object does not have an explicit list message and it is sent a list, then the Max engine splits the list over the available inlets rather than posting • error: foo: doesn't understand "list"'' to the Max window.
I think this only works for lists arriving at the left inlet. I'm pretty sure I had to write explicit list handlers to get lp.sigma & Co. to distribute lists arriving at arbitrary inlets.
Again, the key point is the behavior you've noticed only kicks in _when_the_object_does_not_have_an_explicit_list_method_.
You can see which methods are explicitly defined for an object by a ctrl-opt-Mouse Down on the object box.
This is actually documented in one of the early Tutorials, but the significance of the behavior is unlikely to be apparent to anyone in the early stages of learning Max.
I'm not sure why your second gate example is not working as expected.