Inconsistencies in simple basic trimming

[ModeratelyModular]

Inconsistencies in basic trimming

Just starting with SoundThread (which is great) is selected a nice part of a sample that I wanted to save to use elsewhere (which module to use?).

In the instruction video it is said when a part of the sample/input file is selected only that part will be processed. However, 'trim' and 'remove' require entering percentages that (it turns out) apply to the whole input files. Using them on a selected section renders errors.

I had a sample of 1750 ms *), selected 300-410 ms, which is part from17% to 23% of the sample.

• When I keep the section selected and enter 17% and 23% in 'trim'-> error messages. **) (in a way my mistake, inconsistent, but hard to know how to proceed),
• When I keep the section selected and enter 0 - 100% in 'trim' (consistent) -> error messages. **)
• When I unselect ***) section and enter 17% and 23% in 'trim' I get an output file, however it is the part 00:00:17 - 00: 00:23 instead of 00:00:30 - 00:00:41 (consisitent input, inconsistent interpretation: percentages vs time).

So to me there seem to be two inconsistencies:

1. In 'trim' and 'remove' the whole input file is processed instead of the selected part.
2. In 'trim' the percentages are taken as time stamps.

*) the time is given in 100ths of seconds where usually ms are used. I used Ableton Sampler and Audacity to figure out why I, just beginning in SoundThread (which is great), just could not save my selected sample section as output file.

**) This took me hours with many trials and errors, so I did not document everything, but errors were like.

Processes ran successfully
ERROR: INVALID DATA
ERROR: endcut = startcut: No cutting possible.
Processes failed with exit code: -1

Processes ran successfully
ERROR: INCORRECT USE
ERROR: Parameter[3] Value (0.010000) out of range (0.022676 to 1107.142857)
Processes failed with exit code: -1

***) there actually seems to be no 'unselect'; you have to select the whole sample again, which is hard. In selecting the time-stamps do not run along.

SoundThread 0.40.0-beta

Windows 11

[j-p-higgins]

Hi could you please recreate the issue and post the full console output, without that I won't be able to track down the error unfortunately. Trim and remove shouldn't see the original input file length as the length of the input file to the process is not measured until the trim or remove process is run so the issue is likely being caused elsewhere.

There is a bug I know about with the input node trim values getting stuck that I am still trying to track down that could be causing it. Single clicking without dragging on the waveform on the input node should remove the selected area.

Note that times in soundthread will always be in % of the file when it reaches the input of the node as often there is no way to know the length of a file until other processes in the chain have been run. Many processes involve randomness and so output length may vary. There is a utility node for converting time units that can calculate exact percentages for you if needed although Soundthread is not really meant to be a precise editing tool, if you want to do precise editing in CDP I would use Sound Loom or Soundshaper. For the most part I do all precise trimming of files in a DAW after processing.

[j-p-higgins]

2026-02-0615-43-44-ezgif.com-crop-video.webm

[ModeratelyModular]

Sample 1: 1 minute

In first instance I wanted to make it easier and used a one-minute file with someone counting from 1 to 60. Using trim this worked as was to expected:

• using the whole input file entering percentage 50 and 75 nicely gave an output file counting from 30-45.
• using a selection and using percentates 0 and 100 as well as 50 and 100 also give the to be expected result

So, had I wrong? I tried the file I used yesterday, a homework assignment sample to be used for sample flipping, 1.74 seconds long.

Sample 2: 1.75 seconds

When I selected a section 00:00:29-00:00:42 and trimmed it from 0-100% I got an error (img_02). Error notifications:

Generating processing queue

Output directory and file name(s):D:/Downloads/SoundThread- Output/outfile_2026-02-07_12-23-02

Mapping thread.

Valid Thread found

C:/CDP/CDP8_002_PC/CDPR8/_cdp/_cdprogs/sfedit cut 1 D:/Downloads/Meow.wav D:/Downloads/SoundThread- Output/outfile_2026-02-07_12-23-02_0_input_trim.wav 0.28504361604389 0.42238195318925
0 min 0.12 sec0 min 0.14 sec
Processes ran successfully

C:/CDP/CDP8_002_PC/CDPR8/_cdp/cdprogs/sfedit cut 1 D:/Downloads/SoundThread- Output/outfile_2026-02-07_12-23-02_0_input_trim.wav D:/Downloads/SoundThread- Output/outfile_2026-02-07_12-23-02_1.wav 0.0 -0.1
ERROR: INCORRECT USE
ERROR: Parameter[2] Value (-0.100000) out of range (0.000000 to 0.137347)

Processes failed with exit code: -1

Cleaning up intermediate files.

del D:\Downloads\SoundThread- Output\outfile_2026-02-07_12-23-02_0_input_trim.wav
Processes ran successfully

ren D:\Downloads\SoundThread- Output\outfile_2026-02-07_12-23-02_1.wav outfile_2026-02-07_12-23-02.wav
Het systeem kan het opgegeven bestand niet vinden.
Processes failed with exit code: 1

When I unselected the section (whole sample again) and entered the corresponding (section) percentages 16% and 24% (of the original/whole sample), I got an output file (no error). However, the output-file sounds like 00:00:16 to 00:0024 from the original sample (instead of 00:00:29 to 00:00:42. The length also is 00:08 instead of 00:13. (img_03) The numbers supposed to be percentages turn out to be time (in 1/100ths of a second). When I enter 'percentages' 29 and 42 I get the desired selection again, so they act as time (1/100ths sec).

When I enter 'percentages' of 80 and 150, I get the snippet 00:0080 - 00:00:90 (so the 80 acts as time).
When I enter 100 and 300: no error, but no output file/sound. Testing several value suggests for end values over 100 it takes the start values up to 90 (60-> 30/100 sec,, 70 -> 20, 80 -> 10). End-percentages can be (far) over 100. Playing around with several values (percentage acting as time) indicates under 100 10/100ths are subtracted systematically.

My conclusion: in a certain range/under certain condition percentages are treated as 100ths of seconds. Maybe the length of the sample interferes?

[j-p-higgins]

Ok that's definitely a bug with how it's measuring the length of the file and converting the percentage, properly weird that it's making minus numbers, will have a dig and figure it out, thanks for the detailed report!