DSP Robotics Support

Okay, thanks.

I'm generally thinking to revisit my preset system, because while it operates at certain accuracy (I had to limit it from 0.001 to 0.01), it also operates within wide spectrum (+/-16000), which lowers the linear precision of saved values. From time to time I'm moving back to ideas how to make it right (although wavetable driven single-cycle oscillators produce few sample differences anyway, so no "perfect loops" possible, even for 100 seconds distances at 0.01Hz accuracy).

Yes, I was right about the rounding in preset files. Values get rounded to 6 decimal places. So I have to use this 32bit to 2x 16bit converter to maintain full precision. I got inspired by trog - he came up with a way, to transmit 32bit address of green float array form ruby to assembly primitive (as two 16bit integers). It was effectively memin/memout type of thing. However it was very unstable when loading the schematic. You had to summon a legion of demons with satan himself to stabilize it... (I mean, I have only one schematic that is stable with it and about a dozen that need special procedure to even load... and even have some that are completely non-loadable and crash every time because of it).

When having unstable schematics, I usually try to compensate with proper order of sample&holds, trigger order step-by-step routines and timer based delays. Sometimes, when streams are recompiled on-the-fly according to green data changes - they simply end up in unambiguous or overload situations, and thus - crash. I would try it. Allow the schematic to load, and then - activate other procedures. Otherwise - no way to know what is loaded first.

tester wrote:When having unstable schematics, I usually try to compensate with proper order of sample&holds, trigger order step-by-step routines and timer based delays. Sometimes, when streams are recompiled on-the-fly according to green data changes - they simply end up in unambiguous or overload situations, and thus - crash. I would try it. Allow the schematic to load, and then - activate other procedures. Otherwise - no way to know what is loaded first.

exactly... the problem probably was, that the stream code of assembler was executed before the address reached it through green. result was, that schematic tried to load/write values to address [0] and code crashed. It actually give me an inspiration for ultimate crash code, that crashes the schematic/plugin/application when trigger is received... check it out in examples section...

I wonder if using FS app - it's possible to crash the system too.

tester wrote:I wonder if using FS app - it's possible to crash the system too.

I believe it is... I've bluescreened several times so far ... (I can't remember the exact recipe though )