Forums > MaxMSP

the 256 glass ceiing

October 15, 2007 | 4:36 am

hey I have trouble like many others with the 256 ceiling that most list
objects are limited to. repackaging data to meet the 256 ceiling inherent to
zl and iter type object becomes a programing project in itself and stutters
broad attempts at geometric analysis, will max five seek a higher thresh
hold for the standard of data packaging like 1024 or 65355,

derek

http://www.vcnet.com/~franz/max


October 15, 2007 | 4:59 am

iirc, you can use the java list objects to go further than 256

On Oct 15, 2007, at 12:36 AM, Derek Franz wrote:

> hey I have trouble like many others with the 256 ceiling that most
> list objects are limited to. repackaging data to meet the 256
> ceiling inherent to zl and iter type object becomes a programing
> project in itself and stutters broad attempts at geometric
> analysis, will max five seek a higher thresh hold for the standard
> of data packaging like 1024 or 65355,
>
>
> derek
>
> http://www.vcnet.com/~franz/max

v a d e //

http://www.vade.info
abstrakt.vade.info


October 15, 2007 | 11:24 am

Or perhaps a global variable that can be used to set the maximum size
according to user preference?

On 10/15/07 12:36 AM, "Derek Franz" wrote:

> hey I have trouble like many others with the 256 ceiling that most list
> objects are limited to. repackaging data to meet the 256 ceiling inherent to
> zl and iter type object becomes a programing project in itself and stutters
> broad attempts at geometric analysis, will max five seek a higher thresh hold
> for the standard of data packaging like 1024 or 65355,
>
>
> derek
>
> http://www.vcnet.com/~franz/max < http://www.vcnet.com/~franz/max>
>
>

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


October 15, 2007 | 8:33 pm

can you elaborate on that?

On Oct 15, 2007, at 6:59 AM, vade wrote:

> iirc, you can use the java list objects to go further than 256
>
> On Oct 15, 2007, at 12:36 AM, Derek Franz wrote:
>
>> hey I have trouble like many others with the 256 ceiling that most
>> list objects are limited to. repackaging data to meet the 256
>> ceiling inherent to zl and iter type object becomes a programing
>> project in itself and stutters broad attempts at geometric
>> analysis, will max five seek a higher thresh hold for the standard
>> of data packaging like 1024 or 65355,
>>
>>
>> derek
>>
>> http://www.vcnet.com/~franz/max
>
> v a d e //
>
> http://www.vade.info
> abstrakt.vade.info
>
>
>



PQE
October 15, 2007 | 9:39 pm

Hey, it used to be 64. The problem was, when a Mac held a Meg of memory that seemed to be a good limit, since each object that deals with lists actually has three or four data buffers the size of a list. The limit was increased to 256 (occasionally 255) at version 3 I believe. Since then, numerous proposals to go bigger have been met with stony silence from Cycling central. I’m certainly not looking forward to recompliling 120 Lobjects. (It’s not hard, it’s just a DEFINE statement- but that’s 120, twice!).

But as soon as a longer size was agreed on, there would be a proposal to increase it again. and again. The list mechanism is just a handy way to work with realtively small chunks of data. The objects mostly use for() loops with no optimization. If you need a bigger playing field, there are more efficient ways, such as java or jitter.
pqe

> > On Oct 15, 2007, at 12:36 AM, Derek Franz wrote:
> >
> >> hey I have trouble like many others with the 256 ceiling that most
> >> list objects are limited to. repackaging data to meet the 256
> >> ceiling inherent to zl and iter type object becomes a programing
> >> project in itself and stutters broad attempts at geometric
> >> analysis, will max five seek a higher thresh hold for the standard
> >> of data packaging like 1024 or 65355,
> >>
> >>
> >> derek
> >>
> >> http://www.vcnet.com/~franz/max
> >
> > v a d e //
> >
> > http://www.vade.info
> > abstrakt.vade.info
> >
> >
> >
>
>
>
>
—————————————————-


October 15, 2007 | 10:32 pm

well, i can relate to that, but if they’re wiling to piss people off
with the new look, they might as well give another limit. ; )
incidentally, i think the people most pissed off with the look would
be the ones who want this most.
but seriously, i don’t know about you guys, but i run into this
problem way too often and if you tell this to a traditional
programmer, they generally start laughing at you…

