petterdass

does-this-patch-make-any-sense-if-so-what-does-it-do

if you say the first [pak] creates a list "x y" then the second [pak] 

the "2." in the [/ 2.] has no toher function than putting the object to 

> #N comlet route: Outputs if Input Matches 0;

> #N comlet route: Outputs if Input Matches 4;

> #N comlet route: Outputs if Input Matches 3;

> #N comlet route: Outputs if Input Matches 2;

> #N comlet route: Outputs if Input Matches 1;

> #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;

> #N comlet pak: float to be Element 1 in the list;

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 ;)

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
http://www.heartchamberorchestra.org


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?

> Came across something strange here, can anyone explain?

though it works with floats as well. so it seems to work with everythign 

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

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...

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...?

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
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...?


Quote: Bas van der Graaff wrote on Mon, 10 December 2007 02:42

----------------------------------------------------

> 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:

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?;

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.

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.

Quote: Peter Castine wrote on Wed, 12 December 2007 16:33
----------------------------------------------------
> 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 

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