DSP Robotics Support

Check pic:
http://oi59.tinypic.com/2mm9ugj.jpg

I got an "out of memory" error while trying to connect the mono4 pack (towards the right) output to the subtraction primitive. The program froze shortly after. Tried again and same thing, only it threw an access violation error, then froze after.

http://oi58.tinypic.com/3479u8l.jpg

Did I do something really wrong? Or is this potentially a bug? The schematic is hardly massive so far.

Using version 3.0.4 in FL Studio by the way.

Why are you converting to poly? This is a valid thing to do in only a small number of cases the main use is for free running LFO in poly stream.

Does the filter code have "polyin" instead of "streamin"? Is that why you convert to poly so you can make a connection? If so change the polyins to streamin and get rid of all the poly stuff and you can connect the mono pack 4 connector directly to the filter (you will only need one filter then )

The image isn't meant to represent a functional schematic; I was in the middle of piecing things together when making that connection caused the program to fail.

The poly is for polyphony (I'm working with MIDI). Don't worry about it; I've since changed the design anyways. It was just very unexpected to have the program throw an error and then freeze just from connecting things up like that, and I wanted to know if there was something I was clearly doing wrong ("wrong" as in crash the program wrong). Still seems very odd to me.

The developer of Scirra Construct 2, a html5 game maker software, always claims: "If it crashes it is a bug." I think this is true for every software. It should never crash but have at least a proper error catching routine. You should report it together with a schematic that reproduces the crash.

The access violation error indicates that it tried to access a protected memory address, and ntdll.dll is a native application close to the kernel. There are so many possible reasons for a conflict with ntdll.dll that it doesn't make much sense for us to think about it (a wrong soundcard access is among them).

Yes the only time a crash is 'your fault' is when working in assembly and there is a error in your code.

Even if you have done 'something wrong' like wiring things up a way you shouldn't, then the software should catch that and deal with it so the program doesn't crash.

So if you can reproduce a crash with a test case always report it.

I see. Thanks guys.