PC > PC Installation

SoundShaper "Access Violation" Error When Using TEXTURE GROUP

(1/2) > >>

rotagrad:
Hello. I was studying the TEXTURE processes in SoundShaper recently and was enjoying the TEXTURE SIMPLE a lot. I decided to see the other TEXTURE processes, but they have been giving me an error that stops me from using them.

The error happens in SoundShaper specifically when using TEXTURE GROUP. When I place it for the first time in a session of SoundShaper, it works normally. However, if I try to use it again or edit the parameters of it, it shows the following

ACCESS VIOLATION AT ADDRESS 00406AE8 IN MODULE
'SoundShaper.exe'. READ OF ADDRESS 04FFFFF8.

It then does not allow me to change any parameters of TEXTURE GROUP. This error does not happen if I use the CDP Texture process through command line.

Would anyone know something similar to this having happened before? Is there any way of fixing it? I am currently using SoundShaper 5.0 in Windows 10.

I really wanted to explore the texture elements of CDP without having to use the cumbersome method of command lines. Any help is appreciated.

Robert Fraser:
Thanks for posting this bug. I've verified the problem you mention. I ran Grouped with a single input and the default values. Like you I got the access violation when I went to edit the parameters. I then cancelled and tried again; this time I got the edit boxes but the values were all 0. I also tried recalling a preset and again I got the violation.

Access violations can be quite tricky to track down, but usually occur from impossible values, like accessing a slider value beyond its declared range, for instance. I'll take a close look at the code here and see if I can track down anything sloppy in that regard. The re-setting of values to zero may give a clue. Grouped used to work OK, so I can also compare old code with the current version.

Robert - Author, Soundshaper.

rotagrad:
Hello, Robert.

Indeed, your description is exactly what I'm having at my end too. After trying to check thoroughly the Texture section, it seems grouped and decorate both show the same access violation issue. I believe I remember having seen this same bug with some other process in the Spectral section in the past as well, so I'll check them today again today, if that is of any help, and report back here later.

Robert Fraser:
I've tracked down where the A.V. occurs, but not why. It's something to do with the initial display of the parameter page when it's re-visited to edit the parameters. The weird thing is it doesn't do it every time -- but every OTHER time, consistently.

However, this gives a workaround: click CANCEL to leave the parameter page and try again (double-click the cell again). This seems to work. A third edit will give another A.V. but the 4th should be OK and so on. You will also get one when you exit the program.

In my searches through the code, I found a different serious bug affecting all processes with >10 parameters, mainly TEXTURE and GRAIN. I've issued an interim .exe correcting this (5.06).

Meanwhile I'll continue to look for the cause of the A.V. You're correct, rotagrad, that the bug also affects TEXTURE DECORATE.  But the same workaround seems to work. Maybe whatever these two have in common will give a clue...

rotagrad:
Thank you, Robert. Using the 5.06 executable and your workaround method already allows me to explore the textures processes for the time being.

I've found a curious behavior, though, using another method. I've found it easier, for the moment, to use the reset button on the parameter page of TEXTURE GROUP whenever the access violation bug happens. Since that would end up resetting the previous parameters, I save a snapshot of them before running the process every time. The thing is: this method [open the parameter page -> reset parameter page if access violation -> load snapshot of previous parameters] has already given me several parameter edits of TEXTURE GROUP in a row without any issue of running the process correctly or any access violation warnings this afternoon. It has randomly showed up at points, but the return of access violations does not seem to be connected, in my attempts, to changing any specific parameter. I'm not sure if this is useful in any way for your debugging process, but at least it seems to be an efficient method for minimizing access violation warnings.

Thank you very much for your efforts. This temporary fix is already very welcome.

Navigation

[0] Message Index

[#] Next page