From svlp...@gmx.com on September 22, 2013 22:55:44
What steps will reproduce the problem? I have a error log produced by Win7. Is there any way of knowing which piece of code is responsible from these errors?
Faulting application name: reaper.exe, version: 126.96.36.199, time stamp: 0x52291d3c
Faulting module name: reaper_sws.dll, version: 188.8.131.52, time stamp: 0x5201c1b4
Exception code: 0xc0000417
Fault offset: 0x00180b7b
Faulting process id: 0x1624
Faulting application start time: 0x01ceb7d2027f68e3
Faulting application path: C:\Program Files\REAPER\reaper.exe
Faulting module path: C:\Program Files\REAPER\Plugins\reaper_sws.dll
Report Id: 98e80e14-23c6-11e3-abe2-1c6f65482dbb What is the expected output? What do you see instead? Crashes Reaper.
What version of SWS extension are you using?
What is your Reaper version number and CPU architecture
Reaper 4.52, x86
What operating system are you running?
Windows 7, 32 bit
Original issue: http://code.google.com/p/sws-extension/issues/detail?id=598
From svlp...@gmx.com on September 22, 2013 22:13:17
I found the problem. Can someone please close the issue/bug?
From jeffos...@gmail.com on September 23, 2013 00:34:58
hmm.. does not sound right to me..
how to reproduce this? what was the problem exactly ?
Thank you in advance!
From svlp...@gmx.com on September 23, 2013 14:58:11
The issues had arisen when we're enumerating a large list of user variables in a loop to write midi data to Reaper's midi editor, and then giving Reaper not enough time to open and close the midi take.
We've fixed this by opening a midi take before the loop runs and closing a midi take after the loop, instead of doing it inside a loop. Hope this makes sense?
From svlp...@gmx.com on September 23, 2013 15:32:01
Here is a more illustrated example in "pseudo code". We did something similar to this.
for a, b in enumerate(some_array):
for c, d in enumerate(another_array):
take = self.getActTakeInEditor()
midi = self.allocateMIDITake(take)
# do something to the midi take...
From jeffos...@gmail.com on September 30, 2013 11:10:48
Ok, thanks for the details! Will be fixed for the next release ( r1138 ).
Also, yes, your new code totally makes sense performance-wise but it does not solve the bug being disccused here (just lowers the probability it occurs...)