Acaro00

Now if I update, many of my patches are going to stop working in many points!!

I can't update or I will have to search for all the triggers with lists and recode them.

Is there any way to say Max that I don't want that behaviour??

Seriously, you can't change something like that from day to night, without backwards compatibility.

I work a looot with lists.
Now if I update, many of my patches are going to stop working in many points!!
I can't update or I will have to search for all the triggers with lists and recode them.

Is there any way to say Max that I don't want that behaviour??
Any option or something?

Seriously, you can't change something like that from day to night, without backwards compatibility.


trigger-no-longer-outputs-a-list-when-theres-only-one-numeric-item

Trigger does output a 1 numeric item list when using [t l], just tried that in 5.1.8. Or do I misunderstand something?

If anybody else can confirm that [t l] still outputs single numbers (lists of length 1) then I'm also missing something about this phrase:

"Trigger no longer outputs a list when there's only one numeric item."

If anybody else can confirm that [t l] still outputs single numbers (lists of length 1) then I'm also missing something about this phrase:
"Trigger no longer outputs a list when there's only one numeric item."


I've installed 5.1.8 and all seems fine:


Then, what does that phrase mean??? I don't get it.

Maybe it only means the file type is not a list anymore, so you can't do something like this anymore:

That patch works in 5.1.8 too-- probably best to wait for a response from c74...

Yep, let's see what they say.
Thanks for trying it.


Before this fix, if inputting a single integer to [trigger l], trigger would output a list containing one item. But, in Max, a one item list doesn't really mean anything, and is thus invalid.

This check-in now tells trigger to pass a single number out as a valid data type even when it is calling the list method. Thus, message '1'->[trigger l] will output an integer, 1. It does this because there is no use in passing out an invalid list.

In theory, a proper list is something which has 2 elements or more and whose first argument is a number (int/float). That's the what triggers a list method.

A side note for extra credit. Often people think that the message 'a 1 2 3' is a list, when in fact it is not. It is a symbol, 'a', with the arguments 1 2 3.

Thanks to EJ for refining my understanding of these concepts.

Before this fix, if inputting a single integer to [trigger l], trigger would output a list containing one item.  But, in Max, a one item list doesn't really mean anything, and is thus invalid.  

This check-in now tells trigger to pass a single number out as a valid data type even when it is calling the list method. Thus, message '1'->[trigger l] will output an integer, 1.  It does this because there is no use in passing out an invalid list.

A side note for extra credit.  Often people think that the message 'a 1 2 3' is a list, when in fact it is not.  It is a symbol, 'a', with the arguments 1 2 3.

It's true that a message cannot truly be a list unless it begins with a number; so "a 1 2 3" is not a list. It's also true that a number by itself, such as "1" is not a one-item list; it's an int (or a float if it contains a decimal point). So "1" is a synonym for "int 1" and "1." is a synonym for "float 1.". However, one actually can create a one-item list by explicitly saying "list 1" (or "list 1.", but not "list a").

I can't express enough how glad I am for that fix now. I waited many years for it. A single item list creates more problems than you could hack solutions with...

Thanks for the new behavior. I am sure the aforementioned broken patches are not in triggers, but in route. For the above problems I always hoped that the old buggy behavior would be fixed sooner or later, and had no single [route list] but always a route [list int (float)] in my patches. A single item list really does not make sense...

I can't express enough how glad I am for that fix now. I waited many years for it. A single item list creates more problems than you could hack solutions with... 

[t l] will not be able to output "7", because "7" is an int and not a list.

[t l] can output "7 8 9" or "7 years" or "list 7".

and the latter is how a list with only one number has to look like.

"list 7" will print with a leading space:

i´d recommend you get a copy of [printit] and work with that.

it once helped me a lot to understand message types and so to speak max.

"list 7" will print with a leading space:
 7

"Trigger does output a 1 numeric item list when using [t l], just tried that in 5.1.8. Or do I misunderstand something?"

if they really changed that i am totally against this.

changing the behavior of the trigger object will break patches

and i also do not understand some of what ben said.

changing the behavior of the trigger object will break patches
which contain "1" - [t l i].

and i also do not understand some of what ben said.


It is counter-intuitive (particularly to people used to LISP & Co.) that Max doesn't allow single element lists, nor is it possible to have a list beginning with a symbol.

This seems to be a deliberate decision made by Miller Puckette very early in the design process. It was an established convention--at the latest--by the time of the first commercial release of Max.

It is actually possible to generate either kind of list in a C-based external. But lots of objects get confused when they receive a non-standard list, and several objects will *convert* non-standard lists into more conventional message formats. I suppose the old behavior of trigger, to actually produce a single-element list, could be considered a bug.

@Acaro: can you give an example of a patch that you think will break on 5.1.8? I don't see anything that would behave differently with the example you posted previously.

