I parse a list of length 62 and do many operations on it. I'm not sure 

i'm doing it wrong but parsed data often messes up, mixing parts that 

should be associated with others and so on.

I'll surely post a patch here as soon as someone from the lab sends me 

the logs we could use to reproduce the problem.

Is it possible that Max find itself overflowed with too much realtime 

incoming data to parse and then, loose track of what goes with what (i.e 

: store a list in [zl reg], test a few conditions then bang the list out 

of the [zl reg]) ? If not, then i'm sure i've done something wrong...

f.e chanfrault | aka | personal computer music

>>>>>>> |sublime music for a desperate people|

I parse a list of length 62 and do many operations on it. I'm not sure 
i'm doing it wrong but parsed data often messes up, mixing parts that 
should be associated with others and so on.

I'll surely post a patch here as soon as someone from the lab sends me 
the logs we could use to reproduce the problem.

Is it possible that Max find itself overflowed with too much realtime 
incoming data to parse and then, loose track of what goes with what (i.e 
: store a list in [zl reg], test a few conditions then bang the list out 
of the [zl reg]) ? If not, then i'm sure i've done something wrong...

-- 
f.e chanfrault | aka | personal computer music
 >>>>>>> http://www.personal-computer-music.com
 >>>>>>> |sublime music for a desperate people|


question-about-data-flow-in-max

Well i have focussed a lot at lists and its uses.

Not have seen your patch i can't but make two suggestions to improve.

1    try using jit.matrices, because you can process data faster (using 

2    use a header with a in front of each FIXED length list of 

data you use, the result is that you can cleanly process the 

different data when you use [route ] to process a specific strain.

> I parse a list of length 62 and do many operations on it. I'm not 

> sure i'm doing it wrong but parsed data often messes up, mixing 

> parts that should be associated with others and so on.

> I'll surely post a patch here as soon as someone from the lab sends 

> me the logs we could use to reproduce the problem.

> Is it possible that Max find itself overflowed with too much 

> realtime incoming data to parse and then, loose track of what goes 

> with what (i.e : store a list in [zl reg], test a few conditions 

> then bang the list out of the [zl reg]) ? If not, then i'm sure 

> f.e chanfrault | aka | personal computer music

> >>>>>>> |sublime music for a desperate people|

Well i have focussed a lot at lists and its uses.
Not have seen your patch i can't but make two suggestions to improve.
1	try using jit.matrices, because you can process data faster (using  
jit.op or jit.expr)
2	use a header with a  in front of each FIXED length list of  
data you use, the result is that you can cleanly process the  
different data when you use [route ] to process a specific strain.

> Hello,
>
> I parse a list of length 62 and do many operations on it. I'm not  
> sure i'm doing it wrong but parsed data often messes up, mixing  
> parts that should be associated with others and so on.
>
> I'll surely post a patch here as soon as someone from the lab sends  
> me the logs we could use to reproduce the problem.
>
> Extensive use of [zl stuff] involved.
>
> Is it possible that Max find itself overflowed with too much  
> realtime incoming data to parse and then, loose track of what goes  
> with what (i.e : store a list in [zl reg], test a few conditions  
> then bang the list out of the [zl reg]) ? If not, then i'm sure  
> i've done something wrong...
>
> f.e
>
>
>
> -- 
> f.e chanfrault | aka | personal computer music
> >>>>>>> http://www.personal-computer-music.com
> >>>>>>> |sublime music for a desperate people|
>


> Extensive use of [zl stuff] involved.
>
> Is it possible that Max find itself overflowed with too much  
> realtime incoming data to parse and then, loose track of what goes  
> with what (i.e : store a list in [zl reg], test a few conditions  
> then bang the list out of the [zl reg]) ? If not, then i'm sure  
> i've done something wrong...

> If not, then i'm sure i've done something wrong...

I probably could savely bet an upgrade to Max 5 that it has to do with 

the correct ordering of your data flow... left to right, down to up. 

Max is pretty reliable in this regard, though there are declared "don't 

know the order" cases like sending messages across sub patchers with 

The other problem which can arise is feedback. You think the order is 

the way you think, but it will first push it on the stack, and that way 

the order is reversed. Check it with a deferlow in the feedback path, 

this will put it back into the order you think...

f.e schrieb:
> If not, then i'm sure i've done something wrong...

I probably could savely bet an upgrade to Max 5 that it has to do with 
the correct ordering of your data flow... left to right, down to up. 
Move it a pixel and all changes...

Max is pretty reliable in this regard, though there are declared "don't 
know the order" cases like sending messages across sub patchers with 
send/receive...

The other problem which can arise is feedback. You think the order is 
the way you think, but it will first push it on the stack, and that way 
the order is reversed. Check it with a deferlow in the feedback path, 
this will put it back into the order you think...

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

question about data flow in Max