Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

The Quilcom Mystery: Hopefully not a mystery to use!

Post any examples or modules that you want to share here

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby kortezzzz » Sun Jun 13, 2021 10:58 am

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 :ugeek: 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).
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby Spogg » Mon Jun 14, 2021 8:23 am

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.
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby tulamide » Mon Jun 14, 2021 11:47 am

Spogg wrote: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.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby josevo » Mon Jun 14, 2021 2:18 pm

kortezzzz wrote:...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.
User avatar
josevo
 
Posts: 33
Joined: Mon Jan 01, 2018 9:41 pm

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby kortezzzz » Mon Jun 14, 2021 3:04 pm

Spogg wrote: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.

tulamide wrote: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?

josevo wrote: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.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby StereoSpace » Wed Jun 16, 2021 2:27 am

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))
GUI designer
User avatar
StereoSpace
 
Posts: 76
Joined: Sat Feb 21, 2015 12:59 am

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby kortezzzz » Wed Jun 16, 2021 11:25 pm

StereoSpace wrote: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.
User avatar
kortezzzz
 
Posts: 763
Joined: Tue Mar 19, 2013 4:21 pm

Re: The Quilcom Mystery: Hopefully not a mystery to use!

Postby Halon » Sat Jun 19, 2021 7:55 pm

This sounds fantastic Rex! Thank you for sharing this :)
Halon
 
Posts: 321
Joined: Sat Nov 28, 2015 4:42 pm
Location: Norway

Previous

Return to User Examples

Who is online

Users browsing this forum: Google [Bot] and 34 guests