> I’m certainly not looking forward to recompliling 120 Lobjects.
> (It’s not hard, it’s just a DEFINE statement- but that’s 120, twice!).
well, they fit just in a list, you’re lucky ; )
>
> But as soon as a longer size was agreed on, there would be a
> proposal to increase it again. and again. The list mechanism is
> just a handy way to work with realtively small chunks of data. The
> objects mostly use for() loops with no optimization. If you need a
> bigger playing field, there are more efficient ways, such as java
> or jitter.
> pqe
>
>>> On Oct 15, 2007, at 12:36 AM, Derek Franz wrote:
>>>
>>>> hey I have trouble like many others with the 256 ceiling that most
>>>> list objects are limited to. repackaging data to meet the 256
>>>> ceiling inherent to zl and iter type object becomes a programing
>>>> project in itself and stutters broad attempts at geometric
>>>> analysis, will max five seek a higher thresh hold for the standard
>>>> of data packaging like 1024 or 65355,
>>>>
>>>>
>>>> derek
>>>>
>>>> http://www.vcnet.com/~franz/max
>>>
>>> v a d e //
>>>
>>> http://www.vade.info
>>> abstrakt.vade.info
>>>
>>>
>>>
>>
>>
>>
>>
> —————————————————-
>
>
> –
> Peter Elsea
> Director, Electronic Music Studios
> University of California, Santa Cruz
> http://arts.ucsc.edu/EMS/Music/index.html
> elsea@ucsc.edu
> get the Lobjects and Maxtutors at ftp://arts.ucsc.edu/pub/ems/


October 15, 2007 | 10:38 pm

I was doing some jit.fill to jit.spill trying to contain the lists I got ,
seems that float 32 and 64 doesn’t handle negative numbers less than -9? or
at least jit.cellblock wont view them, so I was doing some – 1000 +1000
offseting before and after going into the matrix, Im a big fan of uzi and
dump comMands they are just so crisp and kelvin kinda immediately freeze the
comuter until everything is done on the highest thread. Ive done some
jitter matrix access optimizations like runnng from sub matrixes at a time
so that the whole matrix doesn’t clogg up the data flow banging a 40 x 5000
just for one of those fortys, its better to sni the biggy into some smallies
like 40×300 and run form those the individual lines….its would be cool to
just run the permutaitons and get the intrinsic speed envelop of max for how
many times something big should be turned into something smaller to get the
smallest out at the biggest speed..ha

Ej seems to have compiled some java objects for lists. is there anyone else
thats run the gamut and made some fatty chunk java clones of the original
great ideas from elsea and lyon


October 15, 2007 | 10:46 pm

Quote: Gary Lee Nelson wrote on Mon, 15 October 2007 04:24
—————————————————-
> Or perhaps a global variable that can be used to set the maximum size
> according to user preference?
>
>

Yes! Please!!!

I understand the practical reasons for limiting the memory usage, and was thinking about a reasonable way to make everyone happy. Why not just make it a global setting, just like the MSP vector size? *I* should be able to specify how much memory Max is going to use on *my* computer, because I am the only one who knows how much load my machine can handle. Don’t impose artificial limits based on what common machines could do when the the *.0 version was released. It’ll just become obsolete and annoying to a lot of people again.

-Adam


October 16, 2007 | 12:40 am

On 16 oct. 07, at 07:38, Derek Franz wrote:

> Ej seems to have compiled some java objects for lists. is there
> anyone else thats run the gamut and made some fatty chunk java
> clones of the original great ideas from elsea and lyon

Don’t forget that there’s also a collection of list objects included
since Max 4.5 as java examples: [mxj list.*]. It’s pretty
straightforward to modify them and add new features if you need.

ej


October 16, 2007 | 5:58 am

If you use lists and list operations a lot, and regularly hit into
problems due to the 256 limit, I would suggest that you take a close
look at FTM.

Best,
Trond