Don't forget that, even though you could get trigger to produce the message "list 42" (ie, a single-element list), many objects would implicitly convert that to the message "int 42" (ie, an integer).

It is actually possible to generate either kind of list in a C-based external. But lots of objects get confused when they receive a non-standard list, and several objects will *convert* non-standard lists into more conventional message formats. I suppose the old behavior of trigger, to actually produce a single-element list, could be considered a bug. 

Don't forget that, even though you could get trigger to produce the message "list 42" (ie, a single-element list), many objects would implicitly convert that to the message "int 42" (ie, an integer).


" It is counter-intuitive (particularly to people used to LISP & Co.) that Max doesn't allow single element lists, nor is it possible to have a list beginning with a symbol. "

...well, it is lucky that max is not made for people used to lisp & co but for people used to max...

Max was ostensibly made for people who weren't used to *anything*. It's hard to convince people to start using Max if a prerequisite is to be an expert in Max before you can start using Max.

The fact is, however, Max uses a lot of conventions borrowed from C. My experience with teaching is that for a lot of novices, getting used to &&, ||, %, <

Having lists with a single item is not just from LISP. As an example, consider the shopping list engendered in the following conversation:

"Honey, pick up some milk on your way home from work!"

Max was ostensibly made for people who weren't used to *anything*. It's hard to convince people to start using Max if a prerequisite is to be an expert in Max before you can start using Max. 

Different types of data are sometimes not very intuitive in Max, but I am ok with that.

I just installed printit and I will try to learn more about different kinds of data.

@PeterCastine I thought the [t l] would output nothing when receiving a message containing "1" or "list 1" for example. But it seems it will output "list 1" or at least "int 1" right? If it does that I suppose none of my patch will break.

sorry for hijack... no, i am very happy with my unrestrained lack of resistance, thanks. in fact i enjoy reading mr castine posts, always a little more when they are a bit fiery, and reasonably easy to get going (what i couldn't resist). but, a more serious point: i do not believe "My experience with teaching is that for a lot of novices...". the definition of 'novice' is important here. sure, if people who are new to max but from a proficient maths/logic/real-programming-environment background have problems grasping a few things, then this is understandable. because max is not a real programming environment, and certain things about it will infuriate the pre-initiated. this can be seen on this forum, where quite a few posts (some examples very recently) from those new but used to other environments completely miss some of the basic max logic. reading some mr puckette's (now old) writings on the subject confirm the resistence of programmers to the whole concept of max. in fact hardcore professional programmers i know laugh at the paradigm. on the other hand, those from a purely abstract musical background (divisions of time, harmony, improvisation, etc) like i was, and those with the likes of dyscalc/lexi/a etc, max is fantastic and easy to grasp, empowering creativity with technology. when i started out from the computer-sewer, i just accepted absolutely anything max did as the way it was to be. of course since then max has taught me C, which years ago i could not have dreamed of. max educates. of course i know i am talking about two extremes, but hell, for the sake of comment/argument etc. any thoughts? i guess that was all a long winded way of saying that i can totally forgive any max logic foibles.

Once more for the cheap seats? (namely me?)

So in 5.1.8, if I'm using [t l] in a patch and I send it in a single integer, it will send out a single number as an INT (whereas before it was a LIST)?

So basically what you are saying is that if [t l] if you were treating a single number coming out of [t l] as an INT or FLOAT anyways, you are fine.

What if you were running a [t l] to a zl object with a varying sized list (1-n elements) and it outputs a single INT or FLOAT to the zl object? Does this cause an error?

What if you were running a [t l] to a zl object with a varying sized list (1-n elements) and it outputs a single INT or FLOAT to the zl object?  Does this cause an error?


 understands ints and floats. The problem was that in the previous version a list of one item was send and as Peter pointed out there's no such thing as list of one item in Max. A list is a group of two or more "things" whose start with a number. For instance, in version prior to 5.1.8 the patch bellow wouldn't work, because 

 would receive a list of 1 item (and the list message requires at least 2 values, target and destination time), now that trigger outputs valid message the int/float is sent out the outlet which cause 

Hope this clarify a bit this obscure improvement ;-)

No, because zl understands ints and floats. The problem was that in the previous version a list of one item was send and as Peter pointed out there's no such thing as list of one item in Max. A list is a group of two or more "things" whose start with a number. For instance, in version prior to 5.1.8 the patch bellow wouldn't work, because line~ would receive a list of 1 item (and the list message requires at least 2 values, target and destination time), now that trigger outputs valid message the int/float is sent out the outlet which cause line~'s int/float method to be called.

Hope this clarify a bit this obscure improvement ;-)


Awesome, I think I understand. Really appreciate your patience explaining it! Time to upgrade, so happy the direct to window fix was applied in 5.1.8!!

Awesome, I think I understand.  Really appreciate your patience explaining it!  Time to upgrade, so happy the direct to window fix was applied in 5.1.8!!
