I have a patch that is reading a text file (converted from gpx), and parsing it out in order to drive sound synthesis.

I'm using both snapshot and a tabwrite to visualize the two different synth chains (one driven by latitude + altitude, the other by longitude + altitude), and can see that the numbers are ranging a lot - from 0 to 120 or so... which is expected, and no problem.

The problem is that writesf~ is only seeming to take the values when they exist between 0 and 1, so only a small portion of my patch is actually recording. At least, this seems to be the issue, as far as I can tell. Can anyone confirm this behaviour ? Is there a way to edit it?

I've tried to put both a clip~ and tanh~ on my signal chain before writesf~, but they both seem to just ignore and values over the argument, and not actually compress/remap the values. Again, am I reading this behaviour correctly?

I can of course decrease the signal, but as I have several different files in my patch, and they all give different values, it is difficult to come up with an absolute value that wont unnecessarily make some of the tracks/processes sound too quiet...

None of this is a problem as far as actual playback is concerned, so in the end I might just record the output with Wiretap or some screencapture software, and just rip the audio, but I had never used writesf~ before, so thought I'd give it a try.

I might also be interested in trying soundfiler, but I am currently writing to 3 different arrays, and it doesn't seem possible to combine multiple arrays into one soundfiler write thread... but please, let me know if you have experience otherwise.

thanks for any feedback...

~ J

@JesseScott said:

The problem is that writesf~ is only seeming to take the values when they exist between 0 and 1, so only a small portion of my patch is actually recording. At least, this seems to be the issue, as far as I can tell. Can anyone confirm this behaviour ? Is there a way to edit it?

I think a 32-bit float format should allow values greater than 1, but I don't know if [writesf~] will clip it anyway.

I've tried to put both a clip~ and tanh~ on my signal chain before writesf~, but they both seem to just ignore and values over the argument, and not actually compress/remap the values. Again, am I reading this behaviour correctly?

Probably not. [tanh~] doesn't take an argument, and everything should just be in the -1 to 1 range. [clip~] takes two arguments (a minimum and a maximum). Anything outside the range will be clipped within the range.

I can of course decrease the signal, but as I have several different files in my patch, and they all give different values, it is difficult to come up with an absolute value that wont unnecessarily make some of the tracks/processes sound too quiet...

Why not decrease them individually? Couldn't you just divide by 120?

None of this is a problem as far as actual playback is concerned...

I find this a little hard to believe. If you're sending the same signal to the [dac~] as you are to [writesf~], they'll clip the same way. Anything outside of -1 to 1 will clip and distort.

@Maelstorm said:

@JesseScott said:

The problem is that writesf~ is only seeming to take the values when they exist between 0 and 1, so only a small portion of my patch is actually recording. At least, this seems to be the issue, as far as I can tell. Can anyone confirm this behaviour ? Is there a way to edit it?

I think a 32-bit float format should allow values greater than 1, but I don't know if [writesf~] will clip it anyway.

Ok, i'll try adding the -4 flag to make it 32-bit... will advise.

@Maelstorm said:

I've tried to put both a clip~ and tanh~ on my signal chain before writesf~, but they both seem to just ignore and values over the argument, and not actually compress/remap the values. Again, am I reading this behaviour correctly?

Probably not. [tanh~] doesn't take an argument, and everything should just be in the -1 to 1 range. [clip~] takes two arguments (a minimum and a maximum). Anything outside the range will be clipped within the range.

Yes, I know that tanh~ doesn't take an argument... but if I take a snapshot~ of the signal right before the tanh~ I can see that anything coming into it above 1 isn't passing through tho the dac~ ?!?

@Maelstorm said:

I can of course decrease the signal, but as I have several different files in my patch, and they all give different values, it is difficult to come up with an absolute value that wont unnecessarily make some of the tracks/processes sound too quiet...

Why not decrease them individually? Couldn't you just divide by 120?

It's just tedious... i have almost a dozen files, and I would have to either code something that stores the highest value or watch each one individually to see what the peak is for each one...

@Maelstorm said:

None of this is a problem as far as actual playback is concerned...

I find this a little hard to believe. If you're sending the same signal to the [dac~] as you are to [writesf~], they'll clip the same way. Anything outside of -1 to 1 will clip and distort.

It had me confused too, once I sat down to think about it. Sure, im getting wildly oscillating sonic values, but that's the intention...

@JesseScott said:

Yes, I know that tanh~ doesn't take an argument... but if I take a snapshot~ of the signal right before the tanh~ I can see that anything coming into it above 1 isn't passing through tho the dac~ ?!?

Because it should be below or equal to one after [tanh~]. It's passing through, just altered. What exactly are you expecting?

It's just tedious... i have almost a dozen files, and I would have to either code something that stores the highest value or watch each one individually to see what the peak is for each one...

Welcome to programming!

You could make a process that triggers when you load a file that runs through the entire textfile, writes every value to a table, and use [tab_max] from iem_tab to find the highest value. If those three arrays you speak of contain all the information from the file, then you're might already be almost there.

It had me confused too, once I sat down to think about it. Sure, im getting wildly oscillating sonic values, but that's the intention...

That could just be masking the distortion.