line~ question


    Dec 17 2007 | 9:20 am
    I don't understand why one of these cases doesn't work:
    Anyone have an answer?
    Thanks,
    Chris
    --
    Chris Muir | "There are many futures and only one status quo.
    cbm@well.com | This is why conservatives mostly agree,
    http://www.xfade.com | and radicals always argue." - Brian Eno

    • Dec 17 2007 | 10:36 am
    • Dec 17 2007 | 11:04 am
      On 17 Dec 2007, at 10:20, Chris Muir wrote:
      >
      > I don't understand why one of these cases doesn't work:
      i believe the use of a comma for splitting lists or messages, is a
      feature of the message*box*, not of a message per se.
      personally i dislike the idea of formatting messages with commas with
      [sprintf] to be used by a message box.
      you could easily replace the comma by a '0' and achieve the same result.
      volker
    • Dec 17 2007 | 5:31 pm
      The working example does indeed respect the comma as an iter (through the message box) while the output from the sprintf (in both examples) does not.
      Doesn't solve you problem. As the Dr. says "Than don't do that).
      KMc
      Chris Muir wrote:
      I don't understand why one of these cases doesn't work:
      Anyone have an answer?
      Thanks,
      Chris
      --
      Chris Muir | "There are many futures and only one status quo.
      cbm@well.com | This is why conservatives mostly agree,
      http://www.xfade.com | and radicals always argue." - Brian Eno
      Keith McMillen
      BEAM Foundation
      http://www.beamfoundation.org/
      510.502.5310
    • Dec 17 2007 | 10:16 pm
      Chris,
      In you "non-working" example, I'm pretty sure sprintf is spitting out a single string with an embedded escaped comma. line~ doesn't know what to do with embedded escaped commas.
      In the second example, [prepend set] receives a message with an embedded, escaped comma and does it's thing, sending a set message with an atom list including an embedded, escaped comma to your message box. The message box interprets the set message (including the embedded, escaped you-know-what), to set its content and then recieves a bang to pass its content on. It is at this point--and not one picosecond sooner--that Max message parsing kicks in, the comma (now un-escaped) signals end-of-message/new-message-begin and you get the expected behavior.
      Why you go through the palaver with sprintf when you could just do the following escapes me
      As Olivier is reputed to have said, it's much easier…
    • Dec 17 2007 | 10:23 pm
      One other thing...
      The Max clip you included is very instructive about one point that occasionally comes up on this list/forum:
      >
      Everyone look carefully at how Max escapes the comma in order to make sure you'll get the sprintf arguments you want. A triple-escape! One backslash to escape the backslash character, another to escape the comma.
      This is a C programmer's dream. Or nightmare.
      -- P
    • Dec 18 2007 | 1:53 am
      At 11:16 PM +0100 12/17/07, Peter Castine wrote:
      >Why you go through the palaver with sprintf when you could just do the following escapes me
      Well... in the real patch my example was taken from, the two times come from different sources, and message boxes don't lend themselves to that as well.
      I'd like to thank everyone who chimed in on this thread. I particularly like Volker's suggestion, earlier in the thread, of just using "0 0" instead of "0," in my sprintf format string. I had a forehead slapping moment with that one.
      -C
      --
      Chris Muir | "There are many futures and only one status quo.
      cbm@well.com | This is why conservatives mostly agree,
      http://www.xfade.com | and radicals always argue." - Brian Eno
    • Dec 18 2007 | 11:59 am
      Quote: Chris Muir wrote on Tue, 18 December 2007 02:53
      ----------------------------------------------------
      > Well... in the real patch my example was taken from, the two times come from different sources, and message boxes don't lend themselves to that as well.
      ----------------------------------------------------
      Fair enough, but then I would use a pack object (or pak) to collect input and put the packed output through the message box, using $1 $2 etc.
      The comma as a message delimiter is a very message box thing.
      sprintf is useful for formatting weird arrangements of letters, but it doesn't know anything about message delimiters and receivers.
    • Dec 18 2007 | 5:05 pm
      Also, note that using the comma can potentially introduce timing
      glitches between the arrival of the two messages. (in that it may not
      be uniform for all repetitions of that message box) I suspect this is
      why function has the "output list for line~" option in its inspector.
      Using value1 0 value2 time is a better way to go.
      Peter McCulloch
    • Dec 20 2007 | 7:35 am
      Peter McCulloch schrieb:
      > Also, note that using the comma can potentially introduce timing
      > glitches between the arrival of the two messages. (in that it may not
      > be uniform for all repetitions of that message box) I suspect this is
      > why function has the "output list for line~" option in its inspector.
      Its not different than a [t b 0] with the bang triggering a message box
      without comma. I don't see the potential of timing glitches. The "list
      for line~" option is for convenience - obviosly, as the comma in a
      message box is for convenience...
      Convenience can be confusing, if someone is in the state of learning...
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Dec 20 2007 | 8:40 am
      At 8:35 AM +0100 12/20/07, Stefan Tiedje wrote:
      >Convenience can be confusing, if someone is in the state of learning...
      As we all should be.
      -C
      --
      Chris Muir | "There are many futures and only one status quo.
      cbm@well.com | This is why conservatives mostly agree,
      http://www.xfade.com | and radicals always argue." - Brian Eno
    • Dec 20 2007 | 9:00 am
    • Dec 20 2007 | 11:24 pm
      Emmanuel Jourdan schrieb:
      > confused? or in the learning process? ;-)
      What's the difference???
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com
    • Dec 21 2007 | 11:10 am
      When one is confused, one needs to learn more to resolve confusion. Ergo, he who is confused is also in the learning state.
      He who is learning is not necessarily confused. With a good teacher, states of confusion occur but generally do not last long.
      --
      Which reminds me of the other aphorism: "The problem with self-taught composers is that they had such mediocre teachers." Salt to taste.
      -- P.
    • Dec 21 2007 | 5:04 pm
      At 12:10 PM +0100 12/21/07, Peter Castine wrote:
      >Which reminds me of the other aphorism: "The problem with self-taught composers is that they had such mediocre teachers." Salt to taste.
      Among my favorite aphorisms is: "Aphorism is better than none."
      -C
      --
      Chris Muir | "There are many futures and only one status quo.
      cbm@well.com | This is why conservatives mostly agree,
      http://www.xfade.com | and radicals always argue." - Brian Eno
    • Dec 21 2007 | 5:32 pm
      I disagree. There IS a slight difference, especially when looping,
      and particularly when you have a lot of stuff going on. This is
      dependent on scheduler load, processor speed, etc., but it can
      introduce very slight differences, which I have definitely observed
      this behavior on my G4 under heavier loads, and the difference was
      between one list and two messages. I would imagine that longer
      lists might exacerbate this effect, as they introduce more of a queue.
      If you have two scheduler messages in your loop, it increases the
      slop factor with the scheduler. For 95% of the time, this isn't an
      issue, and it's on the order of milliseconds at worst, but it's just
      another one of those things that can be taken into account if timings
      aren't quite working as expected.
      Peter McCulloch
    • Dec 24 2007 | 5:45 am
      Peter McCulloch schrieb:
      > I disagree. There IS a slight difference, especially when looping,
      > and particularly when you have a lot of stuff going on.
      I guess this is hard to proove, I can imagine that the message box in
      general is more expensive on the CPU than triggers, but the main rules
      for the order of execution is for sure the same and would not make any
      difference. Elsewise it would be a bug and should be reported as such...
      I do agree to avoid the commas in a message btw. but for aesthetical
      reasons, the order looks different than normal, though its closer to the
      order in real live. But we all switched our brains already didn't we?..
      Stefan
      --
      Stefan Tiedje------------x-------
      --_____-----------|--------------
      --(_|_ ----|-----|-----()-------
      -- _|_)----|-----()--------------
      ----------()--------www.ccmix.com