max5pariah

Your 256-list limit is destroying all of my hopes and dreams.

My whole entire concept for Max at this time, and doing something great with it, is now impossible. I was really going to do something cool. God damnit. God damn this limitation. I hate it so bad. How can I be so dedicated to Max/Msp when it's utterly retarded about some of the most simple things? I ask myself this daily now. I'm not sure why my entire life of using audio software is characterized by this recurring extreme frustration and anger at the developers over their absurd limitations.

I've just coded for a month and in the end, my whole entire project is ruined by 256-list entry limitation.

This is the stupidest bullshitiest limit in max ever.

Your 256-list limit is destroying all of my hopes and dreams.
My whole entire concept for Max at this time, and doing something great with it, is now impossible. I was really going to do something cool. God damnit. God damn this limitation. I hate it so bad. How can I be so dedicated to Max/Msp when it's utterly retarded about some of the most simple things? I ask myself this daily now. I'm not sure why my entire life of using audio software is characterized by this recurring extreme frustration and anger at the developers over their absurd limitations.
I've just coded for a month and in the end, my whole entire project is ruined by 256-list entry limitation.
This is the stupidest bullshitiest limit in max ever.

Simply tell us YES, THE LIMIT IS GONE.
WITH MAX 5 THE LIMIT IS GONE.
Cycling, whisper in our ears!
Come on.

max-5-256-list-limit

:D that was a spot-on self-parody. :D well done.

i love the look of max 5 and the rounded corners, it looks modern and clean, and the new features are amazing. i don't want the stupid corner radius message.

i even love the 256 item limit on lists. been using max for 5 years now and have never needed more. indeed it frys the brain to try and deal with more.

News, entertainment and everything you care about at Live.com. Get it now!

i even love the 256 item limit on lists. been using max for 5 years now and have never needed more.  indeed it frys the brain to try and deal with more.

News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx


I assume you're unhappy with the several other options that will get

> Your 256-list limit is destroying all of my hopes and dreams.

> My whole entire concept for Max at this time, and doing something great with it, is now impossible. I was really going to do something cool. God damnit. God damn this limitation. I hate it so bad. How can I be so dedicated to Max/Msp when it's utterly retarded about some of the most simple things? I ask myself this daily now. I'm not sure why my entire life of using audio software is characterized by this recurring extreme frustration and anger at the developers over their absurd limitations.

> I've just coded for a month and in the end, my whole entire project is ruined by 256-list entry limitation.

> This is the stupidest bullshitiest limit in max ever.

I assume you're unhappy with the several other options that will get
you past that "limitation"?

On 10/27/07, Zola  wrote:
>
> Cycling,
>
> Your 256-list limit is destroying all of my hopes and dreams.
> My whole entire concept for Max at this time, and doing something great with it, is now impossible. I was really going to do something cool. God damnit. God damn this limitation. I hate it so bad. How can I be so dedicated to Max/Msp when it's utterly retarded about some of the most simple things? I ask myself this daily now. I'm not sure why my entire life of using audio software is characterized by this recurring extreme frustration and anger at the developers over their absurd limitations.
> I've just coded for a month and in the end, my whole entire project is ruined by 256-list entry limitation.
> This is the stupidest bullshitiest limit in max ever.
>
> COME ON DAMNIT
>
> Simply tell us YES, THE LIMIT IS GONE.
> WITH MAX 5 THE LIMIT IS GONE.
> Cycling, whisper in our ears!
> Come on.
>
> PEOPLE.
>


> i even love the 256 item limit on lists. been using max for 5 years now and have never needed more. indeed it frys the brain to try and deal with more.

Nobody is forcing you to use 1900 character symbols because it's possible. Do 1900 character symbols fry your brain too?

Keep your lists to 32 entries or whatever is comfortable for you.

> i even love the 256 item limit on lists. been using max for 5 years now and have never needed more.  indeed it frys the brain to try and deal with more.

It fries the brain huh?
So don't deal with more.
Leave that to me.
Nobody is forcing you to use 1900 character symbols because it's possible. Do 1900 character symbols fry your brain too?
Keep your lists to 32 entries or whatever is comfortable for you.
Don't impose it on others.

Il giorno 27/ott/07, alle ore 15:06, Zola ha scritto:

> My whole entire concept for Max at this time, and doing something 

> great with it, is now impossible. I was really going to do 

