Magic/hidden Formula Device Causes Crash On Load

Help, Support & Bugs
1

As the Formula Device is “highly alpha” stage and as such unofficially supported (in fact it is stated that it is unstable and may cause crashes) I fully understand if these are looked at with the very lowest priority, or even not really at all… Even though thought it might be worth bring to the table some of the findings from playing with it in the last DDRC competition.

It appears it becomes very unstable when chaining devices together. Have found it hard to put a more defined explanation than that.

Attached you will find a zip with two files. The xrnt is a DSP Chain containing a number of Formula Devices, outputs going to one of the inputs of the next, and finally to a Ring Mod. The xrns is just a song, no samples or instruments, with the afore mentioned DSP Chain loaded into Track1.

The DSP Chain will nearly always load. It will work when you play, you can load a sample, play it in the track you have loaded it on and hear the effect. It will quite often crash on attempting to load the same chain into a second or third track though.

The Song will crash Renoise as soon as you try and open it.

One excerpt from my Crash Log:

[details=“Click to view contents”] Application: Loading ‘test.xrns’…

MIDI: Loading MIDI actions from file ‘C:\Program Files\Renoise 2.7.2\Scripts\GlobalMidiActions.lua’…

Osc: Loading OSC actions from file ‘C:\Program Files\Renoise 2.7.2\Scripts\GlobalOscActions.lua’…

Player: Constructing…
Player: Creating the slave threads…
Player: Start running…

GUI: Creating the Document GUI…

CrashLog: Handling Exception! Code : C0000005

GUI: Successfully constructed

CrashLog: 00B11EB7: xmlUCSIsCat +48ECD8
CrashLog: 00B1299C: xmlUCSIsCat +48F7BD
CrashLog: 00B12C85: xmlUCSIsCat +48FAA6
CrashLog: 00C01781: xmlUCSIsCat +57E5A2
CrashLog: 00401464: ??? +00000
CrashLog: 008FCADA: xmlUCSIsCat +2798FB
CrashLog: 00B129EE: xmlUCSIsCat +48F80F
CrashLog: 00B12BEF: xmlUCSIsCat +48FA10
CrashLog: 00926EB5: xmlUCSIsCat +2A3CD6
CrashLog: 0092CA23: xmlUCSIsCat +2A9844
CrashLog: 00C4ED23: xmlUCSIsCat +5CBB44
CrashLog: 00C4AC54: xmlUCSIsCat +5C7A75
CrashLog: 00C4AD86: xmlUCSIsCat +5C7BA7
CrashLog: 00B4E474: xmlUCSIsCat +4CB295
CrashLog: 7C80B713: GetModuleFileNameA +001B4

Threads: Timeout while waiting for Thread2 to finish its commands!!

Application: Successfully loaded ‘test.xrns’.
Application: Caught an unhandled exception (Thread: AUDIO)!
Application: Saving a backup…

Application: Terminating…

DirectSound: Stop Polling…

DirectSound: Timeout while waiting for DirectSound to shut down!!
DirectSound: Releasing Primary Sound Device…
DirectSound: Releasing Realtek HDA Primary input…

MIDI: Shut down: Closing all acquired MIDI devices…
MIDI: Shutting down DirectMusic…
[/details]

2

See http://www.renoise.com/board/index.php?/topic/31739-fixed-crash-trying-to-load-xrns-with-magichidden-formula-device/ please. Should already be fixed.

3

hmm, a fix for this means at least the Formula Device is not being neglected. good to know :slight_smile:

4

I’ve found a quick way to cause CPU overload with it.

You connect the formula device to itself, and select formula device for the destination device, then select the A, B or C param in the destination param. and simply put this :

 random ()

in the formula window.

Your CPU usage will simply increase more and more, untill you reach the threshold where renoise automatically stops.

Note that this behaviour does not happen when you connect the formula device to another device.

5

Feedback loop causes CPU overload is news to you?

6

yes and no. I know that in procedural coding languages, recursive function calls increase memory usage, and consequently when you code something like that, you have to find a way to willfully limit the number of recursive calls, what will avoid some problems (memory is filled with the same function, or slowdowns or frozen app.). I suppose that something similar happens here in the audio timeline that is “filled” with the random() function calls waiting in a queue. But I’m a bit surprise that the number / frequency of allowed recursive loops with the formula device has not been limited, for example ; you can also make tests with other achieved meta devices, link for example the hydra device to itself : the cpu overload won’t happen. take for example the send device : some limits have been introduced, sending a send to itself has not been allowed : probably for similar reasons.so feedback loops are not new to me, but what is new is to see this kind of problem in renoise… but i’m confident about the device because for now it is still in a very alpha phase and it will be probably improved in a next release.

7

The Formula Device isn’t officially released, once it is I’m sure these kind of limitations will be built into it like have been done for many of the other DSPs (where you can’t link backwards in the chain.)

8

Live and learn.

9

living and learning are things that every living creature naturally and spontaneously do.

10

Wow. Nobody can tell me I’m not natural or spontaneous anymore. Unless I have imperceptibly died, of course.