how to add offset

[tester]

And now the final question.

What interpolation method produces brighter higs than B-Spline (in this order), without doing this digital metalization on it due to playback speed?

Because none of methods attached above is. B-spline is smooth and relatively bright, Optimal duo are smooth but darker and less detailed (threshold point will be noticable in mix), among other methods - no matter how bright they are - they are not too smooth highs.

Did someone made any experiments with other stuff like that?

[tester]

Hmm... Assuming, that I did not made some mistake on sample indexes in waveread section (these from -2 to + 1 and from -1 to +2), maybe there is one another idea to explore. Combining (mixing) between two interpolation methods. Theoretically, it could give some balance between bright-but-dirty and soft-but-dark section.

//edit:
moving it here:
viewtopic.php?f=2&t=2706#p13985

[tester]

Hey KG, I found a problem, big one and spooky one. It probably has to do with the size of files and the counter. To replicate the issue, please use this file from freesound.

When the offset is set at 0 (%), then everything plays fine. When the offset is set at let say 60 - sound is very distorted. When offset is set somewhere around 46-47, sound sounds normally at the beginning, and then gets distorted. From what I could find, similar thing happens when you remove the "fractional" node, so maybe this is related to how the frac is calculated. But this is all I can say...

I would be very grateful if you were able to fix this.

[KG_is_back]

Hey KG, I found a problem, big one and spooky one. It probably has to do with the size of files and the counter. To replicate the issue, please use this file from freesound.

When the offset is set at 0 (%), then everything plays fine. When the offset is set at let say 60 - sound is very distorted. When offset is set somewhere around 46-47, sound sounds normally at the beginning, and then gets distorted. From what I could find, similar thing happens when you remove the "fractional" node, so maybe this is related to how the frac is calculated. But this is all I can say...

I would be very grateful if you were able to fix this.

I can't test it right now, but the problem is obvious:

The file is too long. When index reaches certain size, integer can't be converted to float and back looselesly.

My index counter provides also 32bit integer output that should not suffer from this problem- use that. And you will have to use custom wave read primitive. Here is the schematic of custom wave read primitive that uses the index(int). The offset (those -2,-1,1 values for interpolation) has to be managed internally cos' you can't add float to int stream.
Also you have to provide pointer (from the mem address primitive - but you have to convert it to binary and then to float), size in bytes (also as binary int) and whether the wave is mono or stereo (true for mono).
To attach green int into stream integer looselessly use the toolkit in the schematic.

I'm sorry I cannot do the whole thing for you, but I do not have the new FS amber, so I do not have the mem address prim, which is crucial for this to work (I have made a workaround just before the update, but it was very unstable).

[tester]

The test file is just 12 minutes long at 48kHz/24bit/stereo, which means that "long files" are pretty short. Not too short? This would also mean, that at continuous playback, at some point the file will start to sound buggy. A little bit more than 6 minutes at 44.1k.

I'm reading your schematic now.

I assume, that I can use the modified version of the counter that I use right now, just with sending that int node instead posint and fracint.

Now there is the other thing. Interpolations. With waveread I (according to what you said earlier about offsets vs methods) have offsets from -2 to 2, depending on which interpolation method is currently used.

But the interpolations itself... They use this fractional part, which means that even with custom waveread - the issue still exist? Or should they be rewritten into something else?

If you say that file is too long, then what for is the fractional part then? Not for adding some accuracy? How many digits (?) of accuracy? If I understand correct, at 48kHz stereo, float prim starts to produce X+e### results at 0.17 minutes, which means 2-3 digits more solve the problem so to speak. Or...? Sorry for loud thoughts, but this is how non-programmers see these things.

*

I haven't yet installed the amber version too, I would have to do too many tests on unfinished other projects.

BTW, would you like to get a new 1 year licence support? No promises, but I can see if I can get one for you.

[KG_is_back]

The test file is just 12 minutes long at 48kHz/24bit/stereo, which means that "long files" are pretty short. Not too short? This would also mean, that at continuous playback, at some point the file will start to sound buggy. A little bit more than 6 minutes at 44.1k.

exactly. Float can be converted looselesly to 24bit int. that is 16777216samples. that is 6,34minutes @44100Hz. Using 32bit int you can index any wave file, since wav uses 32bit int to define file length you should never experience the problem again.

I assume, that I can use the modified version of the counter that I use right now, just with sending that int node instead posint and fracint.

exactly. Use frac as usual, but use the index(int) instead of index(float). The float output is actually made, by converting the int output to float (so you could use the module with normal wave read prim in case you would use shorter files).

Now there is the other thing. Interpolations. With waveread I (according to what you said earlier about offsets vs methods) have offsets from -2 to 2, depending on which interpolation method is currently used.

Yes, the custom wave read is exactly as the stock one, except one minor thing - it needs the index(integer) and the offset(float) to be provided by separate input, since you can't directly add them (like when you connect two connectors to single input, they get added). It would be so much simpler if stream int format was added to the FS. That way we could looselesly connect green ints to stream and have clear idea, where the schematic uses integer and where float. (using stream to carry float is basically an assembly hack)

But the interpolations itself... They use this fractional part, which means that even with custom waveread - the issue still exist? Or should they be rewritten into something else?

as I mentioned. The fractional part is OK - yo should use it in both cases. The integer part is problematic when BIG index values are used.

BTW, would you like to get a new 1 year licence support? No promises, but I can see if I can get one for you.

I am using the Flowstone free version 3.0.2 firefly. Way back from times, when FS had free version. I'm currently in phase of saving money for releasing CD of my band. I would have bought flowstone half year ago already, but at that time updates were nowhere coming, so I wasn't sure of software continuity.

[tester]

Two questions.

1)

One thing confuses me a little bit. Asm block sends data through mono4 blue line here, which means - float. From what I see, it would mean that stream connectors recognize what is connected to them (float/int), but if various greens are connected to the same node - convert everything to float?

2)

Also you have to provide pointer (from the mem address primitive - but you have to convert it to binary and then to float), size in bytes (also as binary int) and whether the wave is mono or stereo (true for mono).

I did not understood that part. You mean using prims int->bin and then...? (there is no bin->float) Or using that integer converter in schematic?

3)

What replaces the "mem-in" connector in your waveread? The pointer?

[Exo]

@tester check out my free running polyphonic oscillators for an example of using the "Mem to address "


@KG_is_back the "Mem to address " is actually a very old primitive called "to int" which was hidden. If you download my free running oscs (you should be able to force load it) you will get access to it, just wrap it in a module and pop it in your toolbox.

[tester]

KG, I did what I understood from what you said, but it's crashing.

[KG_is_back]

One thing confuses me a little bit. Asm block sends data through mono4 blue line here, which means - float. From what I see, it would mean that stream connectors recognize what is connected to them (float/int), but if various greens are connected to the same node - convert everything to float?

That's why I said it is a hack. The SSE variables are 128bit containers (split into 32bit parts), but they do not in any way indicate format (except on declaration when they are pre-set to a constant value of some type). That means, within assembly you can store 32bit ints onto variables which are 32bit floats, but no conversion happens - you simply copy-paste the binary pattern. The SSE instructions simply assume the binary is of certain format and handle the binary as that format.

Look at this example - it should be clear.

I did not understood that part. You mean using prims int->bin and then...? (there is no bin->float) Or using that integer converter in schematic?

simply use that integer converter in the schematic - it is ready to go, so you don't have to make one from the scratch.