> something cool. God damnit. God damn this limitation. I hate it so 

> bad. How can I be so dedicated to Max/Msp when it's utterly 

> retarded about some of the most simple things? I ask myself this 

> daily now. I'm not sure why my entire life of using audio software 

> is characterized by this recurring extreme frustration and anger at 

> the developers over their absurd limitations.

> I've just coded for a month and in the end, my whole entire project 

> is ruined by 256-list entry limitation.

>
> Cycling,
>
> Your 256-list limit is destroying all of my hopes and dreams.
> My whole entire concept for Max at this time, and doing something  
> great with it, is now impossible. I was really going to do  
> something cool. God damnit. God damn this limitation. I hate it so  
> bad. How can I be so dedicated to Max/Msp when it's utterly  
> retarded about some of the most simple things? I ask myself this  
> daily now. I'm not sure why my entire life of using audio software  
> is characterized by this recurring extreme frustration and anger at  
> the developers over their absurd limitations.
> I've just coded for a month and in the end, my whole entire project  
> is ruined by 256-list entry limitation.
> This is the stupidest bullshitiest limit in max ever.
>
> COME ON DAMNIT
>
> Simply tell us YES, THE LIMIT IS GONE.
> WITH MAX 5 THE LIMIT IS GONE.
> Cycling, whisper in our ears!
> Come on.
>
> PEOPLE.

jitter makes it easy to deal with larger data groups. in fact, it 

On Oct 27, 2007, at 10:12 AM, Zola wrote:

>> i even love the 256 item limit on lists. been using max for 5 years 

>> now and have never needed more. indeed it frys the brain to try 

> Nobody is forcing you to use 1900 character symbols because it's 

> possible. Do 1900 character symbols fry your brain too?

> Keep your lists to 32 entries or whatever is comfortable for you.

jitter makes it easy to deal with larger data groups.  in fact, it  
makes it a joy.

>
>
>> i even love the 256 item limit on lists. been using max for 5 years  
>> now and have never needed more.  indeed it frys the brain to try  
>> and deal with more.
>
> It fries the brain huh?
> So don't deal with more.
> Leave that to me.
> Nobody is forcing you to use 1900 character symbols because it's  
> possible. Do 1900 character symbols fry your brain too?
> Keep your lists to 32 entries or whatever is comfortable for you.
> Don't impose it on others.
>
> - Zola
>


I don't understand this comment. Patches that work within the current limit

should continue to work if the max is increased. Shortening, however, would

On 10/27/07 10:27 AM, "pram cummings" wrote:

> find a smarter way of working - don't impose your requirements on us,

> increasing the list limit will break thousands of patcheas.

I don't understand this comment.  Patches that work within the current limit
should continue to work if the max is increased.  Shortening, however, would
cause problems.

On 10/27/07 10:27 AM, "pram cummings"  wrote:

> find a smarter way of working - don't impose your requirements on us,
> increasing the list limit will break thousands of patcheas.

Cheers
Gary Lee Nelson
Oberlin College
www.timara.oberlin.edu/GaryLeeNelson

On 27 oct. 07, at 16:46, Gary Lee Nelson wrote:

> I don't understand this comment. Patches that work within the 

> should continue to work if the max is increased. Shortening, 

> I don't understand this comment.  Patches that work within the  
> current limit
> should continue to work if the max is increased.  Shortening,  
> however, would
> cause problems.

> find a smarter way of working - don't impose your requirements on 

> us, increasing the list limit will break thousands of patcheas.

Not to add to the invective, but generally speaking,this shouldn't be 

that big of a problem. This is one of those "features" that 

shouldn't be depended on, especially with zl slice 256 as an easy 

solution. For any legacy patches that absolutely require lists with

Also, what kind of patches are counting on a list only having 256 

elements? Most of the times that I generate a list, I know the 

number of elements in it. Not that it never happens that I'm 

generating a list without concern for the number of elements, but it 

doesn't happen that often, and is very easy to fix.

Depending on the limitations of the environment to be fixed esp. with 

something like list length is lazy programming and asking for 

trouble. If you were building an audio program that worked with 

audio in integer format, you would set up variables that represent 

the minimum and maximum values available derived from the current 

sample rate rather than using "/ 32768." everywhere in your code. It 

makes it painless to switch from 16-bit processing to 24-bit 

processing. If you need a list to be smaller than a certain size you 

