MultiSampler

[KG_is_back]

OK guys, new update...

I've added new pitch-shifting method feature - it has 3 modes:
resampling: pitch shifts the sample by playing it faster/slower (like in original versions).
time-preserving: preserves the sample length and envelope. Basically it occasionally adds or subtracts one period-length from the clock, so that the clock says as much in sync with original file as possible.
tempo-synced: same as previous, but adjusted for tempo. You must provide tempo of the sample.

I've also added second scroll-bar to the sample editor. The second one allows you to scroll within the bounds set by the first one, basically doubling the resolution and maximum zoom.

There is a problem in this version. For some unknown reason the CPU usage is extremely high. The problem seems to be the sample-data extraction module, which is weird because it should run code only in stage(0)...

[martinvicanek]

Sorry the schematc crashes on first key pressed. Which FS version did you compile it with?

[KG_is_back]

Sorry the schematc crashes on first key pressed. Which FS version did you compile it with?

v.3.0.8.1. I have tried to experiment with some ruby/assembler trickery. Basically packing data in ruby and passing pointer of a string to assembler. I've done it so that memin does not have to allocate all the tables for each voice. I will probably scrap that idea and simply use memin. There are a few cases which I haven't protected, for example when group does not contain any samples, the stream may end up reading data from invalid address. I will try to fix it soon.

[KG_is_back]

OK.... This one should be working normally. I abandoned the lookup-table approach and decided to stick with memin.
I also added two new features:
-added "velamp" feature. It controls how much the volume of the sample responds to velocity. when "velamp=1" the samples will always play at original volume. When at 0, samples volume will scale with velocity being maximum at "velmax" of the group and zero at "velmin" of the group. When set at 0.5, the volume at "velmin" is 50%.

-the piano-tab can now be used to adjust the velocity/key range and central key of the group.

Hopefully this version works correctly.

[KG_is_back]

guys, I think it's time to have a better look at the GUI. As you can probably tell, I'm not really good at making GUIs. There's quite a lot of features in the plugin already and it is getting cramped. I'm not really sure how to split up the controls most sensibly and maintaining the ease of use.

My main problems:
the sample-list is top-bottom, while the sample-edit window is left-to right. They should preferably be accessible at the same time. When I align them side-by side, the edit window is too narrow. When I put them one after another, the sample list is very short.
The biggest problem is, that I plan to add multi-sample support - where each "sample" may contain multiple wavs, one for each output channel. This would make this part of the GUI more of a rectangular. For that version I will display a grid, where names of wav-files will be visible when hovered over.
I'm not really sure how big the GUI can get w/o causing problems to users with small screens.

Another problem is, that I finally need a unified design for knobs, and interaction areas. The stock knobs, buttons and edit boxes do not go well with my custom elements, which are rather simplistic. I feel something in-between would be nice.

Any suggestions and help will be greatly appreciated.

[tulamide]

guys, I think it's time to have a better look at the GUI. As you can probably tell, I'm not really good at making GUIs. There's quite a lot of features in the plugin already and it is getting cramped. I'm not really sure how to split up the controls most sensibly and maintaining the ease of use.

My main problems:
the sample-list is top-bottom, while the sample-edit window is left-to right. They should preferably be accessible at the same time. When I align them side-by side, the edit window is too narrow. When I put them one after another, the sample list is very short.
The biggest problem is, that I plan to add multi-sample support - where each "sample" may contain multiple wavs, one for each output channel. This would make this part of the GUI more of a rectangular. For that version I will display a grid, where names of wav-files will be visible when hovered over.
I'm not really sure how big the GUI can get w/o causing problems to users with small screens.

Another problem is, that I finally need a unified design for knobs, and interaction areas. The stock knobs, buttons and edit boxes do not go well with my custom elements, which are rather simplistic. I feel something in-between would be nice.

Any suggestions and help will be greatly appreciated.

I tried to work something out, since I have a pretty good idea how to arrange especially your main problem #1. But I will be honest: There are too many "grey zones". You need to work out the concept first and create a little list that lists AND explains the elements of your sampler, ordered by relation.

I loaded your latest fsm and pretended to be an average user, never programmed, but used a few samplers before. First issue I had: What am I supposed to do? Well, it's a sampler, and the only thing that looks familiar is the wav loading. So, let's load a wav. Second issue: Where did I load it to? Third issue: Where do I define the key range? Fourth issue: I see something called group. How do I work with groups?
Currently, the only ones that can work meaningful with the sampler are the developer (you), maybe Martin (because he's a wise guy) and maybe Spogg (because he's always willing to dive deep into a schematic).

