Route bug (am I out of my mind?)


    Nov 09 2006 | 6:45 am
    Hi.
    Id like to do something simple, like [route list bang], or even
    [route list] ::
    I expect print name to print the contents of the list, yet, it does
    not - print nada does. What gives? If I fiddle with the route
    helpfile and pass more/less/different arguments to route, it seems
    like sometimes it will do it.
    BUG REPORT:
    Max 4.6.2
    OS X 10.4.8
    Bug:
    Try above patch. Should print to name - prints to nada.
    Open route helpfile. Press "2 wash cat" - this prints out of '2' Re-
    instantiate route with simply route list
    now it prints out of '1' ? Why not 2, like the above patch? Route
    seems to behave differently depending on what arguments you give it?
    Expected behaviour: route behaves and prints to 'name' in included
    patch?
    Am I going insane? Is there a logical reason to this I am missing
    late this evening?
    Thanks,
    v a d e //
    www.vade.info
    abstrakt.vade.info

    • Nov 09 2006 | 6:59 am
      Hi Vade,
      Check out the Max reference PDF. route doesn't match lists, it only
      matches symbols, floats and ints. So, your patch will only print out
      name if you have a list "list something 1 else".
      wes
    • Nov 09 2006 | 7:09 am
      >
      > Am I going insane? Is there a logical reason to this I am missing
      > late this evening?
      >
      > Thanks,
      >
      Vade , i had the same issue, but because i am not an advanced programmer i did not feel ridiculing myself ...
      the only thing that worked for me was using [atoi]&[itoa] for this kind of stuff... its sure odd, but maybe i am missing something too , in which i case i just ridiculed myself ;)
    • Nov 09 2006 | 7:11 am
      actually route does match lists,
      but you have to use a number in the beginning.
      jl
    • Nov 09 2006 | 7:14 am
      So, your patch will only print out
      > name if you have a list "list something 1 else".
      >
      but why does it work with a list like "1 something else" ?
      obviuosly i a missing something ...
    • Nov 09 2006 | 7:21 am
      Wow, I didn't know list worked, at least it's not in the PDF. As for
      the discrepency, it's because "something 1 else" is a message while a
      series of numbers is a list.
      wes
    • Nov 09 2006 | 7:43 am
      Ok, but that still doesnt explain the discrepancy of the behaviour,
      because it WILL match 'something 2 else' or whatever as a list if you
      follow my instructions.
      And, I feel silly asking this, because, but, according to iter :::;
      I always thought of that as a message and a list? perhaps Ive had a
      fundamental misunderstanding, but it seems to me that Max reinforces
      the concept that the above messagebox, contains a LIST, ora series of
      messages as a list.
      Am I making sense? Thanks.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Nov 09 2006 | 8:01 am
      I think the deal this is a bit ambigues because there are some special
      cases in max. There are a number of methods max objects use to handle
      input. These can be specific to floats, ints, or messages such as
      "offset" or "list" etc., or anything at all or a list of numbers.
      Here's a bit of a breakdown I hope it's correct.
      List:
      anything that starts with a number and is followed by at least 1 more item
      Message:
      anything starting with text of some sort followed by 1 or more items
      Iter treats messages and lists the same. Route does not. Anyone see
      anything wrong with the above? Hopefully this makes thing clear.
      wes
    • Nov 09 2006 | 8:27 am
      i as Vade thought that anything composed by more then one item , number, float, symbol, message separated by a space or a comma was a list .
      i guess i need some clarification , what about this then ?
    • Nov 09 2006 | 8:39 am
      Basically, it comes down to, in the end, how the object handles this
      stuff. Trigger is like iter in how it handles lists and messages. I
      don't think there's a hard line between the two anyway. What you're
      getting at with your patch is a difference between list as a term
      describing data in a patcher and list as a term describing how C
      functions react to incoming data, so I think there are 2 difference
      concepts here that bleed into each other.
      wes
    • Nov 09 2006 | 8:54 am
      right, you can only route lists beginning with float
      or int - not with bang or symbol. i agree its confusing.
    • Nov 09 2006 | 8:57 am
      Quote: (karrrlo) wrote on Thu, 09 November 2006 01:27
      ----------------------------------------------------
      > i as Vade thought that anything composed by more then one item , number, float, symbol, message separated by a space or a comma was a list .
      > i guess i need some clarification , what about this then ?
      a comma seperates 2 messages (or lists) from each other.
      (unless the whole thing is a symbol!)
      -110
    • Nov 09 2006 | 9:42 am
      To help clear things up some more, try the following patch and JS. JS
      binds directly to the C functions alot of max objects use to handle
      floats, ints, and lists, so you can use msg_float(), msg_int(), and
      list() to prove things to yourself. Notice the difference between the
      two "lists".
      wes
      function msg_float(val)
      {
      post("float: " + val + "n");
      }
      function msg_int(val)
      {
      post("int: " + val + "n");
      }
      function list(val)
      {
      var args = arrayfromargs(arguments);
      post("list: " + args + "n");
      }
    • Nov 09 2006 | 10:12 am
      Hi,
      My interpretation of that is : what's going thru a connection is just
      a message. When you send the integer "2" max send a message "int"
      with argument 2 so the object which receive the message knows what
      method it have to run do deal with the value specified.
      So now... what's the length of a "bang" ? (I'm just kidding... bang
      is interpreted by the zl len object to retrigger the operation, and
      not to get the length of a bang).
      ej
    • Nov 09 2006 | 12:33 pm
      On Nov 8, 2006, at 11:21 PM, Wesley Smith wrote:
      > Wow, I didn't know list worked, at least it's not in the PDF. As for
      > the discrepency, it's because "something 1 else" is a message while a
      > series of numbers is a list.
      >
      > wes
      on Mac hold down 'option + ctrl' then click on an object...this will
      show you data types and commands for an object -- incredibly useful!
      hope this helps
      :)
    • Nov 09 2006 | 2:10 pm
      That made me laugh this morning.
      Thanks for the responses. These are the sort of issues that get me a
      little annoyed with Max. I feel like every object should qualify the
      type of message symbol, message float int or list in the same way -
      across the board. I understand there is a need for backwards
      compatibility, but Max is a programming environment first - these
      types of ambiguities make life difficult. I cant tell you how many
      patches Ive seen, made, or have seen workshop patrons/teachers make
      that use the message first format as a 'list'.
      Its funny how almost metaphysical the whole thing gets :)
      Anyway, glad to know Im not the one crazy - Max is :)
      Thanks Wes (and everyone)
      (P.S. - I still think route has a bug, I should not be able to fool
      it into thinking 'something 2 else' is a list, ever, if it doesnt
      want to do it when [route list] wont output it from the leftmost
      outlet).
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 9, 2006, at 7:33 AM, Kim Cascone wrote:
      >
      > on Mac hold down 'option + ctrl' then click on an object...this
      > will show you data types and commands for an object -- incredibly
      > useful!
      > hope this helps
    • Nov 09 2006 | 2:46 pm
      On 9 nov. 06, at 15:10, vade wrote:
      > (P.S. - I still think route has a bug, I should not be able to fool
      > it into thinking 'something 2 else' is a list, ever, if it doesnt
      > want to do it when [route list] wont output it from the leftmost
      > outlet).
      Think "int", "float", "list" as reserved words like any other
      programming language.
      Best,
      ej
    • Nov 09 2006 | 4:24 pm
      On 9-Nov-2006, at 9:27, karl-otto von oertzen wrote:
      > i as Vade thought that anything composed by more then one item ,
      > number, float, symbol, message separated by a space or a comma was
      > a list .
      > i guess i need some clarification , what about this then ?
      Max 101 time.
      A list is a sequence of ints, floats, and symbols BEGINNING WITH A
      NUMBER.
      This is in the tutorials you all dutifully read, right?
      To wit:
      1 something else 3.14
      is a list with four arguments: '1' (an integer, which is a kind of
      number), 'something' (a symbol), 'else' (another symbol), and
      '3.14' (a float).
      something 1 else 3.14
      is the message 'something' (which, last time I looked, was not a
      number but a symbol) followed by three arguments, '1', 'else', and
      '3.14' (data types as above).
      You can force a message box to generate a list in which the first
      element is a symbol by using the symbol 'list'.
      list something 1 else 3.14
      which is a list of four arguments: 'something', '1', 'else',
      '3.14' (data types still as above). However, many objects, in an
      attempt to be helpful (?), will convert this into a 'something'
      message with three arguments (as in the second example above).
      It would be helpful if someone who is surprised by the above would
      take the time to look up the chapter and verse in the tutorials where
      the fact is documented that lists must commence with a number. Share
      with us and we will all be wiser.
      Footnote: I used to find it a little annoying that lists can't start
      with a symbol, but on further consideration it's actually very
      sensible. The Max engine has no way of knowing whether somewhere,
      somehow, some day, there might be an object responding to the
      'something' message. None of the standard objects do, but that
      doesn't mean anything. In fact (and coming back to vade's original
      sanity insecurity), you could have a 'route something baz squiggle mr-
      mxyzptlk' object that *requires* the message 'something 1 else 3.14'
      be parsed as a 'something' message with given parameters rather than
      a list.
      Ta.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Nov 09 2006 | 4:52 pm
      ... and i recommend to use the [printit] print object,
      it helps you a lot learning or refreshing how messages
      work behind the frontend.
      -110
    • Nov 09 2006 | 6:53 pm
      thanks Peter , Roman , Wes, Emmanuel , i got the "message".
      time for me to review a couple things indeed, and correct the misconceptions i had ;)
      The fact that Rumsfeld resigned and that i learned a bit more about lists made my day.
      voila
    • Nov 09 2006 | 6:58 pm
      ...and thanks Vade for bringing this up, this intrigued since a while too....
    • Nov 09 2006 | 8:11 pm
      It seems - still - no one is hearing me.
      The issue of what is a message versus a list is all fine and well -
      *the fact is however, that route will behave 2 different ways*
      I can get route, on my system, as per my bug report, to treat
      "something 1 is not a list" as a list.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Nov 09 2006 | 9:03 pm
      Sorry if it didn't come through, but I tried to follow your steps and
      your patch and didn't see this behavior. Can you post a patch with 2
      sections demonstating this dual behavior?
      thanks,
      wes
      On 11/9/06, vade wrote:
      > It seems - still - no one is hearing me.
      >
      > The issue of what is a message versus a list is all fine and well - *the
      > fact is however, that route will behave 2 different ways*
      >
      > I can get route, on my system, as per my bug report, to treat "something 1
      > is not a list" as a list.
      >
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      >
      > On Nov 9, 2006, at 11:24 AM, Peter Castine wrote:
      >
      > On 9-Nov-2006, at 9:27, karl-otto von oertzen wrote:
      >
      >
      > i as Vade thought that anything composed by more then one item , number,
      > float, symbol, message separated by a space or a comma was a list .
      > i guess i need some clarification , what about this then ?
      >
      > Max 101 time.
      >
      > A list is a sequence of ints, floats, and symbols BEGINNING WITH A NUMBER.
      >
      > This is in the tutorials you all dutifully read, right?
      >
      > To wit:
      >
      > 1 something else 3.14
      >
      > is a list with four arguments: '1' (an integer, which is a kind of number),
      > 'something' (a symbol), 'else' (another symbol), and '3.14' (a float).
      >
      > something 1 else 3.14
      >
      > is the message 'something' (which, last time I looked, was not a number but
      > a symbol) followed by three arguments, '1', 'else', and '3.14' (data types
      > as above).
      >
      > You can force a message box to generate a list in which the first element is
      > a symbol by using the symbol 'list'.
      >
      > list something 1 else 3.14
      >
      > which is a list of four arguments: 'something', '1', 'else', '3.14' (data
      > types still as above). However, many objects, in an attempt to be helpful
      > (?), will convert this into a 'something' message with three arguments (as
      > in the second example above).
      >
      > It would be helpful if someone who is surprised by the above would take the
      > time to look up the chapter and verse in the tutorials where the fact is
      > documented that lists must commence with a number. Share with us and we will
      > all be wiser.
      >
      > Footnote: I used to find it a little annoying that lists can't start with a
      > symbol, but on further consideration it's actually very sensible. The Max
      > engine has no way of knowing whether somewhere, somehow, some day, there
      > might be an object responding to the 'something' message. None of the
      > standard objects do, but that doesn't mean anything. In fact (and coming
      > back to vade's original sanity insecurity), you could have a 'route
      > something baz squiggle mr-mxyzptlk' object that *requires* the message
      > 'something 1 else 3.14' be parsed as a 'something' message with given
      > parameters rather than a list.
      >
      > Ta.
      >
      > --------------� � http://www.bek.no/~pcastine/Litter/� �
      > -------------
      > Peter Castine � � � � � � +--> Litter Power & Litter Bundle for Jitter
      > �� � � � � � � � � � � � � � � Universal Binaries on the way
      > iCE:� Sequencing,� Recording &
      > � � � Interface� Building� for � � � � � � � � � |home� � | chez nous|
      > � � � Max/MSP � Extremely cool � � � � � � � � � |bei uns |� i nostri|
      > � � � http://www.dspaudio.com/ � � � � � � � � � http://www.castine.de
      >
      >
      >
      >
      >
      >
    • Nov 09 2006 | 9:34 pm
      On 9-Nov-2006, at 21:11, vade wrote:
      > It seems - still - no one is hearing me.
      No, we're hearing you.
      Let's return to your original message.
      > Try above patch. Should print to name - prints to nada.
      No, in the patch (not quoted but it's in the archive) the message
      'something 1 list' is not a list but a 'something' message with the
      two arguments '1' and 'list' (as explained in my previous message).
      Since the input is not a list, it goes out the rightmost outlet of
      [route list] and from thence to the [print nada] object.
      > Open route helpfile. Press "2 wash cat" - this prints out of '2' Re-
      > instantiate route with simply route list
      > now it prints out of '1' ? Why not 2, like the above patch? Route
      > seems to behave differently depending on what arguments you give it?
      '2 wash cat' *is* a list because the first element is a number. As I
      explained in my previous message. So route sends it out the first
      outlet, which is matching the 'list' message.
      > Expected behaviour: route behaves and prints to 'name' in included
      > patch?
      >
      > Am I going insane? Is there a logical reason to this I am missing
      > late this evening?
      Q1: your expectations are based on a (common) misconception.
      Q2: You'll have to answer that one yourself;-
      Q3: see Q1
      As for iter, its behavior is unconventional in that it treats
      arbitrary messages as if they were lists. Yes, it is "inconsistent"
      in that it treats a 'this' message with a bunch of arguments ('is',
      'a', 'set', 'of', etc.) as if it were a list. There are a couple of
      objects that treat arbitrary messages as if they were lists
      (scramble, alea, ...).
      But in these cases, if iter were to maintain the strict distinction
      between lists and arbitrary messages, what would it do with arbitrary
      messages? Route, on the other hand, can be instantiated as [route
      list wash something racoon sugar] because someone wants to
      distinguish between the different kinds of message.
      Are objects in Max inconsistent? Of course they are, sometimes! But
      Ralph Waldo Emerson knew that almost two centuries ago.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Nov 10 2006 | 4:53 am
    • Nov 10 2006 | 2:23 pm
      It's certainly not obvious, and I'd go so far as to say that it's
      pointless and confusing.
      Why should "messages" and "lists" be different? Isn't a message
      merely a type of list? Why would max need yet another basic datatype
      when a message can clearly be counted and operated upon as if it were
      a list? Now, a symbol is different, which also begs the question why
      symbols and messages are not related, then? Message seems like the
      orphan of some long-defunct logic that may have been useful for Max
      1.0 but it totally irrelevant now, unless I'm missing something obvious.
    • Nov 10 2006 | 6:22 pm
      On 11/10/06, evan.raskob [lists] wrote:
      > It's certainly not obvious, and I'd go so far as to say that it's
      > pointless and confusing.
      >
      > Why should "messages" and "lists" be different? Isn't a message
      > merely a type of list?
      If you want messages to be lists, how does a max object distinguish
      the list "something 1 else" versus the list "something 1 else". If an
      object could potentially have a "something" message or attribute how
      would it respond to a list that begins with "something"? In fact
      there is no distinction if you let messages be lists, so objects won't
      be able to respond to such things and then we only have max objects
      that respond to floats, ints, or lists, no messages or attributes.
      That would really suck.
      wes
    • Nov 10 2006 | 7:50 pm
      why does an object have to respond to a message? why can't it just
      treat it is a form of list and parse it out? Isn't it going to have
      to do that anyway, on some level?
      i think i'm getting the idea from your post that the distinction is
      helpful on the back-end (externals) coding side, but as a max user,
      it's just inherently confusing. Attributes are special because they
      start with the "@" sign - if "messages" started with a special
      character or word (instead of just a standard number) then I would
      have some conceptual way of separating them from lists... but to say
      "just add a number to the front of a message to make it a list" is
      very inelegant and confusing, and the fact that i've been using max/
      jitter for 5 years without ever internalizing this is a testament to
      how obscure it really is.
      No offense to anyone, like I said, I think I can understand how this
      is different from a low-level programming perspective, but that's not
      where the usefulness of Max comes in, for the most part.
      cheers
      evan
    • Nov 10 2006 | 8:22 pm
      ++
      not only is it obscure, other objects, such as iter, trigger, etc, re-
      enforce the concept that [this is a list] is in fact a list, and not
      a message. It should at least be consistent.
      I have not been able to reproduce the route bug, which is odd. ill
      take a hammer to it once I get a spare moment (spare moment.. free
      time.. what are those things again?)
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Nov 10 2006 | 9:39 pm
      Quote: vade wrote on Thu, 09 November 2006 13:11
      ----------------------------------------------------
      > It seems - still - no one is hearing me.
      >
      > The issue of what is a message versus a list is all fine and well -
      > *the fact is however, that route will behave 2 different ways*
      >
      > I can get route, on my system, as per my bug report, to treat
      > "something 1 is not a list" as a list.
      okay, again, slowly.
      1.
      "something 1 is not a list"
      is in fact:
      "list something 1 is not a list"
      2.
      so if you see
      "something 1 is not a list"
      and you send it to [zl], [zl] will get
      "list something 1 is not a list"
      and knows how to use it.
      3.
      now, [route] is all but an intelligent kid.
      it does not understand
      "something 1 is not a list"
      because it is used to get symbols, bangs, or numbers.
      it will require a list starting with a number, or
      with the symbol "list" in err ... written form - say
      like typed into a messagebox.
      (list something 1 is not a list)
      try this:
      "something 1 is not a list"
      [prepend list]
      [route something]
      yes ist weird i know.
      -110
    • Nov 10 2006 | 9:57 pm
      vade, eventually i am telling you bullshit, sorry.
      max v2;
    • Nov 10 2006 | 9:59 pm
      On 11/10/06, evan.raskob [lists] wrote:
      > why does an object have to respond to a message? why can't it just
      > treat it is a form of list and parse it out?
      Effectively this *is* what it's doing. I was hoping you would answer
      this way. So, "something 1 else" gets *parsed* as a message because
      *something* defines an action or state that the objects responds to.
      In the case of route, it responds to *every* possible message. Thus
      "something 1 else" gets parsed as a message something followed by 1
      and else. If it responded as a list proper, you would never be able
      to to route out specific types of messages from each other which is
      the entire point of the object. So, the scheme you're suggesting
      would completely negate route's functionality and render it a no-op
      for distinguishing anything but ints, floats, and your concept of a
      list as a series of anything as opposed to the concept of a list as a
      series of anything starting with a number. Do you see where your
      logic fails here? I'm not trying to be rude or anything, I'm just
      trying to be more straightforward and spell it out a bit more.
      best,
      wes
    • Nov 10 2006 | 10:01 pm
      On 10 nov. 06, at 22:39, Roman Thilenius wrote:
      > okay, again, slowly.
      Sorry to slow you down again but...
      > 1.
      > "something 1 is not a list"
      > is in fact:
      > "list something 1 is not a list"
      euh... no. It's the message "something" with arguments "1 is not a
      liste" (writtien in french to be sure...)
      > 2.
      > so if you see
      > "something 1 is not a list"
      >
      > and you send it to [zl], [zl] will get
      > "list something 1 is not a list"
      > and knows how to use it.
      [zl] knows how to interpret the "something" message with the
      arguments because it have a "anything" method (ctrl+alt+click), which
      accept any message (including list by the way... but that's a step
      backward :-)
      > 3.
      > now, [route] is all but an intelligent kid.
      > it does not understand
      > "something 1 is not a list"
      > because it is used to get symbols, bangs, or numbers.
      >
      > it will require a list starting with a number, or
      > with the symbol "list" in err ... written form - say
      > like typed into a messagebox.
      > (list something 1 is not a list)
      >
      >
      > try this:
      > "something 1 is not a list"
      > [prepend list]
      > [route something]
      what's the problem with [route something] ? it does work for me.
      Best,
      ej
    • Nov 10 2006 | 10:46 pm
      > euh... no. It's the message "something" with arguments "1 is not a
      > liste"
      yes i noticed i was wrong. its just that - for example -
      [zl] or [printit] are understanding it as a list.
      > > try this:
      > > "something 1 is not a list"
      > > [prepend list]
      > > [route something]
      >
      > what's the problem with [route something] ? it does work for me.
      vade wanted to keep the "something" in the output.
      route would cut it off.(okay sure that happens with
      numbers too ... but somehow that is how i always use
      route for lists :) - i prepend number 7 to a certain
      type of list to be able to route it later.)
    • Nov 12 2006 | 7:06 pm
      On 10-Nov-2006, at 21:22, vade wrote:
      > It should at least be consistent.
      A foolish consistency is the hobgoblin of little minds.
      Like I said, Ralph Waldo Emerson had Max' inconsistencies nailed down
      two centuries ago.
      Having myself cursed Max' distinction between lists and messages for
      the first year or three of working with the program, after 17 years I
      have come to recognize that the decision was puredead brilliant. No,
      make that puredead fucking brilliant. I went into one of the reasons
      in my previous message on this thread. Having complained bitterly
      that people weren't listening to you, Vade, I would hazard to suggest
      that someone else here has a little difficulty listening.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Nov 12 2006 | 7:08 pm
      On 10-Nov-2006, at 20:50, evan.raskob [lists] wrote:
      > why does an object have to respond to a message? why can't it just
      > treat it is a form of list and parse it out?
      Efficiency.
      [Please cf the .sig from my previous post on this thread if you need it]
    • Nov 12 2006 | 7:47 pm
      ........
      I still hold my ground - go to any classroom that is teaching Max and
      ask people (including the professor), if
      1 something else
      and
      something 2 else
      are lists, and I bet you will be surprised by the results. Whatever
      the cause, and barring any forsight - it certainly is confusing and
      inconsistent. Why not have everything be a message, where list is a
      keyword? list 1 something else, list something 1 else would both be
      lists. typecasting your variables is not a bad idea regardless, why
      not do it in Max. You can do it with symbols. Why not with messages
      and lists? It would serve to disambiguate datatypes, and lead to
      better programming habits, just like using trigger to disambiguate
      timing issues and cleaning up patches.
      You can be happy with Max as it stands. Id love it to grow and make
      more sense, become cleaner, easier to use and smaller and
      lightweight. Remove the cruft - regardless of the backend. I really
      dont care what makes sense and doesnt C wise - I care about what
      makes sense and makes my life easier in Max land.
      thanks for "listening"
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 12, 2006, at 2:06 PM, Peter Castine wrote:
      >
      > On 10-Nov-2006, at 21:22, vade wrote:
      >
      >> It should at least be consistent.
      >
      > A foolish consistency is the hobgoblin of little minds.
      >
      > Like I said, Ralph Waldo Emerson had Max' inconsistencies nailed
      > down two centuries ago.
      >
      > Having myself cursed Max' distinction between lists and messages
      > for the first year or three of working with the program, after 17
      > years I have come to recognize that the decision was puredead
      > brilliant. No, make that puredead fucking brilliant. I went into
      > one of the reasons in my previous message on this thread. Having
      > complained bitterly that people weren't listening to you, Vade, I
      > would hazard to suggest that someone else here has a little
      > difficulty listening.
      >
      >
      >
      >
      > -------------- http://www.bek.no/~pcastine/Litter/ -------------
      > Peter Castine +--> Litter Power & Litter Bundle for Jitter
      > Universal Binaries on the way
      > iCE: Sequencing, Recording &
      > Interface Building for |home | chez nous|
      > Max/MSP Extremely cool |bei uns | i nostri|
      > http://www.dspaudio.com/ http://www.castine.de
      >
      >
    • Nov 12 2006 | 8:01 pm
      > I still hold my ground - go to any classroom that is teaching Max and ask
      > people (including the professor), if
      >
      > 1 something else
      >
      > and
      >
      > something 2 else
      > are lists,
      Just because a professor says it doesn't mean it's gospel because
      clearly the above statement is false. I still haven't seen any patch
      that proves your statement.
      wes
    • Nov 12 2006 | 8:12 pm
      My point is that, I was wrong, but other Max objects re-enforce the
      belief that they are. For example iter and trigger:
      And my point was also that the majority of the classroom (if not all)
      would be wrong as well.
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 12, 2006, at 3:01 PM, Wesley Smith wrote:
      >> I still hold my ground - go to any classroom that is teaching Max
      >> and ask
      >> people (including the professor), if
      >>
      >> 1 something else
      >>
      >> and
      >>
      >> something 2 else
      >> are lists,
      >
      > Just because a professor says it doesn't mean it's gospel because
      > clearly the above statement is false. I still haven't seen any patch
      > that proves your statement.
      >
      > wes
    • Nov 12 2006 | 8:13 pm
      And BTW, if you want to think of lists and messages as 1 thing try
      thinking of everything as a message with list as a subclass of
      messages and thus a special case where the group of values starts with
      a number.
      wes
      On 11/12/06, Wesley Smith wrote:
      > > I still hold my ground - go to any classroom that is teaching Max and ask
      > > people (including the professor), if
      > >
      > > 1 something else
      > >
      > > and
      > >
      > > something 2 else
      > > are lists,
      >
      > Just because a professor says it doesn't mean it's gospel because
      > clearly the above statement is false. I still haven't seen any patch
      > that proves your statement.
      >
      > wes
      >
    • Nov 12 2006 | 8:24 pm
      I should also note that 'd d d' is not a list, according to route,
      nor is "bob joe frank", yet the zl helpfile states they are. What was
      that about consistency Peter?
      im not trying to be a dick about it, I do understand now (thanks to
      earlier responses in the thread), that a 'true' list starts with an
      int or a float - and that this is due to underlying issues with how
      to disambiguate a list from a message. Check 10 4, roger, message
      received ( I was listening ;)
      My point is (now), that many Max objects treat non lists as lists,
      which makes one believe ROUTE should also (or thresh, or other
      objects that treat lists correctly - can you tell ive been digging?).
      In summation:
      keep it consistent - regardless of backend code.
      yes, it will break things. it will also save people lots of time
      scratching their heads, and make max that much more transparent,
      rather than schizophrenic.
      yes i know this wont happen. - why am I bothering again?
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 12, 2006, at 3:01 PM, Wesley Smith wrote:
      >> I still hold my ground - go to any classroom that is teaching Max
      >> and ask
      >> people (including the professor), if
      >>
      >> 1 something else
      >>
      >> and
      >>
      >> something 2 else
      >> are lists,
      >
      > Just because a professor says it doesn't mean it's gospel because
      > clearly the above statement is false. I still haven't seen any patch
      > that proves your statement.
      >
      > wes
    • Nov 12 2006 | 8:42 pm
      > In summation:
      >
      > keep it consistent - regardless of backend code.
      >
      > yes, it will break things. it will also save people lots of time scratching
      > their heads, and make max that much more transparent, rather than
      > schizophrenic.
      >
      > yes i know this wont happen. - why am I bothering again?
      Fair enough. I think everyone understands each other's positions now
      and we can let this thread die.
      wes
    • Nov 12 2006 | 8:45 pm
      AGREED. anton showed me this the other day and my face just fell.
      it's hard enough to teach max without stuff like this rearing its
      ugly head.
      i dare say that if 'jit_matrix castine' is not a list, a 't l l'
      object should not be able to pass it. grrr.
    • Nov 12 2006 | 8:49 pm
    • Nov 12 2006 | 8:57 pm
      On 12-Nov-2006, at 21:12, vade wrote:
      > And my point was also that the majority of the classroom (if not
      > all) would be wrong as well.
      If you asked the right classroom at the right point in time, the
      majority would have told you that Iraq was dangerous because S.H. had
      weapons of mass destruction and the best thing to do is to send in
      the US Marines.
      Making any decision because "the majority thinks so" is a mind-
      bogglingly, breathtakingly bad argument for doing pretty much anything.
      Whenever people agree with me I always feel I must be wrong...
    • Nov 12 2006 | 9:05 pm
      Quote: wesley.hoke@gmail.com wrote on Sun, 12 November 2006 21:26
      ----------------------------------------------------
      > Well, it may be true that other objects reinforce this idea, but Max
      > has been around for a while and the list/trigger/route thing is one of
      > the oldest parts. It's not going to change overnight. Is it really
      > that hard to remember that a list is something that beings with a
      > number? Just keep that in mind and you shjouldn't have any problems.
      > There are always exceptions somewhere.
      >
      Hi wesley,
      Trying to state this in an inoffensive but clear way: if max is ever to be taken as more than a prototyping language, issues like the one discussed in this thread must not be dismissed so easily. Nothing personal but especially 'is it really that hard to remember that a list is something that begins with a number?' seems like a rather naive statement.
      When you're working on a serious software solution, every ambiguity in the programming language you use can cost an enormous amount of time and annoyance. The most important aspect of a proper programming language is that it can be used to make things that the creators of the programming language didn't envision. Consequently the creators have to meet another standard than a system that works 'for now'.
      It is a fact that every maxer that didn't delve into externals development has a big problem understanding the way lists/strings/symbols/messages work. I think it's safe to say that the current system is not intuitive. If there is any way at all to improve it, it should be done.
      Regards,
      Mattijs
    • Nov 12 2006 | 9:06 pm
      ok, once again, thats for not only not LISTENING, but not being able
      to get the point either. MY POINT WAS THAT IT WASNT FUCKING CLEAR.
      You are either acting incredibly dense, or are incredibly dense.
      Considering your post history an accomplishments I refuse to believe
      you are that dense, so stop doing it on fucking purpose.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Nov 12 2006 | 9:12 pm
      Quote: vade wrote on Sun, 12 November 2006 22:06
      ----------------------------------------------------
      > ok, once again, thats for not only not LISTENING, but not being able
      > to get the point either. MY POINT WAS THAT IT WASNT FUCKING CLEAR.
      > You are either acting incredibly dense, or are incredibly dense.
      > Considering your post history an accomplishments I refuse to believe
      > you are that dense, so stop doing it on fucking purpose.
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      Haha.. Go vade!! I'm with you all the way!
    • Nov 12 2006 | 9:20 pm
      i get what you're saying, but unfortunately i'm still not clear on
      this - why would this prevent route from just always using the first
      element of a list to match against? are you saying that route has to
      convert all input to messages in order to parse them as lists? that
      seems a little bass-ackwards to me...
      On Nov 10, 2006, at 9:59 PM, Wesley Smith wrote:
      > On 11/10/06, evan.raskob [lists] wrote:
      >> why does an object have to respond to a message? why can't it just
      >> treat it is a form of list and parse it out?
      >
      > Effectively this *is* what it's doing. I was hoping you would answer
      > this way. So, "something 1 else" gets *parsed* as a message because
      > *something* defines an action or state that the objects responds to.
      > In the case of route, it responds to *every* possible message. Thus
      > "something 1 else" gets parsed as a message something followed by 1
      > and else. If it responded as a list proper, you would never be able
      > to to route out specific types of messages from each other which is
      > the entire point of the object. So, the scheme you're suggesting
      > would completely negate route's functionality and render it a no-op
      > for distinguishing anything but ints, floats, and your concept of a
      > list as a series of anything as opposed to the concept of a list as a
      > series of anything starting with a number. Do you see where your
      > logic fails here? I'm not trying to be rude or anything, I'm just
      > trying to be more straightforward and spell it out a bit more.
      >
      > best,
      > wes
    • Nov 12 2006 | 9:25 pm
      c'mon now, that's just silly.
      you've just gone and dropped the level of an interesting discussion
      down to ground floor.
      why don't you just let wesley argue the "pro-message" side, he was
      doing a fine job before you had to go and drag the entire iraq war
      into this. write an email to tony blair, not the max-list.
      On Nov 12, 2006, at 8:57 PM, Peter Castine wrote:
      > On 12-Nov-2006, at 21:12, vade wrote:
      >
      >> And my point was also that the majority of the classroom (if not
      >> all) would be wrong as well.
      >
      > If you asked the right classroom at the right point in time, the
      > majority would have told you that Iraq was dangerous because S.H.
      > had weapons of mass destruction and the best thing to do is to send
      > in the US Marines.
      >
      > Making any decision because "the majority thinks so" is a mind-
      > bogglingly, breathtakingly bad argument for doing pretty much
      > anything.
      >
      > Whenever people agree with me I always feel I must be wrong...
      >
      >
      >
    • Nov 12 2006 | 9:28 pm
    • Nov 12 2006 | 9:28 pm
      On 12 nov. 06, at 22:06, vade wrote:
      > ok, once again, thats for not only not LISTENING, but not being
      > able to get the point either. MY POINT WAS THAT IT WASNT FUCKING
      > CLEAR. You are either acting incredibly dense, or are incredibly
      > dense. Considering your post history an accomplishments I refuse to
      > believe you are that dense, so stop doing it on fucking purpose.
      Slow down everyone...
      In the (not to) old days, the trigger made distinctions between list/
      message, so "jit_matrix castineorwathever" wasn't working with a "t
      l" object. The distinction between list and message have been
      smoothed over the time, which tends to make it easier... or not. If
      "iter" works the same way with lists and messages, that's cool. For
      me, "route" is the special case, that's it.
      Best,
      ej
    • Nov 12 2006 | 9:40 pm
      Ok, this is all getting a little out of hand. Can we just hold the
      cursing and politics please? I know it takes alot of energy to ignore
      statements that touch one personally, but doing so keeps the
      discussion from going south. If we were meeting in person I don't
      think it would be a problem, but email's a different game.
      As for the more interesting part of the discussion, I'll just say that
      I understand where you guys are coming from with the ambiguity thing.
      If I could do something about it I would. I can't, so I'm just
      trying to explain why it is the way it is...give some insight. If you
      go back to my way earlier posts with the javascript example and the
      idea of there being 2 conceptions of "list"/subclasses, I think this
      pretty well represents the state of things as they are now. I'm not
      saying it's ideal, but it has been this way for a long long time and
      there's alot of inertia behind it. To change this is to change one of
      the most fundamental elements of Max and you can imagine what a task
      that would be.
      There's *alot* of work going into rethinking max right now, and I
      think this is a small small thing compared to other issues before us
      w/r/t max as a programming environemnt *as well as* a performance
      environment.
      thanks,
      wes
    • Nov 12 2006 | 9:54 pm
      Apologies for that outburtst. The native New Yorker in me came out
      swinging. That was meant for off list too. *chuckle*
      Im glad to know that Max is actively being re-worked. That is great
      news.
      Thanks again Wes and others.
      v a d e //
      www.vade.info
      abstrakt.vade.info
    • Nov 12 2006 | 10:08 pm
      hello list.
      i had problems using Wojciech Kosmas external "windowmanager" with
      Max 4.6.
      thanks for this great external, by the way!
      i wrote another windowmanager external called "io.window", which
      works here with max4.6 (PPC), and includes some more features...
      You can download it here:
      if you want to compile it, look at the code, extend it, or whatever,
      here is the xcode-project:
      have fun
      ingo
    • Nov 13 2006 | 1:52 pm
      What has not been stated (as far as I can see) is:
      The *documentation* to some objects that treat arbitrary messages *as
      if they were lists* washes over the distinction.
      - The Max engine (ie, the language) itself is absolutely consistent.
      The engine supports three basic data types (int, float, symbol) and
      two distinct complex data types: list (arbitrary concatenation of
      elements starting with an int or float) and message (arbitrary
      concatenation starting with a symbol).
      - Some objects treat arbitrary messages as if they were lists.
      If the documentation folks are reading (Gregory?), it might be
      helpful if iter.help read something like "Unpack lists one element at
      a time through its outlet. Arbitrary messages are also treated as if
      they were lists".
      Would that better help people to understand the distinction?
      Analogously for other objects that handle arbitrary messages the same
      way as lists.
      It is true that any object documentation that blurs the distinction
      between lists and messages will tend to confuse the people reading it.
      ----------
      Please ignore the following if you find the main thread tedious.
      On 12-Nov-2006, at 22:54, vade wrote:
      > Apologies for that outburtst. The native New Yorker in me came out
      > swinging. That was meant for off list too. *chuckle*
      If you are from New York, as am I, then neither of us needs to
      apologize for using a good, solid, Anglo-Saxon gerund. Nothing wrong
      with that if used selectively, particularly when used as positive
      reinforcement (ie to emphasize the adjectival phrase "puredead
      brilliant").
      On 12-Nov-2006, at 22:40, Wesley Smith wrote:
      > Can we just hold the cursing and politics please?
      As for politics, if that was in reference to my message, I was
      talking about an historical fact, not politics. Another subtle but
      important distinction that deserves not to be blurred.
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Nov 13 2006 | 4:03 pm
      Quote: Peter Castine wrote on Mon, 13 November 2006 14:52
      ----------------------------------------------------
      > The engine supports three basic data types (int, float, symbol) and
      > two distinct complex data types: list (arbitrary concatenation of
      > elements starting with an int or float) and message (arbitrary
      > concatenation starting with a symbol).
      >
      > - Some objects treat arbitrary messages as if they were lists.
      >
      I vote for this text to be written in the first pages of Max46Fundamentals.pdf.
    • Nov 13 2006 | 4:10 pm
      > It's certainly not obvious, and I'd go so far as to say that it's
      > pointless and confusing.
      >
      > Why should "messages" and "lists" be different? Isn't a message
      > merely a type of list?
      because there would be no longer a difference between
      "fuck, yeah" and "list fuck yeah" if that would be the same?
      Why would max need yet another basic datatype
      > when a message can clearly be counted and operated upon as if it were
      > a list?
      it would make sense if there would be only objects which
      either take lists or singel messages.
      but there are objects like route which take messages
      (a sequence of 1 symbol , number, bang ..) AND lists.
      > but it totally irrelevant now, unless I'm missing something obvious.
      dont we all, most of the time.
      i needed 3 years to find out that there is a maxmsp manual.
    • Nov 15 2006 | 12:40 am
      On 12-Nov-2006, at 22:20, evan.raskob [lists] wrote:
      > i get what you're saying, but unfortunately i'm still not clear on
      > this - why would this prevent route from just always using the
      > first element of a list to match against? are you saying that
      > route has to convert all input to messages in order to parse them
      > as lists? that seems a little bass-ackwards to me...
      Consider the following
      Currently: The message box on the left passes the message 'this' with
      some arguments to route. Route matches the symbol against the symbol
      'this' in its argument list (btw a simple comparison of two
      addresses) and sends the result out the middle inlet. The message box
      on the right passes the message 'list' with some arguments. Same
      deal, and the left outlet is triggered.
      What you seem to be suggesting is that the left message box should
      send a list message with a bunch of parameters, route should then
      peel off the first element of the list and test it against the
      initialization arguments, if there's a match at the symbol level use
      one outlet and otherwise use the general list outlet. Or am I
      misunderstanding you? Or do you want route to trigger two outlets in
      this situation??
      Aside from breaking existing patches that rely on route's current
      behavior, I don't see how either of the alternative approaches would
      be an improvement. But maybe I'm missing something.
      Also note that any significant change to the way a message box passes
      the 'this is not a list' message would require every single external
      object in Max to be updated accordingly. That's in the area of 4,000
      objects.
      >
      >
      >
      >
      > On Nov 10, 2006, at 9:59 PM, Wesley Smith wrote:
      >
      >> On 11/10/06, evan.raskob [lists] wrote:
      >>> why does an object have to respond to a message? why can't it just
      >>> treat it is a form of list and parse it out?
      >>
      >> Effectively this *is* what it's doing. I was hoping you would answer
      >> this way. So, "something 1 else" gets *parsed* as a message because
      >> *something* defines an action or state that the objects responds to.
      >> In the case of route, it responds to *every* possible message. Thus
      >> "something 1 else" gets parsed as a message something followed by 1
      >> and else. If it responded as a list proper, you would never be able
      >> to to route out specific types of messages from each other which is
      >> the entire point of the object. So, the scheme you're suggesting
      >> would completely negate route's functionality and render it a no-op
      >> for distinguishing anything but ints, floats, and your concept of a
      >> list as a series of anything as opposed to the concept of a list as a
      >> series of anything starting with a number. Do you see where your
      >> logic fails here? I'm not trying to be rude or anything, I'm just
      >> trying to be more straightforward and spell it out a bit more.
      >>
      >> best,
      >> wes
      >
      >
      -------------- http://www.bek.no/~pcastine/Litter/ -------------
      Peter Castine +--> Litter Power & Litter Bundle for Jitter
      Universal Binaries on the way
      iCE: Sequencing, Recording &
      Interface Building for |home | chez nous|
      Max/MSP Extremely cool |bei uns | i nostri|
    • Nov 15 2006 | 1:03 pm
      First, thanks for responding. It's good to get a hold on what
      exactly is going on in Max with lists and symbols - your post saying:
      "- The Max engine (ie, the language) itself is absolutely consistent.
      The engine supports three basic data types (int, float, symbol) and
      two distinct complex data types: list (arbitrary concatenation of
      elements starting with an int or float) and message (arbitrary
      concatenation starting with a symbol).
      - Some objects treat arbitrary messages as if they were lists."
      ...was very useful. It's always good to spell things out, even
      though they may have been implied all along.
      Second, let's get something out of the way - I am discussing this in
      a theoretical sense, where I could care less whether or not these
      ideas break all of Max so that it has to be completely rewritten. I
      think its very valuable to have discussions like that, and plus, I
      don't work for Cycling 74. And there's always Pd. ;)
      I'll state my position again, in better terms - in Max there is a
      concept of "message" vs. "list" where a "message" is an array(?) of
      basic max data types starting with a symbol, and a "list", which is
      in many cases *exactly the same thing* except it is required to start
      with an int.
      My issue with this is not only that these two overlap, but they are
      also completely non-intuitive and add to the arbitrary rules of Max.
      Conceptually, why should a list have to start with an int, when at
      first glance it works mostly like an Array? Such a basic part of Max
      should not be completely arbitrary, and I think the fact that there
      are inconsistencies makes it hard to take certain parts of max
      seriously. But maybe Max doesn't want to be taken so seriously, I
      don't know.
      As for [route], it is such a confusing object (because of messages,
      lists, and the shorthand notation of trigger and pack) that even
      *you* don't remember how it works properly, and you know max far
      better than I do:
      On Nov 15, 2006, at 12:40 AM, Peter Castine wrote:
      > On 12-Nov-2006, at 22:20, evan.raskob [lists] wrote:
      >> i get what you're saying, but unfortunately i'm still not clear on
      >> this - why would this prevent route from just always using the
      >> first element of a list to match against? are you saying that
      >> route has to convert all input to messages in order to parse them
      >> as lists? that seems a little bass-ackwards to me...
      >
      > Consider the following
      >
      > #P window setfont "Sans Serif" 9.;
      > #P window linecount 1;
      > #P message 188 105 71 196617 1 2 3 is a list;
      > #P message 100 105 81 196617 this is not a list;
      > #P newex 100 126 60 196617 route l this;
      > #P fasten 2 0 0 0 193 124 105 124;
      > #P connect 1 0 0 0;
      > #P window clipboard copycount 3;
      >
      > >
      > Currently: The message box on the left passes the message 'this'
      > with some arguments to route. Route matches the symbol against the
      > symbol 'this' in its argument list (btw a simple comparison of two
      > addresses) and sends the result out the middle inlet. The message
      > box on the right passes the message 'list' with some arguments.
      > Same deal, and the left outlet is triggered.
      >
      > What you seem to be suggesting is that the left message box should
      > send a list message with a bunch of parameters, route should then
      > peel off the first element of the list and test it against the
      > initialization arguments, if there's a match at the symbol level
      > use one outlet and otherwise use the general list outlet. Or am I
      > misunderstanding you? Or do you want route to trigger two outlets
      > in this situation??
      >
      > Aside from breaking existing patches that rely on route's current
      > behavior, I don't see how either of the alternative approaches
      > would be an improvement. But maybe I'm missing something.
      >
      > Also note that any significant change to the way a message box
      > passes the 'this is not a list' message would require every single
      > external object in Max to be updated accordingly. That's in the
      > area of 4,000 objects.
      >
      >
      >
      >>
      >>
      >>
      >>
      >> On Nov 10, 2006, at 9:59 PM, Wesley Smith wrote:
      >>
      >>> On 11/10/06, evan.raskob [lists] wrote:
      >>>> why does an object have to respond to a message? why can't it just
      >>>> treat it is a form of list and parse it out?
      >>>
      >>> Effectively this *is* what it's doing. I was hoping you would
      >>> answer
      >>> this way. So, "something 1 else" gets *parsed* as a message because
      >>> *something* defines an action or state that the objects responds to.
      >>> In the case of route, it responds to *every* possible message. Thus
      >>> "something 1 else" gets parsed as a message something followed by 1
      >>> and else. If it responded as a list proper, you would never be able
      >>> to to route out specific types of messages from each other which is
      >>> the entire point of the object. So, the scheme you're suggesting
      >>> would completely negate route's functionality and render it a no-op
      >>> for distinguishing anything but ints, floats, and your concept of a
      >>> list as a series of anything as opposed to the concept of a list
      >>> as a
      >>> series of anything starting with a number. Do you see where your
      >>> logic fails here? I'm not trying to be rude or anything, I'm just
      >>> trying to be more straightforward and spell it out a bit more.
      >>>
      >>> best,
      >>> wes
    • Nov 15 2006 | 1:27 pm
      > I'll state my position again, in better terms - in Max there is a
      > concept of "message" vs. "list" where a "message" is an array(?) of
      > basic max data types starting with a symbol, and a "list", which is
      > in many cases *exactly the same thing* except it is required to
      > start with an int.
      (or float.)
      I think, in terms of basic concepts, messages are different to lists
      because the symbol at the start of a message is imbued with a
      semantic meaning, so something like
      reset something
      Carries a connotation that it is attempting to reset something, whereas
      49 something
      does not. The former implies an action; the latter doesn't, and is
      therefore passive data. (So, read "reset something" as "reset
      (something)" rather than "[reset, something]".
      In any case, we're getting in the the territory of the code-vs-data
      arguments that keep Lisp programmers occupied.
      -- N.
      nick rothwell -- composition, systems, performance -- http://
      www.cassiel.com
    • Nov 15 2006 | 2:37 pm
      On Nov 15, 2006, at 1:27 PM, Nick Rothwell wrote:
      >> I'll state my position again, in better terms - in Max there is a
      >> concept of "message" vs. "list" where a "message" is an array(?)
      >> of basic max data types starting with a symbol, and a "list",
      >> which is in many cases *exactly the same thing* except it is
      >> required to start with an int.
      >
      > (or float.)
      >
      > I think, in terms of basic concepts, messages are different to
      > lists because the symbol at the start of a message is imbued with a
      > semantic meaning, so something like
      >
      > reset something
      >
      > Carries a connotation that it is attempting to reset something,
      > whereas
      >
      > 49 something
      >
      > does not. The former implies an action; the latter doesn't, and is
      > therefore passive data. (So, read "reset something" as "reset
      > (something)" rather than "[reset, something]".
      true, but then there's a cross-over, because a list is an arbitrary
      grouping of primitive max data types, EXCEPT when they start with a
      symbol. so a message is a sub-set of list... but it's not treated
      that way.
      one way around this is to slightly break route (which I'd argue is
      already conceptually and semantically fudged) and establish lists as
      true arrays of ANY datatype at ANY position, and then make all
      messages a stronger datatype called "message" which has an "action"
      followed by arguments, like a real function call in a programming
      language.
      then, you could turn a message into list, and likewise, by either
      using objects or [prepend message] or [prepend list]. there already
      is [tosymbol] and [symbol], so this would fit in conceptually with
      the rest of max.
      note that javascript in max already treats messages and lists in this
      manner, behind the scenes.
      > In any case, we're getting in the the territory of the code-vs-data
      > arguments that keep Lisp programmers occupied.
      ooh, now you're going to start a flame-war ;)
    • Nov 16 2006 | 7:32 am
      vade wrote:
      > This strikes me as a cludge, and my gut instinct is to point
      > it out and say, THIS SHOULD BE FIXED!
      There is a bug with route, which has not been covered yet!:
      If I send "something 2 list" to [route list], its correct that it routes
      it out of the right outlet, because its a message. We got this now. But
      if I send "list something 2 list" its still coming out the right outlet
      and thats plain wrong no matter how I define a list!!! (this should and
      could be fixed!!!)
      from the fundamentals:
      A list of two or more numbers separated by spaces (such as 60 79 1.02 4)
      is of the type list. The message need not (but may) begin with the word
      list. Max recognizes a list whenever it sees a message consisting of a
      number followed by anything. In fact, a list can contain words as well
      as numbers (as in the message 1 start 768), so long as it begins with a
      number. A list can contain up to 256 items.
      I would love to see an anhancement of that definition which I believe
      would not break old patches as long as all externals dealing with lists
      learn it:
      ... Max recognizes a list whenever it sees a message consisting of a
      number followed by anything or the message list followed by anything. In
      fact, a list can contain symbols as well as numbers or be empty...
      That would allow finally to deal with one and zero element lists. The
      only object that creates a valid one element list is as far as I know
      the trigger object. But its of no use, it converts numbers into lists
      but a single lement list creates more confusion than is helpfull,
      because its rejected by objects which cannot deal with lists.
      Trigger converts inputs to the type specified (sometimes). In one case
      it does so annoyingly (because I can't tell it to leave it as it is) and
      in the other case its not:
      If I send a number to [t l], it will be coverted to a list with one
      element. But if I send it a message, it will not convert it to a list,
      it remains as message.
      To do so I send it through a [zl reg] which should deals with lists, but
      it converts one element lists, and strips the keyword list as well.
      The patch explains all that odd behaviours. And I believe the main
      problem is that odd definition what a list is. Enhancing the list
      definition by the keyword list with anything OR a number followed by
      anything would solve it.
      Stefan
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Nov 16 2006 | 4:17 pm
      What if the max interface would just handle datatypes the way every language does? With clear typecasting, only if you explicitly choose to do so. I tried to explain this with the attached example image.
      Cheers,
      Mattijs
    • Nov 16 2006 | 5:17 pm
      or typecast within a message box, so everything is a 'subclass' of
      message ?
      [int 45]
      [float 45.]
      [list lists can start with whatever we want now]
      [list 1 2 3 4 5 6 7]
      [symbol "astf zomg yes"]
      you could then typecast by doing
      [prepend list]
      everything would otherwise be considered a message. I havent thought
      this through, so im sure there are issues...
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      > What if the max interface would just handle datatypes the way every
      > language does? With clear typecasting, only if you explicitly
      > choose to do so. I tried to explain this with the attached example
      > image.
      >
      > Cheers,
      > Mattijs
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
      >
    • Nov 16 2006 | 5:41 pm
      Quote: vade wrote on Thu, 16 November 2006 18:17
      ----------------------------------------------------
      > or typecast within a message box, so everything is a 'subclass' of
      > message ?
      >
      > [int 45]
      > [float 45.]
      > [list lists can start with whatever we want now]
      > [list 1 2 3 4 5 6 7]
      > [symbol "astf zomg yes"]
      >
      > you could then typecast by doing
      >
      > [prepend list]
      I think that would have to be
      [route int]
      [prepend list]
      guess better would be
      [cast list]
      but still wouldn't it be better to put explicit typecasting in the basis of the system and make sure the datatype and the content are visually separated?
      Considering the method I proposed, no externals would have to be changed, only the max core. If patch cords would automatically connect to their datatype counterpart when an old patch is imported, most old patches would still work.
      >
      > everything would otherwise be considered a message. I havent thought
      > this through, so im sure there are issues...
      >
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      > On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      >
      > > What if the max interface would just handle datatypes the way every
      > > language does? With clear typecasting, only if you explicitly
      > > choose to do so. I tried to explain this with the attached example
      > > image.
      > >
      > > Cheers,
      > > Mattijs
      > > --
      > > SmadSteck - http://www.smadsteck.nl
      > > Interactive audiovisual sampling soft- and hardware
      > >
      > >
      >
      >
      >
      >
      ----------------------------------------------------
    • Nov 16 2006 | 6:51 pm
      yes!!!
      that's what i was getting at with my long rants.
      except that, like i proposed, "message" and "list" would be
      different, with no subclassing - so that lists starting with symbols
      other than numbers would be allowed.
      On Nov 16, 2006, at 5:17 PM, vade wrote:
      > or typecast within a message box, so everything is a 'subclass' of
      > message ?
      >
      > [int 45]
      > [float 45.]
      > [list lists can start with whatever we want now]
      > [list 1 2 3 4 5 6 7]
      > [symbol "astf zomg yes"]
      >
      > you could then typecast by doing
      >
      > [prepend list]
      >
      > everything would otherwise be considered a message. I havent
      > thought this through, so im sure there are issues...
      >
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      > On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      >
      >> What if the max interface would just handle datatypes the way
      >> every language does? With clear typecasting, only if you
      >> explicitly choose to do so. I tried to explain this with the
      >> attached example image.
      >>
      >> Cheers,
      >> Mattijs
      >> --
      >> SmadSteck - http://www.smadsteck.nl
      >> Interactive audiovisual sampling soft- and hardware
      >>
      >>
      >
    • Nov 16 2006 | 6:58 pm
      hmm... a "cast" object, there's a thought.
      or, [tolist] and [tomessage] (like [tosymbol])
      i'd vote for [list] or [message], which could work like [int] and
      [float] to automatically typecast their inputs, much like in Java.
      but under the hood, following the rest of max/jitter, you'd need it
      to say "DATATYPE variable_name" much like "jit_matrix bubba"
      there is already [zl reg] for creating/storing a list, but it's odd
      to have it in an object called [zl].
      anyway, i'll stop ranting on this subject now (is anyone out there
      still following this thread but the 3 or 4 of us??)
      On Nov 16, 2006, at 5:41 PM, Mattijs Kneppers wrote:
      >
      > Quote: vade wrote on Thu, 16 November 2006 18:17
      > ----------------------------------------------------
      >> or typecast within a message box, so everything is a 'subclass' of
      >> message ?
      >>
      >> [int 45]
      >> [float 45.]
      >> [list lists can start with whatever we want now]
      >> [list 1 2 3 4 5 6 7]
      >> [symbol "astf zomg yes"]
      >>
      >> you could then typecast by doing
      >>
      >> [prepend list]
      >
      > I think that would have to be
      >
      > [route int]
      > [prepend list]
      >
      > guess better would be
      >
      > [cast list]
      >
      > but still wouldn't it be better to put explicit typecasting in the
      > basis of the system and make sure the datatype and the content are
      > visually separated?
      >
      > Considering the method I proposed, no externals would have to be
      > changed, only the max core. If patch cords would automatically
      > connect to their datatype counterpart when an old patch is
      > imported, most old patches would still work.
      >
      >>
      >> everything would otherwise be considered a message. I havent thought
      >> this through, so im sure there are issues...
      >
      >
      >
      >>
      >>
      >>
      >> v a d e //
      >>
      >> www.vade.info
      >> abstrakt.vade.info
      >>
      >>
      >> On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      >>
      >>> What if the max interface would just handle datatypes the way every
      >>> language does? With clear typecasting, only if you explicitly
      >>> choose to do so. I tried to explain this with the attached example
      >>> image.
      >>>
      >>> Cheers,
      >>> Mattijs
      >>> --
      >>> SmadSteck - http://www.smadsteck.nl
      >>> Interactive audiovisual sampling soft- and hardware
      >>>
      >>>
      >>
      >>
      >>
      >>
      > ----------------------------------------------------
      >
      >
      > --
      > SmadSteck - http://www.smadsteck.nl
      > Interactive audiovisual sampling soft- and hardware
      >
    • Nov 16 2006 | 7:33 pm
      Probably not. Doesnt mean we arent giving ideas to the PD people :P
      But seriously, I think it helps, and im sure C74 is listening
      quietly, silently judging all our requests and weighing them
      accordingly. This stuff breaks just about everything, but could be
      very useful in the long run. Things need to evolve and adapt to
      changing needs. People are pushing max harder and harder, and cracks
      in the foundation might show up.
      Anyway.
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 16, 2006, at 1:58 PM, evan.raskob [lists] wrote:
      > hmm... a "cast" object, there's a thought.
      >
      > or, [tolist] and [tomessage] (like [tosymbol])
      >
      > i'd vote for [list] or [message], which could work like [int] and
      > [float] to automatically typecast their inputs, much like in Java.
      > but under the hood, following the rest of max/jitter, you'd need it
      > to say "DATATYPE variable_name" much like "jit_matrix bubba"
      >
      > there is already [zl reg] for creating/storing a list, but it's odd
      > to have it in an object called [zl].
      >
      > anyway, i'll stop ranting on this subject now (is anyone out there
      > still following this thread but the 3 or 4 of us??)
      >
      >
      >
      > On Nov 16, 2006, at 5:41 PM, Mattijs Kneppers wrote:
      >
      >>
      >> Quote: vade wrote on Thu, 16 November 2006 18:17
      >> ----------------------------------------------------
      >>> or typecast within a message box, so everything is a 'subclass' of
      >>> message ?
      >>>
      >>> [int 45]
      >>> [float 45.]
      >>> [list lists can start with whatever we want now]
      >>> [list 1 2 3 4 5 6 7]
      >>> [symbol "astf zomg yes"]
      >>>
      >>> you could then typecast by doing
      >>>
      >>> [prepend list]
      >>
      >> I think that would have to be
      >>
      >> [route int]
      >> [prepend list]
      >>
      >> guess better would be
      >>
      >> [cast list]
      >>
      >> but still wouldn't it be better to put explicit typecasting in the
      >> basis of the system and make sure the datatype and the content are
      >> visually separated?
      >>
      >> Considering the method I proposed, no externals would have to be
      >> changed, only the max core. If patch cords would automatically
      >> connect to their datatype counterpart when an old patch is
      >> imported, most old patches would still work.
      >>
      >>>
      >>> everything would otherwise be considered a message. I havent thought
      >>> this through, so im sure there are issues...
      >>
      >>
      >>
      >>>
      >>>
      >>>
      >>> v a d e //
      >>>
      >>> www.vade.info
      >>> abstrakt.vade.info
      >>>
      >>>
      >>> On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      >>>
      >>>> What if the max interface would just handle datatypes the way every
      >>>> language does? With clear typecasting, only if you explicitly
      >>>> choose to do so. I tried to explain this with the attached example
      >>>> image.
      >>>>
      >>>> Cheers,
      >>>> Mattijs
      >>>> --
      >>>> SmadSteck - http://www.smadsteck.nl
      >>>> Interactive audiovisual sampling soft- and hardware
      >>>>
      >>>>
      >>>
      >>>
      >>>
      >>>
      >> ----------------------------------------------------
      >>
      >>
      >> --
      >> SmadSteck - http://www.smadsteck.nl
      >> Interactive audiovisual sampling soft- and hardware
      >>
      >
    • Nov 16 2006 | 9:52 pm
      Actually, im curious what people following this thread would think of
      something Ive been working on.
      Im curious if people would find it useful. It makes life a lot easier
      for myself, I must say.
      login beta
      password p0lyt3ch
      checkout the screencasts to get an idea of what Im going for.
      Stay tuned for more.
      v a d e //
      www.vade.info
      abstrakt.vade.info
      On Nov 16, 2006, at 2:33 PM, vade wrote:
      > Probably not. Doesnt mean we arent giving ideas to the PD people :P
      >
      > But seriously, I think it helps, and im sure C74 is listening
      > quietly, silently judging all our requests and weighing them
      > accordingly. This stuff breaks just about everything, but could be
      > very useful in the long run. Things need to evolve and adapt to
      > changing needs. People are pushing max harder and harder, and
      > cracks in the foundation might show up.
      >
      > Anyway.
      >
      >
      > v a d e //
      >
      > www.vade.info
      > abstrakt.vade.info
      >
      >
      >
      > On Nov 16, 2006, at 1:58 PM, evan.raskob [lists] wrote:
      >
      >> hmm... a "cast" object, there's a thought.
      >>
      >> or, [tolist] and [tomessage] (like [tosymbol])
      >>
      >> i'd vote for [list] or [message], which could work like [int] and
      >> [float] to automatically typecast their inputs, much like in
      >> Java. but under the hood, following the rest of max/jitter, you'd
      >> need it to say "DATATYPE variable_name" much like "jit_matrix bubba"
      >>
      >> there is already [zl reg] for creating/storing a list, but it's
      >> odd to have it in an object called [zl].
      >>
      >> anyway, i'll stop ranting on this subject now (is anyone out there
      >> still following this thread but the 3 or 4 of us??)
      >>
      >>
      >>
      >> On Nov 16, 2006, at 5:41 PM, Mattijs Kneppers wrote:
      >>
      >>>
      >>> Quote: vade wrote on Thu, 16 November 2006 18:17
      >>> ----------------------------------------------------
      >>>> or typecast within a message box, so everything is a 'subclass' of
      >>>> message ?
      >>>>
      >>>> [int 45]
      >>>> [float 45.]
      >>>> [list lists can start with whatever we want now]
      >>>> [list 1 2 3 4 5 6 7]
      >>>> [symbol "astf zomg yes"]
      >>>>
      >>>> you could then typecast by doing
      >>>>
      >>>> [prepend list]
      >>>
      >>> I think that would have to be
      >>>
      >>> [route int]
      >>> [prepend list]
      >>>
      >>> guess better would be
      >>>
      >>> [cast list]
      >>>
      >>> but still wouldn't it be better to put explicit typecasting in
      >>> the basis of the system and make sure the datatype and the
      >>> content are visually separated?
      >>>
      >>> Considering the method I proposed, no externals would have to be
      >>> changed, only the max core. If patch cords would automatically
      >>> connect to their datatype counterpart when an old patch is
      >>> imported, most old patches would still work.
      >>>
      >>>>
      >>>> everything would otherwise be considered a message. I havent
      >>>> thought
      >>>> this through, so im sure there are issues...
      >>>
      >>>
      >>>
      >>>>
      >>>>
      >>>>
      >>>> v a d e //
      >>>>
      >>>> www.vade.info
      >>>> abstrakt.vade.info
      >>>>
      >>>>
      >>>> On Nov 16, 2006, at 11:17 AM, Mattijs Kneppers wrote:
      >>>>
      >>>>> What if the max interface would just handle datatypes the way
      >>>>> every
      >>>>> language does? With clear typecasting, only if you explicitly
      >>>>> choose to do so. I tried to explain this with the attached example
      >>>>> image.
      >>>>>
      >>>>> Cheers,
      >>>>> Mattijs
      >>>>> --
      >>>>> SmadSteck - http://www.smadsteck.nl
      >>>>> Interactive audiovisual sampling soft- and hardware