DSP Robotics Support

My bad. I tried again and the 32bit version opened now just fine. I think when the 64bit version crashed the crash reporter was still active in the background, behind the main window and that's why was not allowing me to load the 32bit version properly. Now it loaded just fine. By the way, that crash reporter is not really reporting anything because it needs something. I think it was asking for an email program or something. In the end it didn't send any reports.

DSP-Robotron wrote:... By the way, that crash reporter is not really reporting anything because it needs something. I think it was asking for an email program or something. In the end it didn't send any reports.

It doesn't send anything because the embedded email address is incorrect. I told Malc about it ages ago.

This bug reporting email is not working either. (support@dsprobotics.com).
I sent these super buggy files to that email and they never received them.
Can you please check why is the ADSR silently overloading the CPU please ?
It's like all the voices are silently accumulating in the background until it reaches 86% CPU load or more.

The problem is the Ruby code. I’m not very good at Ruby but I can see that a midi event causes the midi to be switched to one of the midi outputs. This means each “synth” may get a note-on without the later corresponding note-off. This in turn means that poly channels stay open so the cpu accumulates as you play.

To fix this the Ruby code needs to be far more sophisticated and keep track of which notes are turned on and supply a note-off at some point for the currently playing notes. It can be done I think, but not by me I’m afraid.

Well since you know what's causing the overload... Can't we just gate it somehow ? That seems to be the problem then because even in my other files the notes were sustaining way past the ADSR levels. Even after I reduced the Sustain/Decay/Release the sounds were still accumulating. How do we contact the developers to tell them to fix that bug ? Because the Ruby module is not supposed to add any additional triggers.

I have a similar switcher that switches between 8 samples done in SynthEdit and it's using only 1% CPU. This thing is at least 10 times slower because of those sustaining bugs.

support@dsprobotics.com is not working. They have no support email at all.

Spogg wrote:The problem is the Ruby code. I’m not very good at Ruby but I can see that a midi event causes the midi to be switched to one of the midi outputs. This means each “synth” may get a note-on without the later corresponding note-off. This in turn means that poly channels stay open so the cpu accumulates as you play.

To fix this the Ruby code needs to be far more sophisticated and keep track of which notes are turned on and supply a note-off at some point for the currently playing notes. It can be done I think, but not by me I’m afraid.

Can't we just send note off signals to everything after every 8 notes or at the end of every ARP cycle ?
That should work I think. The bug must be in the arpeggiator code then.