Good programming practices eliminate legacy code issues like this. 

I'd love to see the list limit raised, but given the third-party 

externals issues, it sounds like it may not happen soon...

> find a smarter way of working - don't impose your requirements on  
> us, increasing the list limit will break thousands of patcheas.

Not to add to the invective, but generally speaking,this shouldn't be  
that big of a problem.  This is one of those "features" that  
shouldn't be depended on, especially with zl slice 256 as an easy  
solution.  For any legacy patches that absolutely require lists with  

Also, what kind of patches are counting on a list only having 256  
elements?  Most of the times that I generate a list, I know the  
number of elements in it.  Not that it never happens that I'm  
generating a list without concern for the number of elements, but it  
doesn't happen that often, and is very easy to fix.

Depending on the limitations of the environment to be fixed esp. with  
something like list length is lazy programming and asking for  
trouble.  If you were building an audio program that worked with  
audio in integer format, you would set up variables that represent  
the minimum and maximum values available derived from the current  
sample rate rather than using "/ 32768." everywhere in your code.  It  
makes it painless to switch from 16-bit processing to 24-bit  
processing.  If you need a list to be smaller than a certain size you  
do it explicitly.

Good programming practices eliminate legacy code issues like this.   
I'd love to see the list limit raised, but given the third-party  
externals issues, it sounds like it may not happen soon...

I recommend the mxj list objects for larger arrays.

The only place that the limit really hurts me is in the coll object. Once

upon a time, coll source code was included in the max sdk. I compiled my

own version with a 1024 limit but haven't been able to do it again for UB.

The only place that the limit really hurts me is in the coll object.  Once
upon a time, coll source code was included in the max sdk.  I compiled my
own version with a 1024 limit but haven't been able to do it again for UB.

Quote: joshua goldberg wrote on Sat, 27 October 2007 08:20

----------------------------------------------------

> jitter makes it easy to deal with larger data groups. in fact, it 

removing if (argc > 127) argc = 127; from the anything method

But why are we regarding *Max* as some obsolete second-rate old-cousin, which should not be regarded with high standards anymore, and which you say "find smarter ways to work" about? What!? What about MAX? So Max isn't smart? When did that happen?

I fail to see how the existence of other possibilities should lower our standards for Max itself. Leave max limited forever because jitter wires exist? Is this really a good attitude for the future? Didn't we all already buy Jitter?

I have specific reasons for wanting max. For wanting the scheduler, the queues, the deferral, the whole banana-split. And my messages are specifically ~400 to ~700 elements, not 255.

Quote: joshua goldberg wrote on Sat, 27 October 2007 08:20
----------------------------------------------------
> jesus christ, man, give it a rest!
>
> jitter makes it easy to deal with larger data groups.  in fact, it  
> makes it a joy.

Yes, there's
mxj list.*
and there's
mxj ej.l*
and there's
removing if (argc > 127) argc = 127; from the anything method
and there's Jitter

I have specific reasons for wanting max. For wanting the scheduler, the queues, the deferral, the whole banana-split. And my messages are specifically ~400 to ~700 elements, not 255.


Quote: Gary Lee Nelson wrote on Sat, 27 October 2007 08:59

> I recommend the mxj list objects for larger arrays.

> The only place that the limit really hurts me is in the coll object. Once

In Max side of town, you have to build clean-room patches and your buddies can't use your common messaging protocol with any of their abstractions.

And you have to maintain two sets of ideas.

And color code your wires to make sure you dont accidentally flow a big one through a small one network.

Quote: Gary Lee Nelson wrote on Sat, 27 October 2007 08:59
----------------------------------------------------
> I recommend the mxj list objects for larger arrays.
>
> The only place that the limit really hurts me is in the coll object.  Once

In Max side of town, you have to build clean-room patches and your buddies can't use your common messaging protocol with any of their abstractions.
And you have to maintain two sets of ideas.
And color code your wires to make sure you dont accidentally flow a big one through a small one network.

If you are dealing with SDIF data or any other tracking data or coll 

objects, the limitation is a real pain. Particularly if you are 

importing external text files with arbitrary number of elements (say 

partial text-files from Spear). Why insist on it? Frankly I don't 

want to spend the rest of my life finding ways to deal with this 

limitation. It is stupid.. and makes max look childish compared with 

Maybe It is not efficient to have such large lists, but then max is 

