MultiSampler

[KG_is_back]

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.

Yes, that is exactly correct. I was considering also renaming "group" to "zone" because it hints much better what the idea behind it is.

[tulamide]

Awesome! If you would really be willing to rename group to zone, that would make it even easier. Because, if you could consider this as well, I always like tree structures, and by adding another name, we could have it nailed down.

(some name, maybe instrument or, if group is renamed to zone then this could be the new "group")
|
consists of zones (at least one)
|
consists of samples (at least one)

group

zone 1
sample 1, sample 2
zone 2
sample 3, sample 4, sample 5

Based on this completed concept, I'll work out a first draft, which will be about the layout first, not design.

[KG_is_back]

I have a new idea on how to arrange the GUI. Top of the screen may be "windows"-styled browse-folder dialog:


First layer would be "groups/instruments". when you click on one, it will open the zones-tree in the top GUI and will enable (or switch to) instrument-related parameters in the bottom half of the GUI. When you click specific zone, it will open its samples in the top and zone-parameters in the bottom. When you click sample, the sample editor will be open in the bottom part of the GUI.

This would make quite clear what each part of the GUI does and always show only relevant parameters. Also, if completely new user would open the plugin for the first time, he would be forced to add "instrument", then "zones" into that instrument and "samples" into the zones, because that would be the only sequence of steps the GUI would allow him to do in default empty configuration.

I would have to rework some design choices I've made earlier regarding the controls on the bottom layer (possibly even rewriting the thing from ground up), but it's worth it.

Had you something similar in mind tulamide?

[tulamide]

Sorry for the delay!

To answer your question, my post should have given you some hints ("I love tree structures"). Yes I was thinking similar. Here's a first layout draft:
http://image.prntscr.com/image/b78de5dff55e4a40a2504b80345a3710.png

[KG_is_back]

I love it!
Although, there are few things I'd perhaps change. In case of midi-effects, I'd like to make some sort of midi-matrix, where midi effects could be chained in various ways. Also, individual midi effects will have completely different parameters. So maybe, the global section should include some sort of "Tab selection". When "sampler tab" is selected the GUI would contain the elements as you described them. When "midi tab" is selected, the Visual section would display the midi matrix similar to Nubeat's FX order or FL patcher. While the "parameter section" would contain parameters for currently selected midi-effect in the chain. I have not figured out the details yet.

