Forums > MaxMSP

Lists getting truncated by zl, despite setting higher limit

February 19, 2013 | 5:19 pm

Here’s the first (vital) operation in a modification I’m trying to add to a lighting sequencer. The on/off RGB states are stored in a matrix ctrl, which is stepped through using a metro.
I want to be able to quickly modify an existing matrixctrl by moving the existing on points either up, down, forwards or backwards. But I’m having a problem with the [zl group] that I’m using to gather the matrixctrl output into a single list. Despite setting the max zl list length to 1024 ( [zl 1024 group] ) and sending the output of the matrixctrl (64*3 * 3 items per point) to [zl group 576], I still can’t get a single list. What gives?

(The reason I want a single list is that I want to temporarily store the list in an Lbuf (LObjects – temporarily store list (tho" i don’t know if _that’lll cope with such a long list)), so that I can clear the matrixctrl before i modify the list and send it back to the matrixctrl.)

Here’s an illustration..

– Pasted Max Patch, click to expand. –

February 19, 2013 | 6:19 pm

Well, while i was waiting, I came up with an almost working solution using jitter. So far this only advances the on points, and it has a couple of faults which I haven’t figured out yet.

I’d still like to know what the deal is with list length limits with zl though!

– Pasted Max Patch, click to expand. –

February 19, 2013 | 7:20 pm

Your assumption that one zl object sets the default list length globally is false. You need set each instance individually.


February 19, 2013 | 7:33 pm

ok. I had another look at the help file , and IMO it could be read either way, but thanks for clearing that up.

That said, I’d already tried [zl group 756] [zl 1024 group 756] and (I think) [zl 756 group]. None seemed to work. Which one of the preceding _should it be?


February 19, 2013 | 7:35 pm

[zl ]

– Pasted Max Patch, click to expand. –

`


February 19, 2013 | 10:01 pm

Thanks for the help mzed…
I’ve finished up the jitter based version, which I think is actually the neatest way of handling large lists (the previous one I posted was actually broken).
I’ll post it in a separate thread, as it’s now working…


February 20, 2013 | 4:19 pm

Note that if you’re using Max 6 you can also use the syntax zl.group 1024 @zlmaxsize 1024 which I find more explicit/clear. YMMV ;-)


February 20, 2013 | 9:35 pm

OK. Interesting.

And the @zlmaxsize attribute applies only to that specific object. So my zl.group that’s supposed to spit out a list after 576 items would look like
this: [zl.group 576 @zlmaxsize 576] ? Wouldn’t it be simpler to have the first argument specify the max list size? After all, one generally knows how many items one is trying to group together, no? Am I being dense?


February 21, 2013 | 2:51 pm

The reason why they are decoupled is that you can have a zl.group which can store let’s say 1024 values (@zlmaxsize 1024) but sometimes group less values by changing the number of elements in the right inlet.


February 21, 2013 | 3:00 pm

ah, thanks. I was thinking along those lines, but couldn’t figure out how to express it – too tired in the brain.

thanks ej


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