Chris Muir

I don't understand why one of these cases doesn't work:

Chris Muir | "There are many futures and only one status quo.

cbm@well.com | This is why conservatives mostly agree,

 | and radicals always argue." - Brian Eno

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


line-question

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 

you could easily replace the comma by a '0' and achieve the same result.

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


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

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. 

Chris Muir  wrote: 
I don't understand why one of these cases doesn't work:

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


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…

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.

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.

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

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. 

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

sprintf is useful for formatting weird arrangements of letters, but it doesn't know anything about message delimiters and receivers. 


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.

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.

> 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 

Convenience can be confusing, if someone is in the state of learning...

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

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


At 8:35 AM +0100 12/20/07, Stefan Tiedje wrote:

>Convenience can be confusing, if someone is in the state of learning...

At 8:35 AM +0100 12/20/07, Stefan Tiedje wrote:
>Convenience can be confusing, if someone is in the state of learning...

> confused? or in the learning process? ;-)

Emmanuel Jourdan schrieb:
> confused? or in the learning process? ;-)

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.

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

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.

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

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.

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

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

line~ question