supposed to be open ended and a decision of efficiency should be left 

to the user. Even with 256 element lists you could make a damn 

inefficient patch, so maybe only 4 element lists should be allowed!?

As for jitter, I cannot afford it or justify buying it. So is this 

limitation imposed as a way to make more money? I can only hope that 

max 5 will be different, or I will not even bother getting it.

On 27 Oct 2007, at 15:56, Peter McCulloch wrote:

>> find a smarter way of working - don't impose your requirements on 

>> us, increasing the list limit will break thousands of patcheas.

> Not to add to the invective, but generally speaking,this shouldn't 

> be that big of a problem. This is one of those "features" that 

> shouldn't be depended on, especially with zl slice 256 as an easy 

> solution. For any legacy patches that absolutely require lists 

> Also, what kind of patches are counting on a list only having 256 

> elements? Most of the times that I generate a list, I know the 

> number of elements in it. Not that it never happens that I'm 

> generating a list without concern for the number of elements, but 

> it doesn't happen that often, and is very easy to fix.

> Depending on the limitations of the environment to be fixed esp. 

> with something like list length is lazy programming and asking for 

> trouble. If you were building an audio program that worked with 

> audio in integer format, you would set up variables that represent 

> the minimum and maximum values available derived from the current 

> sample rate rather than using "/ 32768." everywhere in your code. 

> It makes it painless to switch from 16-bit processing to 24-bit 

> processing. If you need a list to be smaller than a certain size 

> Good programming practices eliminate legacy code issues like this. 

> I'd love to see the list limit raised, but given the third-party 

> externals issues, it sounds like it may not happen soon...

If you are dealing with SDIF data or any other tracking data or coll  
objects, the limitation is a real pain. Particularly if you are  
importing external text files with arbitrary number of elements (say  
partial text-files from Spear). Why insist on it? Frankly I don't  
want to spend the rest of my life finding ways to deal with this  
limitation. It is stupid.. and makes max look childish compared with  
supercollider or csound.

Maybe It is not efficient to have such large lists, but then max is  
supposed to be open ended and a decision of efficiency should be left  
to the user. Even with 256 element lists you could make a damn  
inefficient patch, so maybe only 4 element lists should be allowed!?

As for jitter, I cannot afford it or justify buying it. So is this  
limitation imposed as a way to make more money? I can only hope that  
max 5 will be different, or I will not even bother getting it.

>> find a smarter way of working - don't impose your requirements on  
>> us, increasing the list limit will break thousands of patcheas.
>
> Not to add to the invective, but generally speaking,this shouldn't  
> be that big of a problem.  This is one of those "features" that  
> shouldn't be depended on, especially with zl slice 256 as an easy  
> solution.  For any legacy patches that absolutely require lists  
> with
>
> Also, what kind of patches are counting on a list only having 256  
> elements?  Most of the times that I generate a list, I know the  
> number of elements in it.  Not that it never happens that I'm  
> generating a list without concern for the number of elements, but  
> it doesn't happen that often, and is very easy to fix.
>
> Depending on the limitations of the environment to be fixed esp.  
> with something like list length is lazy programming and asking for  
> trouble.  If you were building an audio program that worked with  
> audio in integer format, you would set up variables that represent  
> the minimum and maximum values available derived from the current  
> sample rate rather than using "/ 32768." everywhere in your code.   
> It makes it painless to switch from 16-bit processing to 24-bit  
> processing.  If you need a list to be smaller than a certain size  
> you do it explicitly.
>
> Good programming practices eliminate legacy code issues like this.   
> I'd love to see the list limit raised, but given the third-party  
> externals issues, it sounds like it may not happen soon...
>
> Peter McCulloch


In case you are afraid of line coding, have a look at ftm.

A bit hard to use but sometimes worth to try for complex data 

structures using with the control scheduler !!

In case you are afraid of line coding, have a look at ftm.
A bit hard to use but sometimes worth to try for complex data  
structures using with the control scheduler !!

Not to take any position on the list size thing, but if you're doing 

lots of SDIF work you should definitely look at FTM, which is free.

Not to take any position on the list size thing, but if you're doing 
lots of SDIF work you should definitely look at FTM, which is free.

Yeah I have looked at ftm. There just doesn't seem to be a 

documentation with all the available commands, etc... All the basic 

stuff I could find but when it gets complex the documentation 