isjtar wrote:
> well, i can relate to that, but if they’re wiling to piss people off
> with the new look, they might as well give another limit. ; )
> incidentally, i think the people most pissed off with the look would be
> the ones who want this most.
> but seriously, i don’t know about you guys, but i run into this problem
> way too often and if you tell this to a traditional programmer, they
> generally start laughing at you…
>
>> I’m certainly not looking forward to recompliling 120 Lobjects. (It’s
>> not hard, it’s just a DEFINE statement- but that’s 120, twice!).
> well, they fit just in a list, you’re lucky ; )
>>
>> But as soon as a longer size was agreed on, there would be a proposal
>> to increase it again. and again. The list mechanism is just a handy
>> way to work with realtively small chunks of data. The objects mostly
>> use for() loops with no optimization. If you need a bigger playing
>> field, there are more efficient ways, such as java or jitter.
>> pqe
>>
>>>> On Oct 15, 2007, at 12:36 AM, Derek Franz wrote:
>>>>
>>>>> hey I have trouble like many others with the 256 ceiling that most
>>>>> list objects are limited to. repackaging data to meet the 256
>>>>> ceiling inherent to zl and iter type object becomes a programing
>>>>> project in itself and stutters broad attempts at geometric
>>>>> analysis, will max five seek a higher thresh hold for the standard
>>>>> of data packaging like 1024 or 65355,
>>>>>
>>>>>
>>>>> derek
>>>>>
>>>>> http://www.vcnet.com/~franz/max
>>>>
>>>> v a d e //
>>>>
>>>> http://www.vade.info
>>>> abstrakt.vade.info
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>> —————————————————-
>>
>>
>> —
>> Peter Elsea
>> Director, Electronic Music Studios
>> University of California, Santa Cruz
>> http://arts.ucsc.edu/EMS/Music/index.html
>> elsea@ucsc.edu
>> get the Lobjects and Maxtutors at ftp://arts.ucsc.edu/pub/ems/
>
>


October 26, 2007 | 8:15 am

Adam Murray schrieb:
> Quote: Gary Lee Nelson wrote on Mon, 15 October 2007 04:24
> —————————————————-
>> Or perhaps a global variable that can be used to set the maximum
>> size according to user preference?
>
> Yes! Please!!!

No that is a very bad idea, a certain patch needs it or doesn’t. I would
want my patches to run on any Max installation…

I would look at it a different way. We can already circumvent the limit
in two ways: first and easiest, use the java classes with a limit of
4095. If you need more than that take the second way and use jitter.
Jitter doesn’t have any limit…

The existing limit is good for sizes one can deal with visually in a
message box…

jitter is for the more abstract list handling, and for that its better
suited as well…

I wouldn’t mind an extension to 8192 though, higher limits would burn my
human memory, not the memory of actual computers… ;-)
But then multislider has to be extended from 4095 to 8191 as well…

Stefan


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


October 28, 2007 | 6:53 pm

Quote: Stefan Tiedje wrote on Fri, 26 October 2007 01:15
—————————————————-
> Adam Murray schrieb:
> > Quote: Gary Lee Nelson wrote on Mon, 15 October 2007 04:24
> > —————————————————-
> >> Or perhaps a global variable that can be used to set the maximum
> >> size according to user preference?
> >
> > Yes! Please!!!
>
> No that is a very bad idea, a certain patch needs it or doesn’t. I would
> want my patches to run on any Max installation…
>

I disagree; this is a very a good idea and at the top of my list for features I would like to see in Max.

Why? Additive synthesis. If there are three (or four or five) data points per partial, then 256 elements is used very quickly. I deal with students, mostly, who don’t know Java and are unable to afford Jitter. While I’m comfortable telling a "Pro" to acquire the skills and software, it is very hard on a music student. And, even though we can do some things with the java classes provided with Max, the limitation comes back every time one uses an OEM external.

For backward compatibility, I would prefer having a limit set to 256 elements that the user could change (globally) if they wanted. In the nature of Max, this should be changeable programmatically — like overdrive, vector sizes, and everything else in Max.

Stefan: your patches already don’t run on every Max installation. If you are careful, you already have initialization routines that set scheduler and DSP modes. One more line to set the list length (if your programming somehow relies on this truncation) does not seem unreasonable.

While I normally don’t indulge in gratuitous feature requests, I’ll keep rolling and say I would also like to be able to change the default behavior from ints to floats. That is, if you put a lone mathematical operator in an object box, it would be nice if it assumed that the math would be in floats. I know that there are many times when an int is an int, but the number of bugs I see where someone inadvertently truncates a float is huge. Again, it would be important to be able to re-set this with a message box, for compatibility.

Perhaps this post is venting some feelings from other Max 5 related threads. It is obvious that people who don’t teach Max to others regularly are not always tuned in to the beginners experience. (Stefen, I am not referring to you anymore.) Even though I think Max is an excellent first programming language, there are a number of fussy elements that make it harder for beginners, especially those with less computer background, to pick up easily. I am very pleased to see a number of features in Max 5 that will make max easier to learn, use, and teach. It gets me down when the "maxigensia" shout down these features. because is doesn’t fit their ninja ideal.

