Lists getting truncated by zl, despite setting higher limit
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..
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!
Your assumption that one zl object sets the default list length globally is false. You need set each instance individually.
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?
[zl ]
`
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...
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 ;-)
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?
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.
ah, thanks. I was thinking along those lines, but couldn't figure out how to express it - too tired in the brain.
thanks ej