evaporates (maybe I am wrong in which case any pointers will be 

For instance I was trying to work out how to read a text files with 

ftm (since lists are truncated in-between a text object in max and an 

ftm object!). But I couldn't find any answers. I am trying to avoid 

sdif as much as I can and stick to a humanly readable text file 

On 27 Oct 2007, at 16:47, Owen Green wrote:

> Not to take any position on the list size thing, but if you're 

> doing lots of SDIF work you should definitely look at FTM, which is 

Yeah I have looked at ftm. There just doesn't seem to be a  
documentation with all the available commands, etc... All the basic  
stuff I could find but when it gets complex the documentation  
evaporates (maybe I am wrong in which case any pointers will be  
appreciated).

For instance I was trying to work out how to read a text files with  
ftm (since lists are truncated in-between a text object in max and an  
ftm object!). But I couldn't find any answers. I am trying to avoid  
sdif as much as I can and stick to a humanly readable text file  
generated by spear.

> Hey Peiman,
>
> Not to take any position on the list size thing, but if you're  
> doing lots of SDIF work you should definitely look at FTM, which is  
> free.
>
> -- 
> O


it's just that your efforts at communicating your need are just so... 

obnoxious. you scream and shout about how the max5 interface is going 

to RUIN RUIN RUIN YOUR LIFE, without even knowing what it will feel 

like. and now your LIFE IS SOOOOO OVER because you don't get >256 

length list ops without using java or jitter.

but hey man, it's cool, i was a drama major too.

On Oct 27, 2007, at 11:09 AM, Zola wrote:

> Quote: joshua goldberg wrote on Sat, 27 October 2007 08:20

> ----------------------------------------------------

>> jitter makes it easy to deal with larger data groups. in fact, it

> removing if (argc > 127) argc = 127; from the anything method

> But why are we regarding *Max* as some obsolete second-rate old- 

> cousin, which should not be regarded with high standards anymore, 

> and which you say "find smarter ways to work" about? What!? What 

> about MAX? So Max isn't smart? When did that happen?

> I fail to see how the existence of other possibilities should lower 

> our standards for Max itself. Leave max limited forever because 

> jitter wires exist? Is this really a good attitude for the future? 

> I have specific reasons for wanting max. For wanting the scheduler, 

> the queues, the deferral, the whole banana-split. And my messages 

> are specifically ~400 to ~700 elements, not 255.

it's just that your efforts at communicating your need are just so...  
obnoxious.  you scream and shout about how the max5 interface is going  
to RUIN RUIN RUIN YOUR LIFE, without even knowing what it will feel  
like.  and now your LIFE IS SOOOOO OVER because you don't get >256  
length list ops without using java or jitter.

>
> Quote: joshua goldberg wrote on Sat, 27 October 2007 08:20
> ----------------------------------------------------
>> jesus christ, man, give it a rest!
>>
>> jitter makes it easy to deal with larger data groups.  in fact, it
>> makes it a joy.
>
>
> Yes, there's
> mxj list.*
> and there's
> mxj ej.l*
> and there's
> removing if (argc > 127) argc = 127; from the anything method
> and there's Jitter
>
> But why are we regarding *Max* as some obsolete second-rate old- 
> cousin, which should not be regarded with high standards anymore,  
> and which you say "find smarter ways to work" about? What!? What  
> about MAX? So Max isn't smart? When did that happen?
>
> I fail to see how the existence of other possibilities should lower  
> our standards for Max itself. Leave max limited forever because  
> jitter wires exist? Is this really a good attitude for the future?  
> Didn't we all already buy Jitter?
>
> I have specific reasons for wanting max. For wanting the scheduler,  
> the queues, the deferral, the whole banana-split. And my messages  
> are specifically ~400 to ~700 elements, not 255.
>
>


If you have to deal with 2 or 3 (robotic cases) universses you will need more than 512 channels, so more than 255 on a list is a very usefull thing.... and .... 

the ZX spectrum days was at long time ago!!!

If you have to deal with 2 or 3 (robotic cases) universses you will need more than 512 channels, so more than 255 on a list is a very usefull thing.... and .... 
the ZX spectrum days was at long time ago!!!

> Yeah I have looked at ftm. There just doesn't seem to be a documentation 

> with all the available commands, etc... All the basic stuff I could find 

> but when it gets complex the documentation evaporates (maybe I am wrong 

Max 5 >256 List Limit