good question. and yes, if the '1 or 2 blocks dropped' i get are from the resizing process, they should be happening just before the start of every file. get text, send to load [readsf~], remove and resize.
i've got a 200ms or more delay on the [open(, so the resizing should be happening during that preload time, which is indeed silent.
the mode switches are a bigger concern - they happen when i hit the last remaining line of text and ask to reload the original txt file.
i really should double check whether or not they are happening in that same silent space (at what point the reloads are called exactly in the patch.)
the thing is i still need to combine this with sending OSC messages to drive my display, so the whole patch is not going to get any lighter on CPU. just trying to avoid possible problems, i guess.
i'm now thinking of trying this:
i'm hoping that loading an array sequentially with a 0-136 uzi-like counter instead of loading a txt file into ram is less heavy. that would replace loading the txt file.
i could then:
- get value from random index,
- use value to reference my txt (which wouldn't have to be resized anymore) to load [readsf~],
- set value to, say, -1 to mark as 'used'.
next button press asks for new random value. if the output is -1, ask for new random index. this would avoid having to resize the array as well.
this would mean that the later an index gets called, the more i would have to bang [random] to hunt it down, but at least on the laptop that went unnoticably fast. and since this would happen before the loading of [readsf~], it should be spiking in silence, if it spikes at all.