vichug

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

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


is-there-a-better-way-to-do-this-coll-related

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

You can keep track of the index numbers yourself with a counter.

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?

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?


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

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

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.

>if there was a little [append] message built-in

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

ah oh yeah, sorry. I must have misremembered. And hehe oh man is it strangely documented "see above"...? wtf, hehe.

This variant of Christopher's patch continues counting after close and reopen.

@Wetterberg : indeed :p
@broc : this is cleaner/easier indeed


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