list size limit?

    Nov 12 2009 | 1:26 pm
    I'm using coll and function to store the movements of a dial, to be played back via line - kind of like recording automation. My problem is that the list output by function does not contain all elements that are stored in both the function and the coll. It's quite easy for these to have 200 or more elements/points. Am I coming up against a list size limit? Patch attached below..
    Any suggestions on how to get around this would be great. I tried to use a gate in order to limit the frequency at which data is collected and stored (e.g. only every x milliseconds), however I still came across the same problem...
    Thanks in advance for your suggestions..

    • Nov 12 2009 | 6:29 pm
      I think it's a bug. Unless I'm missing something?
      It seems that the second outlet of [function] is limiting the list to 256 elements :
    • Nov 12 2009 | 11:40 pm
      Hi thanks for pointing that out, I was assuming it was limiting it somehow. Having re-read the line~ helpfile I would assume this would be due to line~'s maximum of accepting 128 value-time pairs in a list...
      I have checked out the ej.function.js as a replacement for function - and it doesn't seem to limit the size of the list - now I just need to find a way to get longer lists into line~ - any suggestions anyone??
    • Nov 13 2009 | 2:10 am
      Below is the patch in its revised version. I have used the ej.function.js object in replacement of the standard function as described above. As line~ only accepts lists of up to 256 elements, longer lists are sliced using zl and triggered one after the other to get around this problem. There will still be a limit at some point (there is currently only a maximum of 14 lists of 256 elements).. but I think that this provides the best workaround for the moment. Thanks again for the heads up on the list size limit of function.
      Any other suggestions are welcome... it's a shame that line~ has a limit to how many value-time pairs can be accepted in a single list.
    • Nov 18 2009 | 2:53 pm
      create some sustain points to split it up...
      But seriously, function is a user interface object with a lot of overhead to do all the fancy stuff you are able do by hand. Obviously with more than 128 points this isn't the case anyway. The limit in function does make sense, though its only the output, the object itself holds more than 128 points in your patch without problem even 600 points... There are a lot of ways to reconstruct the functionality of function. You could also connect a pattr to function and get a longer list of triples (time value mode) in this case... Here are some wildly hacked starting points:
    • Nov 20 2009 | 12:02 pm
      Hey thanks for the tips. I wasn't aware of the pattr object. This will be very useful for retrieving info from any object!! Your way of using the zl objects is much more efficient than how I'd had them set out so thanks for that...