I have made two screenshots from Reason's Sampler NN-XT. It's not about the design. But I wanted you to show the difference in the logic of the concept. You can easily understand it just by viewing the GUI:
http://image.prntscr.com/image/e571dc2622184ef591d10f86a8cae06e.png

I chose a multi-layered, multi-sampled Instrument. There's three sections in the image. The upper part obviously for all things global. The lower part is divided into two sections, the "lcd-screen" and the surroundings. The surroundings are labelled "group". Now look at the "lcd-screen". You see samples, obviously grouped somehow, and you see how the samples are arranged on the keys. In fact, the concept only deals with three words: group, sample, zone. A group contains at least one sample, each sample is zoned on the keyboard. Each group has parameters, each sample has parameters and each zone has parameters. All those parameters are accessed in the group section of the lower part of the screen.

http://image.prntscr.com/image/1360bbd8729a4fd8af846828427cdf3e.png

In this image I have selected a sample from a group. You can see how immediatly all relevant parameters for the group, the sample and the zone are activated.

So, work on a more complete concept, convert it to a listed text and make it understandable for those who didn't program it. I for one would then love to work out a GUI.

[Spogg]

For my more recent creations I've started making a basic user guide to go with the plugins.
It's so hard to see something as new when you've seen it grow up so, when the layout is finalised, I would love to see a user guide included for new users.

Cheers

Spogg

[kortezzzz]

Hi KG,

I've just downloaded it and took to a small ride with it and here is my impression:

1) At the sound department, I used one of my bass samples which sounds pretty good with some other samplers. From the first key press, the sound was not good. It was too clicky and poppy and I got a feel like it lack's a decent envelope release (too short?). After few seconds, things started to slow down as with a very noticeable latency (maybe I just made a bad use with one of the sample options?... anyway, couldn't fix it back, no matter whatever option I switched on\off) . I think this sampler is not yet decent enough for playing. Also the randomizer didn't worked for me (or I just don't thoroughly understand what it should do...).

2) At the GUI department: I didn't totally understood the logic behind the ruby GUI. Too many possibilities are packed together into one tide code without any option for the designer to customize them. For instance, I cant re-design the "new sample load\save" option and I cannot reach the very basic adjustments (like env.s, LFO's, etc.)

But I definitely see the potential there!

It's reminds me a little my drum sampler, "Shaka" that released about 2 years ago. It was horribly huge and complex project for me (and my poor knowledge ) back then, and I used the SFZ which is most likely a lot slower then your load\save method (per sample). I see how your sample packing method can be smoothly integrated into my project, so I would like to suggest to you nest your sampling system into my complete project and try, as the first step, to fit your code to any of my adjustment options (ENV.s, pitch, filters, etc.). After that, I believe it would be a lot easier to extract your code out of my "Shaka" shell and nest it into a new "body". I would call it "Frankensteining"

Sharing the full project, plus adding the plug-ins sound library installer link for download (don't get scared, it's just an easy to install 22 mega-bytes library that sends itself to your "my documents" folder )
Just install the library first and then open the project in FS

Full project's FSM file link: https://drive.google.com/open?id=0B9g2XipKO-C6dVlISmN5V2F4VTA
Sound library link: https://drive.google.com/open?id=0B9g2XipKO-C6TWR3VzYzeEdIdG8

[KG_is_back]

I've made a short manual for current version. Hopefully it will make a little bit more clear what the thing should do. Unfortunately I've been busy lately and heaven't got time to fix some bugs I've found.

[tulamide]

Hey KG,

I just read your manual and it makes a lot of issues clearer to me. As a proof that I finally understood the concept, please confirm (or disconfirm) the following:

If I want to have a multi-sampled instrument, opposed to classic samplers, I don't create ONE group with all of the sample-files in it, but one group for each keyrange that each sample-file should cover. Additional samples in a group then only define alternative velocities and/or round-robin.

If I am finally correct, then I would like to propose some naming changes:
- center key: in the world of samplers this is known as "root key"
- randomizer: again this is better known as "alternating"
- pitch track: is usually named "key track"
- VelAmp: this could be misleading, I propose "volume track" to keep the naming convention and give a better image of what this knob does.

Hope to hear from you soon