SoundShaper "Access Violation" Error When Using TEXTURE GROUP

[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.

[Robert Fraser]

I also found the RESET possibility, but I found that it tended to give an A.V. every time (instead of just every other time). And I experimented a lot with snapshots; it is useful with this problem to save parameter sets via the snapshot buttons, but again I found that if recalled one when there was an A.V. I got a worse "crash".

However, I can confirm that your Reset + recall snapshot method works. (4th May) Thanks for the suggestion, rotagrad.

For now, I'm continuing to work with the code and explore other ways of doing things, which might hopefully avoid the problem altogether. 4th May update: I've now isolated where the problem occurs and roughly why -- also why it would not give an A.V. every other time.

[Robert Fraser]

The Access Violation affecting Texture Grouped (and Decorate) has been pinned down and fixed. I'll need to do many more tests to confirm this and will issue a replacement .exe as soon a possible.   

In the end, it wasn't anything to do with Texture Grouped. I assumed the data was being read in wrongly or parameter-related objects (like slider ranges) were being re-defined at the wrong time. No, it was re-writing the page title. So I put this later and all was well.  Just the sort of geeky Windoze-type of problem I do programming for. Or not.   

And why did it affect only Texture?
-- No idea. Computers are magic. Sometimes they behave like magic too.

[rotagrad]

I'm glad that the problem was simpler to fix than initially expected. Can barely wait for the fixed version!

Also, while checking other modules looking for similar bugs, I seem to have stumbled on something else: SOUNDFILE - ENVELOPE - CREATE - ENVELOPE FILE (.evl) has an issue of editing the parameters of the module. It can be put into the grid normally, and will open the default envelope file on the first attempt at editing parameters. However, after having saved the changes to the envelope file and opening the module on the grid again, it gives a window saying "Scrollbar property out of range.", and the scrollbars disappear from the GUI of the module. Clicking OK gives the window "Expected output file C:\cdpr7\Temp\~A_0.evl was not found." and the error window "Insufficient parameters on command line." The resulting envelope file cannot be accessed on the patch grid by other processes like ENVELOPE REPLACE.

A similar issue happens with CREATE - BREAKPOINT ENVELOPE. Changing any line on the envelope and clicking OK returns "INTERNAL ERROR - Cellcol." (has already happened on the first and on the second edit). Double clicking the module on the patch grid to edit parameters then returns "Cell appears to be a Virtual Copy, which cannot be edited. Instead, edit the cell that it's copied from." Unlike CREATE ENVELOPE, you can still find the resulting envelope file on the grid and use it with envelope-related modules.

I'm not sure if this is of any use, as it doesn't seem to be entirely compromising the usage of envelopes, but perhaps it was an issue that had been overlooked by others in the past.

[Robert Fraser]

Access Violation has been fixed in the latest version 5.07, now available for download.

I'll look into the aspects of Create Envelope File. (Pity that was not a separate thread and I would have caught it before releasing 5.07. Too bad.)

[Robert Fraser]

ENVEL CREATE Error: Your description is quite correct. One (and sometimes the other) of these functions is not always selecting the mode button in the left-hand panel. Simply click on the empty mode button and the problem goes away, I  believe. 

I'm not sure why this is happening and will look into it: all Soundshaper parameter pages have at least one mode button, though there may not be an actual mode number in CDP (there is in this case).

There is an alternative way of creating envelopes in Soundshaper, based on the length of an actual soundfile. Load the file, then select Graph | New Breakpoint Graph. A new flat graph is created with an X-scale of the same length as the sound. Change the Y-scale to 0 - 1 with 0.5 as the middle point. You can then create whatever envelope shape you like and save that as a breakpoint file using whatever name and location you like.

If you think about how you might use this with the second envel create function, it seems a bit pointless to use a breakpoint file to create a breakpoint file. But the documentation points out that you can precede a level value with the letter 'e' to get an exponential curve. That could be useful, but don't try to edit this in the Graph Edit!