Anyhow, that’s my 0.015 euros. Sorry to have taken up bandwidth with a rant.

best,

mz


October 28, 2007 | 7:06 pm

I don’t mean to be repetitive but the mxj list objects have met all of my
needs except the issues with coll that I outlined before. I have FTM but
have not gotten very far into it yet. Looks very promising with regard to
the list length problem.

The additive synthesis issue is real as is the SDIF problem. Not sure
anyone has tried LPC with Max but anything with lots of frame-based data is
going to be difficult.

On 10/28/07 2:54 PM, "mzed" wrote:

>
> Quote: Stefan Tiedje wrote on Fri, 26 October 2007 01:15
> —————————————————-
>> Adam Murray schrieb:
>>> Quote: Gary Lee Nelson wrote on Mon, 15 October 2007 04:24
>>> —————————————————-
>>>> Or perhaps a global variable that can be used to set the maximum
>>>> size according to user preference?
>>>
>>> Yes! Please!!!
>>
>> No that is a very bad idea, a certain patch needs it or doesn’t. I would
>> want my patches to run on any Max installation…
>>
>
> I disagree; this is a very a good idea and at the top of my list for features
> I would like to see in Max.
>
> Why? Additive synthesis. If there are three (or four or five) data points per
> partial, then 256 elements is used very quickly. I deal with students, mostly,
> who don’t know Java and are unable to afford Jitter. While I’m comfortable
> telling a "Pro" to acquire the skills and software, it is very hard on a music
> student. And, even though we can do some things with the java classes
> provided with Max, the limitation comes back every time one uses an OEM
> external.
>
> For backward compatibility, I would prefer having a limit set to 256 elements
> that the user could change (globally) if they wanted. In the nature of Max,
> this should be changeable programmatically — like overdrive, vector sizes,
> and everything else in Max.
>
> Stefan: your patches already don’t run on every Max installation. If you are
> careful, you already have initialization routines that set scheduler and DSP
> modes. One more line to set the list length (if your programming somehow
> relies on this truncation) does not seem unreasonable.
>
> While I normally don’t indulge in gratuitous feature requests, I’ll keep
> rolling and say I would also like to be able to change the default behavior
> from ints to floats. That is, if you put a lone mathematical operator in an
> object box, it would be nice if it assumed that the math would be in floats.
> I know that there are many times when an int is an int, but the number of bugs
> I see where someone inadvertently truncates a float is huge. Again, it would
> be important to be able to re-set this with a message box, for compatibility.
>
> Perhaps this post is venting some feelings from other Max 5 related threads.
> It is obvious that people who don’t teach Max to others regularly are not
> always tuned in to the beginners experience. (Stefen, I am not referring to
> you anymore.) Even though I think Max is an excellent first programming
> language, there are a number of fussy elements that make it harder for
> beginners, especially those with less computer background, to pick up easily.
> I am very pleased to see a number of features in Max 5 that will make max
> easier to learn, use, and teach. It gets me down when the "maxigensia" shout
> down these features. because is doesn’t fit their ninja ideal.
>
> Anyhow, that’s my 0.015 euros. Sorry to have taken up bandwidth with a rant.
>
> best,
>
> mz
>
>
>
>
> –
> || michael f. zbyszynski — molecular gastronimist
> || http://www.cnmat.berkeley.edu/
> || http://www.mikezed.com/
>
>
>

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


October 29, 2007 | 5:29 pm

BEGIN_WHISPER

Rumor in the salt mines is that Max 5 will end the 256 element
limitation for lists.

END_WHISPER

This is for the standard object set, and doesn’t speak for 3rd party
externals. However, utilities will be available for 3rd party
external developers to dynamically allocate large blocks of memory
for large atom lists, and keep the much faster performance of stack
allocated memory for smaller lists (which is the *real* reason that
there is a 256 element list limitation–i.e. fast stack memory usage
without using up all stack memory in a decent sized chain of objects).

-Joshua


October 30, 2007 | 9:53 am

>
> END_WHISPER
>

:)


October 30, 2007 | 7:16 pm

(which is the *real* reason that
> there is a 256 element list limitation–i.e. fast stack memory usage
> without using up all stack memory in a decent sized chain of objects).
>
> -Joshua
>
—————————————————-