Also, I'm not sure about how the browser should work. One option is the typical "windows folder tree" layout like mentioned above, where all groups, zones and samples may be potentially visible at the same time. Another option would be "windows explorer" system, where when you double-click a group, it will go down one level and it will now display list of zones (the same would happen when double clicked a zone - it will give you list of samples). It would probably have a big "back"/"up one level" button on the left and "new" button on top/bottom.
This image shows both options in the windows side by side (naturally our version would have different look, but I'm talking about functionality at the moment): http://www.daleisphere.com/wp-content/uploads/windows-xp-windows-explorer-folders-view.jpg

[tulamide]

I will go with whatever you prefer, but personally I'd go with the "windows folder tree" functionality. Of course we wouldn't need the +/- button, a click on a group or zone would automatically show the childs. I see an advantage in it and that is, you can easily switch between zones/groups while having oversight of the structure. Whereas in the second functionality you always only see the current "subfolder"-content and have to click to get back to the structure then click to get to another "subfolder"-content.

Regarding midi: I wasn't aware of your visions regarding them (I thought of a few on/off switches only). Of course, we can do such a change. We could even think of the whole space underneath the global section as switchable, so that, for example, the midi effects don't show the browser, but use the space instead for a wider visual and parameter section.

And in case of audio effects (I know you don't plan on them, but who knows?), they would also have such a section. The same for global, it could have some sort of file browser for presets, for example.

What about the size? I decided for one that leaves enough space to always look tidy while showing quite a lot of information. Currently we can change the scale, but when I begin with the design I should rely on a size.

[KG_is_back]

I will go with whatever you prefer, but personally I'd go with the "windows folder tree" functionality. Of course we wouldn't need the +/- button, a click on a group or zone would automatically show the childs. I see an advantage in it and that is, you can easily switch between zones/groups while having oversight of the structure. Whereas in the second functionality you always only see the current "subfolder"-content and have to click to get back to the structure then click to get to another "subfolder"-content.

there are pros and cons to both of them. In case of the tree functionality, the tree can get messy quite fast. If you take into consideration that each group may contain several dozen zones, and each zone may contain a dozen samples, whichever sub-folder you chose, its child items will easily cover the full visible list, which effectively kills the benefits of it. Also, we need to keep in mind, that there must be "add group","add zone" and "add sample" button somewhere, which needs to be easily noticeable because it will be used a lot. The "explorer" style would have them all in the same place (switching between them depending on which subsection you have selected). In case of tree structure, there would either have to be some enabling/disabling or switching based on which subsection you have selected.
Despite all of this, I also think the "folder tree" structure is preferable, for being a bit more clear in what's happening under the hood. Perhaps using differently styled "labels" (different font/size/offset) for groups/zones/samples will make it more intuitive.

"Regarding midi: I wasn't aware of your visions regarding them (I thought of a few on/off switches only). Of course, we can do such a change. We could even think of the whole space underneath the global section as switchable, so that, for example, the midi effects don't show the browser, but use the space instead for a wider visual and parameter section.

And in case of audio effects (I know you don't plan on them, but who knows?), they would also have such a section. The same for global, it could have some sort of file browser for presets, for example."
Yes, this was kind of my original intent too. An idea sparked in my head some time ago, that the global section could contain a "description" which would be editable text field. It would be intended to include user-written description of the preset. The sampler may even come in "light version" which would only allow loading presets, not making/editing them - basically it would only have this global tab.

What about the size? I decided for one that leaves enough space to always look tidy while showing quite a lot of information. Currently we can change the scale, but when I begin with the design I should rely on a size.

Well, the size is generally a problem with samplers. There is always a lot of info that should preferably be easily accessible. The image you posted covers almost full browser window on my notebook. You might've heard that bootsy had to make a "smaller GUI" version of one of his plugins, because people complained it did not fit their screens sometimes. Shrinking the GUI concept you posted by 10-20% may be a good idea.

By the way, should I start working on the folder-tree-module? I have something in mind, where the basic functionality would be coded in and the visuals of specific gui elements may be easily modified to whatever GUI you come up with.

[tulamide]

In case of tree structure, there would either have to be some enabling/disabling or switching based on which subsection you have selected.
Despite all of this, I also think the "folder tree" structure is preferable, for being a bit more clear in what's happening under the hood. Perhaps using differently styled "labels" (different font/size/offset) for groups/zones/samples will make it more intuitive.

Offset, of course. Different sizes or fonts make it too heavy on the eyes. For the buttons I had in mind the bottom of the browser area. There would be two beside each other. On is "add", and one is "remove". They wouldn't even need relabeling, because it is clear that you add a group if nothing is selected, a zone if a group is selected, and a sample, if a zone is selected. The same for remove: It removes, whatever is selected.

Yes, this was kind of my original intent too. An idea sparked in my head some time ago, that the global section could contain a "description" which would be editable text field. It would be intended to include user-written description of the preset. The sampler may even come in "light version" which would only allow loading presets, not making/editing them - basically it would only have this global tab.

Sounds good to me. I will make changes to the layout to reflect the new "all in tabs" concept.

Well, the size is generally a problem with samplers. There is always a lot of info that should preferably be easily accessible. The image you posted covers almost full browser window on my notebook. You might've heard that bootsy had to make a "smaller GUI" version of one of his plugins, because people complained it did not fit their screens sometimes. Shrinking the GUI concept you posted by 10-20% may be a good idea.

I was thinking about size a lot before I made this decision. Most people have at least HD (1280 x 720), and based on that I shrunk to 1152 x 648, which is 90% of HD. But sure, I will reduce the size again. I'll try 1024 x 576, which is 80% of HD.

By the way, should I start working on the folder-tree-module? I have something in mind, where the basic functionality would be coded in and the visuals of specific gui elements may be easily modified to whatever GUI you come up with.

If you have such a plan, then go with it. As long as it's versatile enough to "fit any size", so to speak, I see no reason why not to implement the functionality already!

[tulamide]

I'm in the middle of working on the design. Normally I don't like presenting half-done work, but according to the forums today is your birthday! So here you are:

http://image.prntscr.com/image/bd511ce5d50048a28a6b6fbd0de3c783.png

It's a so called "flat design", with a triaded color palette and a base color known by the name "mint leaf". Goal is to have the most simple shapes and a clear, tidy surface.

Happy Birthday

[KG_is_back]

Thank you tulamide, that is very nice

I like the flat design - exactly what I had in mind. Looking at the tree browser, it reminded me a thing that I probably should have clarified.
A "sample" within a zone is not just placeholder for wav. It contains looping/envelope data and up to N wav files (one for each channel). The number of channels can be changed in the Global section. Gsamp versions I posted so far are simplified (the number of channels is fixed to 1, as you can see in the "save/load section" module, variable number of channels is anticipated). The idea is that it should be able to sample multi-channel drums (each drum having "linked" wavs for direct mic(s), overhead and room mic, as well as bleed to other direct mics).

When new "sample" is added, the wave editor window (where envelope/waveform is shown in previous versions) would show no waveform, but show text saying "add wav files to channels above /\". Above the Wave editor would be N icons/cells (one for each channel), "empty" cells and cells with files already loaded would be colored differently. Optionally one would be highlighted even more, which would indicate it is the wave being shown in the wave editor as background. Loading/deleting wave files and selecting one for wave editor background would be done by left/right clicking and perhaps context menu.

It might not be the best solution, because names of the wavs would not be normally visible (they'd have to be displayed as "tooltip" when hovering over cells). Including the wavs into the tree browser may be a solution, but IMHO a confusing one, because it would cause inconsistent behaviour - groups can have arbitrary number of zones, zones can have arbitrary number of samples, but samples always contain fixed number of wavs and include "empty" slots too... This again essentially boils down to the vertical vs. horizontal space issue...

BTW, the tree browser is close to finished. Currently it only keeps the selected path unravelled, but I can try to make it so tat multiple branches can be unravelled at the same time.