The Quilcom Mystery: Hopefully not a mystery to use!

[kortezzzz]

Thank you for the comments, guys.

Looks like there is no easy way to do it. Followed Digitonix's idea to use Extreme sample converter (ESC) to easily create a looped sample which can be then exported and readed. Inside ESC the sample gets an automatic damn perfect loop point that creates a perfect legato with no problems BUT... when you then try to import it to FS, there is no way to read those loop points The only way is with the multisample module which need the SFZ file involved and has also an exaggerated price of CPU. Well, you can indeed add those loop points manually, since ESC outputs them for you, but still, didn't find a way to create that loop inside FS (If there is away or any ideas, feel free to share).

[Spogg]

It’s possible that the resulting wav file could be read by Ruby and the loop start and end points could be spat out as 2 index values. Then the next task would be to create a reader that used those values to loop between during the sustain phase.

I don’t know Ruby well enough to know if it’s even possible, let alone do it myself, but it’s a case of parsing the file to extract the data, so I think it might work. We need a Ruby expert on the case…

The waveform reader is a DSP challenge, the trickiest part being how to handle the release phase which can come at any time during the looping or attack phase. Sudden jumps to new index values would cause clicks. It would be easier if the release phase was not part of the wav, so you get the attack then looped sustain only. In that situation you just initiate a fadeout for the release while the wav continues to loop. The attack phase before the loop start value would have to complete, so slow attacks and early release during the attack would not play as expected.

[tulamide]

I don’t know Ruby well enough to know if it’s even possible, let alone do it myself, but it’s a case of parsing the file to extract the data, so I think it might work. We need a Ruby expert on the case…

It is possible to parse the wave file with Ruby. Actually it has been done already. There are at least two Ruby wave file reader here on the forums (just search for them). Both support loop points, as I recall.

But again: If you create a sound, loop it in your DAW 3 times, record all three loops, then cut the one in the middle and use that. You can't get a better seamless loop! No need for complicated stuff.

[josevo]

...the multisample module which need the SFZ file involved and has also an exaggerated price of CPU.

Maybe the CPU cost is due to the wave viewer, did you try hidding it or skipping the redraw function?

Probably unnecessary points are being redrawn at smaller scales in your version of the multisample. As an example, at a scale of 25% of full view, 75% of the pixels would become unnecessary and could be skipped, only 1 pixel each 4 should be redrawn in that case.

Another CPU cycles reducer could consist in storing the wave view into "cache" memory by converting it into a bitmap, just after loading or editing it.

Hope it helps.

[kortezzzz]

The waveform reader is a DSP challenge

Thanks for the full explanation. Well, we'll have to first find those sampler schematics which tulamide mentioned.

You can't get a better seamless loop!

Maybe you're right, but if I understood correctly, in this way we miss the original starting point of the sample which tends to be unique (wind instruments for instance). I don't want to end up with a synth a like sound. Or I just didn't understand you correctly?

Maybe the CPU cost is due to the wave viewer, did you try hidding it or skipping the redraw function?

Removed it completely. It still keeps being high. It's probably not the reader but the DSP code itself.

[StereoSpace]

I recently spoke with DigiTonix that the weak side of the flow stone is sampling. No matter how I tried to do something with sfz, I still got a lot of CPU load. If you try to connect more than one, then everything becomes sadder. The load comes with a poly signal problem that causes sound to be damped by source a or b. The lack of dfd also throws back the sampler in relic times))

[kortezzzz]

I recently spoke with DigiTonix that the weak side of the flow stone is sampling. No matter how I tried to do something with sfz, I still got a lot of CPU load. If you try to connect more than one, then everything becomes sadder. The load comes with a poly signal problem that causes sound to be damped by source a or b. The lack of dfd also throws back the sampler in relic times))

That's why a decent continuous sample player with a proper looper can be a nice alternative. Yes, it's not the real thing, but might do the trick especially when the CPU get kept low. I looked in the forum for the sampler with the start - end point and couldn't find. If someone knows where it is or who is the uploader, please let us know.

[Halon]

This sounds fantastic Rex! Thank you for sharing this