Composers Desktop Project Forum

Some further tests have shown there probably IS a bug in LOAD PATCH. I loaded a sound and did a preview and render, then cleared the patch grid. When I clicked LOAD to load another patch, the "patch not cleared" message came up and the old source was still there in TEMP. The patch ran OK, but with the old source! (I think "Include source" was checked, for the patch.)

I then decided to repeat all this, but the old source wouldn't re-load (because it was still in TEMP) and Windows wouldn't let me delete it manually ("file in use"). To fix this would mean shutting down the program and then deleting the file.

I'll investigate this further and issue a program update when I think it's sorted.
 

OK, as you were; the two lines in filters0.c (ca Line 241) needed to be moved up to the end of the previous if block (after the for loop). they are needed for the variable filter banks, but not the fixed options. I have updated git with this change. Trevor is "out of the office" for a week, so any revisions to this solution may be a while.
.

Thanks; but NB only partly. The proper solution will very probably be inside the code for filter itself, rather than in the library (in principle, any change there, even if ostensibly benign, would demand a full recompilation; and the hack I have suggested will also have the possible consequence of hiding other bugs that may be out there). For example, I am now wondering if the offending assignment in filters0.c is in fact spurious and can be deleted, as the index name used is cited in the relevant header file as specifically for time-varying filters, which does not apply here.

Quote from: Vasilakis on June 05, 2025, 10:44:24 AMthere are indeed some weird folders in TMP named "~X_4" and "~X_11". There are also various .bat files like getenv and mixmany.

getenv.bat and mixmany.bat should not have a preceding tilde (~). Don't delete those. ~X_4 and ~X_11 folders are from your previews. I'll check my mechanism for clearing those -- Windows traditionally wanted folders cleared of their contents before you delete the folder, but now there is a more direct way, which I hope the program is using.

About your side note on .brk and text files:
some are supplied empty (delaytimes is a good example, because the program can't predict what times you will want). You have to edit this data yourself. Similarly, many .brk file defaults are just "skeletons" so the graphic editor has something to load. You're quite right to edit these defaults and save the results for your own use. No need to re-load the defaults.

Hello, thank you for investigating into my case.

I can't try out things at the moment, but I've checked what you mentioned and, well, it looks like there are indeed some weird folders in TMP named "~X_4" and "~X_11". There are also various .bat files like getenv and mixmany.

Hi again,

I ran my version of your patch successfully on another PC which has different paths, but that wasn't an issue in this case. You can download it here: https://1drv.ms/f/c/c99eb976df17b95e/Eodc8wmPlrVLuG2WhHRyjAQBNpGpwUficKOGx8EBx0uEFA?e=2vzXbP
 
Unzip PatchJun4.zip somewhere and copy the .ssp file and its associated folder (Vasilakis) to your PATCHES folder - see Settings if you're not sure where that is.

I hope it will run OK on your system. If not, please report back.
Robert

Hi,

I'm sorry you had such a bad experience for your first attempt to load a Soundshaper patch. Thank you for giving such a detailed account of what happened.

The problem was with the message you got that "previous patch files may not all be cleared". The program checks to see if there are files in the TEMP folder that would stop the patch loading properly, and it found something - and the patch failed. (The report window rubbish was CDP's responses and should not be taken too seriously.) I'm puzzled as to why there seemed to be no parameter file (.prm) for REVERB (it would need that, which is why the parameter page didn't work), but that's not the main issue here.

1) Were there actually any temporary files left in the TEMP folder? - these have a tilde (~) as their first character. If Windows fails to delete these (it does occasionally), the workaround is to open the folder and delete them yourself, not through Soundshaper. I suggest you try this check.

2) Or maybe my CheckPatchCleared function (which triggers that messsage) has some faulty logic - I can't see it, but will work on that, anyway. However, the message is only a warning, so I think this was not the problem.

3) I recreated a patch similar to your one (Source-Reverb-Speed-FiltVari-Speed) and it ran OK. I actually tried to crash this patch (and trigger the message) by leaving a different source file (~A_0.wav) in my TEMP folder, but this didn't stop the patch loading correctly, with its own source. Unfortunately I can't share the patch, as it uses paths specific to this machine.


Hope this may help a little.
Robert

Thanks for the update Richard and for figuring out the issue!

Hello,

there is indeed a bug here, a memory error unsurprisingly. The array allocated for internal parameters ("param") is too small, currently 18, needs to be at least 21. When that location is written to, it happens, on this Mac, to corrupt the internal sfsys file ID for the infile, so that calls to write data fail, in this case causing an endless loop.

The short-term fix to make is in the library file tklib3.c (folder "cdp2k"), at and after line 175. Before the malloc call, the value of "storage_cnt" needs to be increased, e.g. "storage_cnt += 8".

Then recompile the library, and relink "filter".

This is a bug that I need to report directly to Trevor Wishart, who can provide the necessary changes to the parameter count. I will only update sources on GitHub once I have that from him.

Well done to all for diving into the code - not as you see, for the faint-hearted. Any time a program fails "sometimes", or not at all in some cases, the culprit is very likely to be a memory error of this kind. Easier to describe than find...

Sorry to keep spamming the forum, I hope this info is useful to someone. I have a somewhat working solution.

Adding a lot of cleanup to free all the filter arrays in dz that I can find in the code after print_messages_and_close_sndfiles seems to make the process want to run multiple times with different filter modes and settings. What I have done is giving me a segfault error (exit code 11) when its done although it does run the filtering fine and produce the outfile. I think the segfault is probably just me trying to free something twice.

Seems like maybe mac is being picky about reallocating memory between runs and trying to reuse old things.

Not sure if this is the real fix, think I might just be sticking a plaster on the issue and hiding it. But, hopefully knowing that changing this and replacing soundseekx make this process want to run properly on mac will point someone who actually knows what they're doing in the right direction of the fault.

My guess is that as SoundLoom calls each process and closes it up fully after run, that that is why it works when called directly in SoundLoom but that calling it multiple times in the same terminal session or batch file doesn't close it fully and that is why some stuff is getting left over and is causing issues on subsequent runs.