Derek Franz

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,

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,

the-256-glass-ceiing

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 

> 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
>
> www.vcnet.com/~franz/max

Or perhaps a global variable that can be used to set the maximum size

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,

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
>
> www.vcnet.com/~franz/max 
>
>

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

> 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 

> 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
>>
>> www.vcnet.com/~franz/max
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>


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.

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

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

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
> >>
> >> www.vcnet.com/~franz/max
> >
> > v a d e //
> >
> > www.vade.info
> > abstrakt.vade.info
> >
> >
> >
>
>
>
>
----------------------------------------------------


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 

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 

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

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

http://arts.ucsc.edu/EMS/Music/index.html

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
>>>>
>>>> www.vcnet.com/~franz/max
>>>
>>> v a d e //
>>>
>>> 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/


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

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

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

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

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.

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

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

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 

> 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 

> 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 

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

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

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

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.

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
>>>>>
>>>>> www.vcnet.com/~franz/max
>>>>
>>>> v a d e //
>>>>
>>>> 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/
>
>


> 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

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. 

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

jitter is for the more abstract list handling, and for that its better 

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

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Quote: Stefan Tiedje wrote on Fri, 26 October 2007 01:15

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

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

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

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.

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

> Quote: Stefan Tiedje wrote on Fri, 26 October 2007 01:15

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

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

> 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

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

> 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

the 256 glass ceiing