bug? weird problem with [vexpr @scalarmode 1] and stack overflows
dear all,
i'm currently working on a tool for the monome and repeatedly encounter stack overflows while upscaling lists via [vexpr ... @sclarmode 1] to send these to the device. for those who don't know the monome: OSC data sent to it is not mirrored / output, so i can rule out that i am having a feedback-loop.
if i remove the vexpr object from the process (or replace it by itering, multiplying and then regrouping the lists), everything works fine. also everything appears to work if i [deferlow] the process.
any clue? is it possible that something's wrong with [vexpr] ?
Have a very similar problem with the [vexpr @scalarmode 1] "anomalously" running into stack overflow..
I get this issue as well, and not always in a monome-y context.
What seems to fix it is sticking a [defer] before the [vexpr], so I'm guessing this has to do with threading somewhere, where things in the high-priority scheduler can somehow overflow vexpr.
This isn't idea for time-sensitive things though.
What makes it tricky is that I can't seem to isolate a part of the patch that creates this problem, because if I strip bits away, it no longer overflows.