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| http://www.dspaudio.com/ http://www.castine.de
    • 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| http://www.dspaudio.com/ http://www.castine.de
    • 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.
    • 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| http://www.dspaudio.com/ http://www.castine.de
    • 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| http://www.dspaudio.com/ http://www.castine.de
    • 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| http://www.dspaudio.com/ http://www.castine.de
    • 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 >>>>> >>>>> >>>> >>>> >>>> >>>> >>> ---------------------------------------------------- >>> >>> >>> -- >>> SmadSteck - http://www.smadsteck.nl >>> Interactive audiovisual sampling soft- and hardware >>> >> >
    • Nov 16 2006 | 10:26 pm
      Actually, im curious what people following this thread would think of some things Ive been working on (and is still a work in progress)
      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.
      v a d e //
      www.vade.info abstrakt.vade.info
    • Nov 17 2006 | 3:28 am
      great job , specially "the concept expansion". would love to try it out when it's beta-ready...
      k
      Quote: vade wrote on Thu, 16 November 2006 14:26 ---------------------------------------------------- > Actually, im curious what people following this thread would think of > some things Ive been working on (and is still a work in progress) > > Im curious if people would find it useful. It makes life a lot easier > for myself, I must say. > > http://001.vade.info/?page_id=13 > > login beta > password p0lyt3ch > > checkout the screencasts to get an idea of what Im going for. > > v a d e // > > www.vade.info > abstrakt.vade.info > > ----------------------------------------------------
    • Nov 17 2006 | 3:47 am
      Thanks for the kind words. Im hoping tomorrow I can have the basic patch files ready and one or two example patches of usage, with modules, etc.
      the last 10% is 90% of the work. God thats annoying. :)
      v a d e //
      www.vade.info abstrakt.vade.info
      On Nov 16, 2006, at 10:28 PM, karl-otto von oertzen wrote:
      > > great job , specially "the concept expansion". > would love to try it out when it's beta-ready... > > > k > > Quote: vade wrote on Thu, 16 November 2006 14:26 > ---------------------------------------------------- >> Actually, im curious what people following this thread would think of >> some things Ive been working on (and is still a work in progress) >> >> Im curious if people would find it useful. It makes life a lot easier >> for myself, I must say. >> >> http://001.vade.info/?page_id=13 >> >> login beta >> password p0lyt3ch >> >> checkout the screencasts to get an idea of what Im going for. >> >> v a d e // >> >> www.vade.info >> abstrakt.vade.info >> >> > ---------------------------------------------------- > > > -- > karrrlo > www.marswalkers.org > www.fleeingbirds.org
    • Nov 20 2006 | 2:02 pm
      Quote: vade wrote on Thu, 16 November 2006 23:26 ---------------------------------------------------- > Actually, im curious what people following this thread would think of > some things Ive been working on (and is still a work in progress) > > Im curious if people would find it useful. It makes life a lot easier > for myself, I must say.
      hey vade, it looks like you're doing a great job on very slippery terrain. I can imagine what you're going through making this in max. I am working on a system that is quite as elaborate, also to enhance Max core functionality. According to my experience, max is not up to a task like this, which means there are a lot of loose ends to deal with, which costs tremendous amounts of time.
      Keep up the good work! Mattijs
    • Nov 20 2006 | 2:24 pm
      you sir have spoken very well. Thats why im making it open source :P I imagine many people have solved similar problems, yet I dont see much of a 'terrain guide', let alone best practices, etc. This will be somewhat of an attempt to at that. And why should Max NOT be up to a task like this?
      I really feel as though every time I try and make something passed a certain threshold of complexity, no matter what approach I take within Max/MSP proper, Max inexplicably decides to do something totally unexpected and ruin my plans - and weeks of my time.
      Of course people will say this is me, and ill take the blame 90% of the time, but science-dammit, its annoying as all hell, and there are times I just want to find a surrogate for Max and punch it in the face repeatedly - so I dont throw my powerbook out of a 12 story window.
      Someone wise once told me to hate your tools, its the only way to transcend them. Maybe im taking it too literally with Max?
      v a d e //
      www.vade.info abstrakt.vade.info
      On Nov 20, 2006, at 9:02 AM, Mattijs Kneppers wrote:
      > > Quote: vade wrote on Thu, 16 November 2006 23:26 > ---------------------------------------------------- >> Actually, im curious what people following this thread would think of >> some things Ive been working on (and is still a work in progress) >> >> Im curious if people would find it useful. It makes life a lot easier >> for myself, I must say. > > hey vade, it looks like you're doing a great job on very slippery > terrain. I can imagine what you're going through making this in > max. I am working on a system that is quite as elaborate, also to > enhance Max core functionality. According to my experience, max is > not up to a task like this, which means there are a lot of loose > ends to deal with, which costs tremendous amounts of time. > > Keep up the good work! > Mattijs > -- > SmadSteck - http://www.smadsteck.nl > Interactive audiovisual sampling soft- and hardware >
    • Nov 20 2006 | 8:03 pm
      Quote: vade wrote on Mon, 20 November 2006 15:24 ---------------------------------------------------- > you sir have spoken very well. Thats why im making it open source :P > I imagine many people have solved similar problems, yet I dont see > much of a 'terrain guide', let alone best practices, etc. This will > be somewhat of an attempt to at that. And why should Max NOT be up to > a task like this?
      Maybe because the developers didn't anticipate people who would use it as a toolbuilding-tools building tool. Only as a toolbuilding tool. I hope I am making myself clear :p. Max was always the last step before the end of the chain, the end of the chain being relatively simple patches that accomplished a single task. It was never designed as a programming environment that allows for unlimited expansion.
      I can't blame them by the way, we're talking about a long history. Max originated as a smart way to manipulate data, aimed at musical compositions. Not as a general-purpose programming language. They can't help the enthousiasm they trigger among developers. Maybe the question we should have asked cycling, before blaming them for every small inconcistency, is: would you like us to treat max as a general-purpose programming language?
      > > I really feel as though every time I try and make something passed a > certain threshold of complexity, no matter what approach I take > within Max/MSP proper, Max inexplicably decides to do something > totally unexpected and ruin my plans - and weeks of my time.
      Yep, same here.
      > > Of course people will say this is me, and ill take the blame 90% of > the time, but science-dammit, its annoying as all hell, and there are > times I just want to find a surrogate for Max and punch it in the > face repeatedly - so I dont throw my powerbook out of a 12 story window. > > Someone wise once told me to hate your tools, its the only way to > transcend them. Maybe im taking it too literally with Max?
      Hmm, maybe it's time to move on (is what I am thinking a lot lately). Start hating some low-level C++ libraries and give cycling 74 some peace.
      Mattijs
    • Nov 20 2006 | 8:41 pm
      FWIW, I personally went into C++ purgatory back in January only to return to using Max and Jitter a few months later. For advanced uses of Max, I think it is essential to know when and how to move between making custom extensions and when to use built in objects.
      I will admit that interface issues are a trickier subject. There are some facilities available for doing GUI objects as documented in the WritingMaxExternals.pdf CHs 9-12. I personally am holding off until I see what Max5 makes available before I make a decision as to whether Max can support "toolbuilding-tools building tool".
      wes
    • Nov 20 2006 | 9:14 pm
      On Nov 20, 2006, at 3:03 PM, Mattijs Kneppers wrote:
      > > Maybe because the developers didn't anticipate people who would use > it as a toolbuilding-tools building tool. Only as a toolbuilding > tool. I hope I am making myself clear :p. Max was always the last > step before the end of the chain, the end of the chain being > relatively simple patches that accomplished a single task. It was > never designed as a programming environment that allows for > unlimited expansion. > > I can't blame them by the way, we're talking about a long history. > Max originated as a smart way to manipulate data, aimed at musical > compositions. Not as a general-purpose programming language. They > can't help the enthousiasm they trigger among developers. Maybe the > question we should have asked cycling, before blaming them for > every small inconcistency, is: would you like us to treat max as a > general-purpose programming language? > >>
      Of course. I think youve hit the nail on the head with regards to the building tools metaphor, but, in a way, isnt that the whole point?
      The sorts of constructions Im working on arent breathtakingly complex, or really all that amazing from a compotent max building perspective, they seem like a totally logical progression from basic max work to decent programming concepts and all I am doing is trying to make things as well rounded, consistent,user friendly and 'proper' as can be. I still go completely insane when I remember how useless bpatchers can be when nested and used as really deep modular structures, or how having one patch open with many bpatchers in it can lower your framerate, even if the patch isnt being banged and running. I feel these things are quality of life issues, to put it in terms of how it makes me feel.
      > Hmm, maybe it's time to move on (is what I am thinking a lot > lately). Start hating some low-level C++ libraries and give cycling > 74 some peace.
      Ive been toying with Cocoa and Obj-C, but Max is just so goddamned flexible out of the box. Quartz Composer pales in comparison to Jitter. It makes me so sad :) It just proves how great Max is as well. The only reason im so vocal, is because I dont really want to abandon Max.... not that OBJ-C and QC are targeted at the same audience, or even the same sort of developers... > > --- > > FWIW, > I personally went into C++ purgatory back in January only to return to > using Max and Jitter a few months later. For advanced uses of Max, I > think it is essential to know when and how to move between making > custom extensions and when to use built in objects. > > I will admit that interface issues are a trickier subject. There are > some facilities available for doing GUI objects as documented in the > WritingMaxExternals.pdf CHs 9-12. I personally am holding off until I > see what Max5 makes available before I make a decision as to whether > Max can support > "toolbuilding-tools building tool".
      Im very curious about this too (v 5). My gut says a lot of this will be addressed, and I hope Max 5 is in a sense, a new foundation, re- written with some of the ideas and limitations of the current Max engine taken into account.
      Anyway, this thread has been epic. Back to hating thispatcher scripting and non double-buffered bpatchers ;)
      > > Mattijs > -- > SmadSteck - http://www.smadsteck.nl > Interactive audiovisual sampling soft- and hardware >
    • Nov 20 2006 | 10:04 pm
      i think you hit the wall with any programming environment/language, at some point. God, at least you're not using Flash - you want to talk about inconsistent, unreliable, and arbitrary? :)
      -ev
      On Nov 20, 2006, at 2:24 PM, vade wrote:
      > you sir have spoken very well. Thats why im making it open > source :P I imagine many people have solved similar problems, yet I > dont see much of a 'terrain guide', let alone best practices, etc. > This will be somewhat of an attempt to at that. And why should Max > NOT be up to a task like this? > > I really feel as though every time I try and make something passed > a certain threshold of complexity, no matter what approach I take > within Max/MSP proper, Max inexplicably decides to do something > totally unexpected and ruin my plans - and weeks of my time. > > Of course people will say this is me, and ill take the blame 90% of > the time, but science-dammit, its annoying as all hell, and there > are times I just want to find a surrogate for Max and punch it in > the face repeatedly - so I dont throw my powerbook out of a 12 > story window. > > Someone wise once told me to hate your tools, its the only way to > transcend them. Maybe im taking it too literally with Max? > > > v a d e // > > www.vade.info > abstrakt.vade.info > >