is there a better way to do this ? [coll] related

    vichug
    Apr 14 2013 | 4:11 pm
    hello, i want to continuously record a stream of input data inside a [coll], with as few objects as possible. It gives that :
    Because i didn't find a message like (append) existing, which would add a received information at a new index increased from the last numerical index already existent, i first reorder the existing list from last to first element, then insert at first index (which is really the last index !) then redo the sort operation so that the last inserted element is now the first. I feel like there should be an easier way to do this, and that this is pretty mmuch a lot of operation... but maybe whatever ? anyway maybe i overlooked a message for coll that would be like (append) ?
    • Vjacobs
      Apr 14 2013 | 4:22 pm
      Hello,
      This way the index gets calculated separately and gets joined with the data to store. You see more objects, but I would suspect it takes less effort this way to append something when you arrive at record 10000+ then when you have to resort/reorder your whole list every iteration
      Hope it helps
    • Christopher Dobrian
      Apr 14 2013 | 4:25 pm
      You can keep track of the index numbers yourself with a counter.
    • parksa
      Apr 14 2013 | 5:26 pm
      you can do this with a single JS object give me more than 20 minutes to fool around with it and i will get back to you with some code :)
      i have some questions though: are you continually sampling data at a fixed rate or do you want your data to come in whenever you want it to? can you tell us more about what you have in mind for the bigger picture?
    • vichug
      Apr 14 2013 | 5:57 pm
      @Vjacobs and @Christopher : i'm sorta conscious that the correct way to do it involves a counter, but the problem is that if you want to continue the coll after closing and reopening the patch, you have to recall the index of last element registered, which is not very convenient (although completely doable - but i was looking for a more automated or clean sort of way...).
      @parksa : hah, i don't know a thing about js so maybe :) but then maybe it's simpler for me to do it with counter etc :p the bigger picture : it's like controlling something from the outside and recording each element as it arrives, so it's not timed at a fixed rate, and it's also to records a stream of incoming things (so quite instantaneous).
    • parksa
      Apr 14 2013 | 6:26 pm
      you can add the directory of your patcher to your path (options -> file preferences)
      then use 'read mycoll.txt' and 'write mycoll.txt' to retrieve the file
      the 'end' message followed by a bang will retrieve the index of the last element, which can be routed to the counter
    • vichug
      Apr 14 2013 | 9:08 pm
      hm... so, this thing here does what i want : those things were necessary to append whatever the index, using the "end" message, and allowing to begin the fill if there's nothing inside, and allowing to continue filling once the patch is closed then reopened... it seems a little overkill, if there was a little [append] message built-in, this would not be necessary.
      But there we are...
    • Wetterberg
      Apr 14 2013 | 9:26 pm
      >if there was a little [append] message built-in
      what, like "insert2 [yourmessage]"?
    • vichug
      Apr 14 2013 | 10:10 pm
      :D D: /./ ./ •/
    • vichug
      Apr 14 2013 | 10:12 pm
      er, here it does not do that, it takes the number you give him as the index. but insert2 is not well enough documented imho...
    • Wetterberg
      Apr 14 2013 | 10:17 pm
      ah oh yeah, sorry. I must have misremembered. And hehe oh man is it strangely documented "see above"...? wtf, hehe.
    • broc
      Apr 14 2013 | 11:16 pm
      This variant of Christopher's patch continues counting after close and reopen.
    • vichug
      Apr 14 2013 | 11:36 pm
      @Wetterberg : indeed :p @broc : this is cleaner/easier indeed