oh! you mean you weren’t just arbitrarily imposing a limit on list size to piss everyone off? (smiley face)


October 31, 2007 | 5:22 pm

mzed schrieb:
> I disagree; this is a very a good idea and at the top of my list for
> features I would like to see in Max.

but if I set my limit to 512, und you set yours to 1024, your patches
won’t work on my computer. Now explain that to a user who’s patch
doesn’t work. You will force him to set it at least to 1024. But why not
8192 for all, there will never be a reason to decrease the limit…

> I deal with students, mostly, who don’t know Java and are unable to
> afford Jitter.

But you don’t have to know anything about Java to use the java based
externals… Its literally as easy as using zl…

> And, even though we can do some things with the java classes provided
> with Max, the limitation comes back every time one uses an OEM
> external.

That would also apply if the limit of Max 5 is raised to 8192. All OEMs
have to raise theirs as well… (The limit isn’t a limit of Max, its a
limit of the externals which deal with lists…)

> For backward compatibility, I would prefer having a limit set to 256
> elements that the user could change (globally) if they wanted.

I would never want to go back, a raised limit just can’t break old
patches…

> While I normally don’t indulge in gratuitous feature requests, I’ll
> keep rolling and say I would also like to be able to change the
> default behavior from ints to floats. That is, if you put a lone
> mathematical operator in an object box, it would be nice if it
> assumed that the math would be in floats.

But this definitely would break old patches. I can live with how it is.
The only way I can imagine to achive that is a way to define standard
parameters as soon you type into a message box, some kind of
autocompletion. Then you would autocomplete your operators just with 0. …

Stefan


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


October 31, 2007 | 8:32 pm

Another interesting situation where a 256 item list is not enough is happening down the hall from me. We have a speaker array with 120+ channels:

http://www.meyersound.com/news/2006/cnmat_project/

We’d like to control it with martix~, but 120*3>256. Using the java externals doesn’t help here.

mz


October 31, 2007 | 9:04 pm

Quote: Stefan Tiedje wrote on Wed, 31 October 2007 10:22
—————————————————-
>
> but if I set my limit to 512, und you set yours to 1024, your patches
> won’t work on my computer. Now explain that to a user who’s patch
> doesn’t work. You will force him to set it at least to 1024. But why not
> 8192 for all, there will never be a reason to decrease the limit…

So maybe the global preference is a bad idea, but what if it were a patch-specific and/or object-specific setting? What if we could send a message to the max object on loadbang to increase the size for the current patch, or go into the inspector for applicable objects and change the size there (not sure if the latter makes much sense).

As Joshua mentioned the current limit exists for performance, so I think ideally there would be an option to increase the size only when needed. That’s why I jumped on the "make it a global preference" bandwagon, but what I’m really after is having the option to decide when to make the tradeoff myself, instead of C74 saying, "No, no, in general this way is better for performance so you are stuck with it."

We’ll just have to wait and see what we get in Max 5.

-Adam


October 31, 2007 | 9:34 pm

Stop worrying.
You’re majorly overthinking this.

You don’t need any patch-specific or any object-specific list limit settings, or any You-set-yours, I-set-mine limits.
Not like that.

It’s up to extern developers to support however-many list entries they want. The 256-ceiling issue was about max’s builtin externs supporting 256.

Trust Cycling to have a general solution which requires no limit-setting like that.


October 31, 2007 | 9:59 pm

Quote: Zola wrote on Wed, 31 October 2007 14:34
—————————————————-
> Stop worrying.
> You’re majorly overthinking this.
>
> You don’t need any patch-specific or any object-specific list limit settings, or any You-set-yours, I-set-mine limits.
> Not like that.
>
> It’s up to extern developers to support however-many list entries they want. The 256-ceiling issue was about max’s builtin externs supporting 256.
>
> Trust Cycling to have a general solution which requires no limit-setting like that.
>
—————————————————-

Indeed.

What I was suggesting was something like
"; max listlength 1024", or something, which you could bang from your patch.

But, Joshua invoked the magical phrase "dynamically allocate," which is much better.

mz


October 31, 2007 | 10:06 pm

On Oct 31, 2007, at 2:34 PM, Zola wrote:

> Trust Cycling to have a general solution which requires no limit-
> setting like that.

Yes. The new strategy remains fast for small lists and dynamically
allocates memory for large lists. The utility functions we use will
also be available to 3rd party developers.

-Joshua


Viewing 22 posts - 1 through 22 (of 22 total)