## Does this patch make any sense? If so - what does it do?

Dec 08 2007 | 8:32 pm
Thanks alot!
max v2;

• Dec 10 2007 | 10:11 am
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 ;)
p
check this out:
petterdass wrote:
> Thanks alot!
>
>
>
> max v2;
> #N vpatcher 15 55 929 648;
> #P origin 8 -20;
> #N comlet route: Outputs if Input Matches 0;
> #P outlet 317 169 15 0;
> #N comlet route: Outputs if Input Matches 4;
> #P outlet 304 169 15 0;
> #N comlet route: Outputs if Input Matches 3;
> #P outlet 291 169 15 0;
> #N comlet route: Outputs if Input Matches 2;
> #P outlet 278 169 15 0;
> #N comlet route: Outputs if Input Matches 1;
> #P outlet 265 169 15 0;
> #N comlet route: Outputs if Input Matches 0;
> #P outlet 252 169 15 0;
> #N comlet route: Outputs if Input Matches 4;
> #P outlet 239 169 15 0;
> #N comlet route: Outputs if Input Matches 3;
> #P outlet 226 169 15 0;
> #N comlet route: Outputs if Input Matches 2;
> #P outlet 213 169 15 0;
> #N comlet route: Outputs if Input Matches 1;
> #P outlet 200 169 15 0;
> #N comlet route: Outputs if Input Matches 0;
> #P outlet 187 169 15 0;
> #N comlet route: Outputs if Input Matches 4;
> #P outlet 174 169 15 0;
> #N comlet route: Outputs if Input Matches 3;
> #P outlet 161 169 15 0;
> #N comlet route: Outputs if Input Matches 2;
> #P outlet 148 169 15 0;
> #N comlet route: Outputs if Input Matches 1;
> #P outlet 135 169 15 0;
> #N comlet route: Outputs if Input Matches 0;
> #P outlet 122 169 15 0;
> #P window setfont "Sans Serif" 9.;
> #P newex 57 57 49 9109513 pak 0. 0.;
> #P newex 57 117 50 9109513 pack 0 0.;
> #P newex 57 87 89 9109513 / 2.;
> #P newex 57 143 287 9109513 route 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20;
> #N comlet pak: float to be Element 2 in the list;
> #P inlet 96 37 15 0;
> #N comlet pak: float to be Element 1 in the list;
> #P inlet 57 37 15 0;
> #N comlet route: Outputs if Input Matches 4;
> #P outlet 109 169 15 0;
> #N comlet route: Outputs if Input Matches 3;
> #P outlet 96 169 15 0;
> #N comlet route: Outputs if Input Matches 2;
> #P outlet 83 169 15 0;
> #N comlet route: Outputs if Input Matches 1;
> #P outlet 70 169 15 0;
> #N comlet route: Outputs if Input Matches 0;
> #P outlet 57 169 15 0;
> #P connect 5 0 10 0;
> #P connect 10 0 8 0;
> #P connect 8 0 9 0;
> #P connect 9 0 7 0;
> #P connect 7 0 0 0;
> #P connect 7 1 1 0;
> #P connect 7 2 2 0;
> #P connect 6 0 10 1;
> #P connect 7 3 3 0;
> #P connect 10 0 9 1;
> #P connect 7 4 4 0;
> #P connect 7 5 11 0;
> #P connect 7 6 12 0;
> #P connect 7 7 13 0;
> #P connect 7 8 14 0;
> #P connect 7 9 15 0;
> #P connect 7 10 16 0;
> #P connect 7 11 17 0;
> #P connect 7 12 18 0;
> #P connect 7 13 19 0;
> #P connect 7 14 20 0;
> #P connect 7 15 21 0;
> #P connect 7 16 22 0;
> #P connect 7 17 23 0;
> #P connect 7 18 24 0;
> #P connect 7 19 25 0;
> #P connect 7 20 26 0;
> #P pop;
>
>
>
>
--
http://pure.test.at
• Dec 10 2007 | 10:42 am
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?
• Dec 10 2007 | 11:47 am
• Dec 10 2007 | 12:00 pm
Bas van der Graaff wrote:
> Came across something strange here, can anyone explain?
>
>
>
though it works with floats as well. so it seems to work with everythign
except symbols
p
--
http://pure.test.at
• Dec 10 2007 | 3:09 pm
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...
example:
-> 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
gate closes
-> 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...?
• Dec 11 2007 | 6:04 am
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:
• Dec 13 2007 | 12:33 am
It is not objects that "automatically spray".
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.
• Dec 13 2007 | 7:03 am
Quote: Peter Castine wrote on Wed, 12 December 2007 16:33
----------------------------------------------------
> It is not objects that "automatically spray".
Whoops, bad terminology. I meant to say "auto unpack"
> 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
Sort of, but that explanation makes me think the message boxes in this patch should all behave the same way:
Maybe there is a bug here, but this seems like a bad practice anyway. I'd always use an explicit unpack in these situations.