MultiSampler

[KG_is_back]

KG, there is something else you can do to mitigate glitches when the recorded pitch is a little off: read two copies of the sample delayed by one period. Crossfade between them in such a way that each time you skip or repeat a period the respective copy is silent. Always skip two periods (leapfrog) so the two copies maintain lag of one period.

great idea. What you are basically saying, that every time the clock-difference approaches zero I start to crossfade with signal one period behind (or vice versa depending on the direction of pitch shift).
Another idea I had, is to put a small auto-correlator and interpolator (two point - a few samples in front and back from target position) to joint the waves as close as possible to smooth joint. This way the algorithm would correct for minor pitch fluctuations.

Either way I will have to add at least one additional interpolated wave-read module. Once I implement attack-sustain(loop)-release phases it will triple the amount of wave readers. I wish there was a way to read wave-arrays in assembler. It would make it possible to code more efficient wave-reading with bypasses... It is possible with normal waves...

[tulamide]

It feels strange to not exist

[KG_is_back]

If you're not looking for harddisk streaming, then Ruby should be able to help you with preprocessing. You could load a file (the wav's chunk format is straight forward and should be no issue, it will just need time to write the code) to a string, convert it to 32-bit-float and send the appropriate bytes via frame-sync to blue.

None of this being complicated, but for sure will take some time to write the code...

...or I can just skip ruby, load the wave file and use wave-read prim in blue. Actually I'd rather avoid blue, since it only runs at sample-rate. The point was to do some pre-processing on the samples during loading. I've done some experiments with the analyser prim and it seems to be stable as long as the files are small enough and as long as I don't connect anything to its output (which is float array with hundreds of thousands of entries = problems).

However, I was considering making a custom wave-array, because stock wave-array-read prim is very limiting and inefficient in many cases. There is a cool trick I have found when playing with strings and pack/unpack methods. You can actually use pack method to obtain pointer to a string and then send that pointer out (and for example use it in assembler, like demonstrated here).
I believe this is how flowstone "Frame" class is actually implemented under the hood.
My idea is, to create a module, that can do following:
1. load a wave file
2. convert the file to array of floats and pack it into a string ( basically data.pack("f*") )
3. store the strings internally as a "wavetable" and provide the pointers to those strings.

I have done a schematic that loads wave files and stores them as Frame, but ruby was very slow and kept freezing. Then I moved the loading to another thread, which solved the freezing but made everything even slower.

[tulamide]

The point was to do some pre-processing on the samples during loading.

And my point was that you can do exactly that while loading. Hell, you can even read in a single byte if you like to. It would be: read x bytes, process them, read next x bytes, etc. See (IO or File).read(name, offset, length). If you don't call a block, the file keeps open, which allows you to use lower level calls to seek within the file and read x bytes. That would be IO::seek.

Then I moved the loading to another thread, which solved the freezing but made everything even slower.

Yes, we had that issue in the past, as I remember. You were experimenting with threads and it turned out (I think it was Tronic who shed some light on this) that user threads are childs of the one Ruby thread that Flowstone runs. So, it does indeed make it even slower. I only see one solution to this isuue: a larger buffer to buy more time.

[KG_is_back]

And my point was that you can do exactly that while loading. Hell, you can even read in a single byte if you like to. It would be: read x bytes, process them, read next x bytes, etc. See (IO or File).read(name, offset, length). If you don't call a block, the file keeps open, which allows you to use lower level calls to seek within the file and read x bytes. That would be IO::seek.

Yes I'm familiar with IO and File classes. I'm sceptical about the ruby processing speed. With current setup in the gsamp, loading of typical bank takes about 20seconds (that is roughly 25 2-minute files). I suppose we could start making a WaveFile class for flowstone ruby. Something of sort that I made earlier in topic I referenced in previous post.

BTW, I like how this multi-sampler project touches on so many areas and brings them together. syncing data between ruby modules and streams, loading and processing files, working with midi, re-sampling, interpolation... Each of which might deserve its own topic to deal with in depth.

[KG_is_back]

Hello,
New update. This one contains several unfinished things. It is mainly to show new GUI layout. I've added piano-view where you can see key/velocity ranges of individual groups (current group is marked red). Currently it is only visual - I will add interaction later.
I've also improved the sample editor view. I've basically written new "wave-minmax" module, which now changes resolution based on zoom level. I've also added selector for the pitch-shifting method. Currently it does nothing - it's just a GUI part for upcoming feature.
The schematic also contains a lot of half-finished modules.

Loading time of the samples and present may have increased (quite significantly), because I've added some pre-processing for loading samples.

It seems like the preset file stores an absolute path rather than a relative one. When I put it back to my /Download folder the old and the new one worked fine, in the same old folder location.

It works fine here. Are you sure that you copied the preset file with all of its samples? Are the samples in new folder, in the same relative position to the preset file (ie. you have "eguitar.gsp" an "eguitar" subfolder in the same folder)?

[martinvicanek]

You can store a pitch profile along with the sample or generate one on load. I have a very lightweight and quite accurate pitch tracker that I can share.

This is my little pocket sampler which, besides the mentioned pitch tracker, containes other elements that you may find useful for your project. Just poke around and grab anything that suits you. The pitch tracker is based on ASDF, which I find more accurate and more robust than any other monophonic pitch detection method (including zero crossing). I have optimized the heck out of it. This one is taylored for my 5 string bass so it goes down to low B, covering more than 4 octaves. That range could be extended if you can afford some moderate CPU load increase.

[Spogg]

It seems like the preset file stores an absolute path rather than a relative one. When I put it back to my /Download folder the old and the new one worked fine, in the same old folder location.

It works fine here. Are you sure that you copied the preset file with all of its samples? Are the samples in new folder, in the same relative position to the preset file (ie. you have "eguitar.gsp" an "eguitar" subfolder in the same folder)?

Well I just tried to reproduce the issue and it worked fine this time. Computers eh? Or this stupid old Vulcan did something wrong.
Anyways, thanks for that and sorry to have worried you.
I'll try the new one out very soon...

Cheers

Spogg

[Spogg]

All ok on my system

Here's what might be a big ask...
It would be nice to get some visual feedback on the loading progress when a preset is loaded. And/or maybe switch back from the preset page to the main one when done.

Am I supposed to see any activity at all on the Piano roll view at this point? I just see vertical lines but that may be correct at the moment.

Cheers

Spogg

[KG_is_back]

It would be nice to get some visual feedback on the loading progress when a preset is loaded.

yeah it would be... I'm working on this already, sadly with very little luck. Flowstone freezes during loading, because samples are loaded in a loop. It turns out be hard to redraw GUI during the process. Also, the wave-array prim does not give out any progress on loading of single wave. I am trying to fix the issue by writing a WaveFile class. It makes the loading process even slower, but at least it gives off loading-progress.

Am I supposed to see any activity at all on the Piano roll view at this point? I just see vertical lines but that may be correct at the moment.

The piano-view shows minkey/maxkey/minvel/maxvel of each group as a blue rectangle. Horizontal axis is pitch, vertical axis is velocity. Current group is marked red and also marks red the "central key". Reason why currently (in the preset I provided) it shows only vertical lines is, because all groups happen to have velocity range 0-127 and don't overlap with each other.