Lists getting truncated by zl, despite setting higher limit

Feb 19, 2013 at 5:19pm

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

– Pasted Max Patch, click to expand. –
#66593
Feb 19, 2013 at 6:19pm

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. –
#239674
Feb 19, 2013 at 7:20pm

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

#239675
Feb 19, 2013 at 7:33pm

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?

#239676
Feb 19, 2013 at 7:35pm

[zl ]

– Pasted Max Patch, click to expand. –

`

#239677
Feb 19, 2013 at 10:01pm

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…

#239678
Feb 20, 2013 at 4:19pm

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

#239679
Feb 20, 2013 at 9:35pm

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?

#239680
Feb 21, 2013 at 2:51pm

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.

#239681
Feb 21, 2013 at 3:00pm

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

thanks ej

#239682

You must be logged in to reply to this topic.