Lists getting truncated by zl, despite setting higher limit


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

    • Feb 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!
    • Feb 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.
    • Feb 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?
    • Feb 19 2013 | 7:35 pm
      [zl ]
      `
    • Feb 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...
    • Feb 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 ;-)
    • Feb 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?
    • Feb 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.
    • Feb 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