DSP Robotics Support

Now that you mention it, indeed you already said that a sample can be a group of .wav files. I somehow removed this important info from my mind. However, reading your explanation, I think I have a clever solution design-wise. But, as always, let me first see if I really understood:

I am an aspiring drum set library producer. I have recorded drums with different microphones, quite like in your example. I recorded 3 different "velocities".
Now I set up the kick drum. I have 9 samples, 3 velocities x 3 mic positions. I create a group, create a zone, set the zone to just one key and add a sample to the zone. In the sample I add 3 wav files (the 3 mic positions in lowest velocity). I add another sample, and in there add 3 wav files (3 mic pos in mid veloctiy). And I do the same a third time, for the highest velocity.

I hope I'm close, because this is going really deep (I just now begin to realize what awesome capabilites gsamp will have when ready).

If I'm correct, then I would make a change to the layout/design. Nothing spectacular but probably the best way to deal with the "samples". And of course I won't touch the browser. I agree that it would be a bad idea to add them there.

One important question. Is the maximum number of possible wav files per sample (I think you refer to them as channels) fixed? I'm only interested in if you you will cap the number of channels, or if you allow as many as the user's system might be able to deal with? If there is a max number, I'd use a simpler design, that's why I ask.

But instead of talking about it, I will work on it as soon as you approve my understanding of the "samples". Graphics say more than a thousand words.

I have downloaded the folder tree, but did not yet have the chance to inspect it. Btw., you are roughly half my age, which also means you're double as fast xD So please accept that I will provide you with updates at a slower pace

tulamide wrote:I hope I'm close, because this is going really deep (I just now begin to realize what awesome capabilites gsamp will have when ready).

Yes, you got it exactly right.

tulamide wrote:One important question. Is the maximum number of possible wav files per sample (I think you refer to them as channels) fixed? I'm only interested in if you you will cap the number of channels, or if you allow as many as the user's system might be able to deal with? If there is a max number, I'd use a simpler design, that's why I ask.

The plugin will have 16 audio outputs (8 stereo channels). The user may specify in the global section how many of these channels he wants to use (in your example 3), which will bypass the unused ones to save processing. Each "sample" will then have one slot for a wav file per channel. When the sample gets triggered, those 3 wav files will be played to the specific audio-outputs respectively. User may then route these 3 parallel stream channels however he wants inside his DAW and post-process them separately.
This is an example of plugin that does something really similar:
https://www.youtube.com/watch?v=lpZuVzeraGA
Note that EZ drummer has an additional internal mixer, where each virtual "microphone" can be set to route its sound to arbitrary output (even all to the same one). My plugin will have each channel to one output by default - I may add similar mixer in the future.

Now you may see why I didn't wanted to add built-in audio-effects.

KG_is_back wrote:The plugin will have 16 audio outputs (8 stereo channels). The user may specify in the global section how many of these channels he wants to use (in your example 3), which will bypass the unused ones to save processing. Each "sample" will then have one slot for a wav file per channel. When the sample gets triggered, those 3 wav files will be played to the specific audio-outputs respectively. User may then route these 3 parallel stream channels however he wants inside his DAW and post-process them separately.
This is an example of plugin that does something really similar:
https://www.youtube.com/watch?v=lpZuVzeraGA
Note that EZ drummer has an additional internal mixer, where each virtual "microphone" can be set to route its sound to arbitrary output (even all to the same one). My plugin will have each channel to one output by default - I may add similar mixer in the future.

Now this brings up another question. Comparing it to easy drummer, but with harcoded 1 ch to 1 out, doesn't that mean your sampler can't use more than 16 wav files overall? Or do you allow other samples to use the same 16 channels than the first one (assuming the first one used all 16 channels)? And what about stereo vs mono wav files? Wouldn't a stereo file use 2 channels?

I would have thought that the number of cells is not related to the number of audio channel outs. In that case, each cell would define up to 2 channels (2 if stereo, 1 if mono) and multiple cells could share the same out. Probably this is what you currently set on hold, because it is too much work? However, the first paragraph with my questions is more important to me!

KG_is_back wrote:Now you may see why I didn't wanted to add built-in audio-effects.

Indeed!

tulamide wrote:Now this brings up another question. Comparing it to easy drummer, but with harcoded 1 ch to 1 out, doesn't that mean your sampler can't use more than 16 wav files overall? Or do you allow other samples to use the same 16 channels than the first one (assuming the first one used all 16 channels)? And what about stereo vs mono wav files? Wouldn't a stereo file use 2 channels?

Let's assume number of channels is set to 16. Each "sample" has 16 slots for wave-files. Each of those slots gives output to specific output channel (note, some slots may be empty, so they give off just silence). You can have as many wave files as you like. All wave files that are in first slot of their respective samples will give output to first output channel etc.

By default, wave files are converted to stereo when loaded (due to limitations of Flowstone WaveArray prim). Also, sadly it is not possible freely combine mono and stereo outputs from VST in the DAW. VST format actually does not specify mono/stereo/other output configurations - DAWs simply assume that when plugin has even number of outputs, they are stereo-pairs instead of singular mono channels. This actually causes issues when plugin has even number of inputs that were meant to be mono. When I say 16 channels, what I mean, the plugin will have 32 outputs (16stereo pairs).

Ok, here's my proposal. The twist is to reverse the technical flow of things for the GUI. It doesn't need to reflect the exact structure of the sound engine, it is more important to give the user the ability to use the GUI (preferably) intuitively. Have a look first before reading on:
http://image.prntscr.com/image/94a82023ddc349aba0fe3bb313dc1f44.png

If the user selects a sample in the browser, the list on the right is shown (WIP, ignore the big bar below for now). As you can see, there's still a matrix-like appeal, but the user sees the soundfiles of this sample and selects a channel for each soundfile. That's more intuitive to me than the other way 'round. The light mint rectangle shows the range of channels that the user defined on the global page. In this example, the first soundfile is routed to channel 1, the next to channel 3 and the last to channel 8. I based the graphics on a maximum of 16 channels (=32 outs). Also, what this graphic can't show, in my mind you can hover over the soundfile's name and it will turn light orange (like in the browser), indicating a possible action. If the user then clicks, the view switches to the sample editor, where she can set the envelope, etc.

I know it's different from what you envisioned, but this is a very convenient way to show all informations while not cluttering the view. Also, there will be less soundfiles than available channels most of the time, so making it a scrollable list by soundlife gives a better overview.

I don't like it. The gui implies that you can add arbitrary number of wave files into each sample and that you can route any one of them to any channel. I think it would be much simpler to simply show 16 (or whatever number is selected) lines, each having ch1 ... ch16 in a square. The ones that have wavefiles loaded would show filename next to the square and also the square would be highlighted. The gui is easily big enough to show all 16 lines if necessary.
Something like this (but hopefully prettier) :
http://www.mediafire.com/view/lnyf11d4dfvba7t/sample.png

The section/loop editor would then be shown as a different tab. The channel cells on the left would preferably stay, so the user can easily switch between the loaded waves in the editor tab. Note, that all the samples share the same envelope/loop-points etc. -they are parallel channels, as if they were a single 32-channel surround sound sample. The switching of the waves in the editor view would almost purely for visual purpose. Only functional difference would be that the editor would snap the loop-points to the currently selected wav.

Well, the channel dots would have been switches, not multi-selectable. But your sketch is doing just as well. I'll work on it. Expect a new draft soon ! (why isn't there a "sweat" emoticon? )

The important thing to keep in mind, that I was perhaps aware unconsciously and that we dancing around right, but I couldn't put my finger on it is this:
Making presets for samplers is very time-consuming and repetitive (it's arguably the most boring task there is in making music in the box). For a medium-sized sampler (with velocity layers etc.) you typically have around 200 samples that you need to load to specific places, which may take about an hour. When loading them, you quickly develop a routine and get familiar with the GUI. So the main goal with the GUI should be speed, and we should sacrifice clarity for speed if necessary.

a) we should prefer operations that take less time. A rule of thumb is: drags >> clicks > keyboard short-cuts. And we should reduce the number of steps/operations needed to do simple tasks that will be done the most.
Your last example required 4 clicks to load a wav and set it up properly (click load, select sample, click Open, click to assign channel) and possibly even involves dragging, when there are many channels (which is the worse case scenario). Mine needs only 3 clicks (click load in specific channel, select sample, click Open), which is at least 25% improvement (might be even more, when doing it repetitively, because shorter sequence of steps is easier to get "into the hand", so to speak). It might not sound like much, but multiply this by 200 for typical sampler-preset-making and you saved a dozen minutes.

c) put as few distractions as possible and as many visual guides as possible.
For example, in the version I posted, even and odd lines should be coloured differently, so it's easier to notice where you're clicking (maybe even groups of 4 should be marked). And clicking anywhere in the line should open the load-window, so you don't have to aim so precisely (Fitt's law), since this is the action you will most likely perform the most.

d) we should automate some parts of the process if possible (maybe just optionally as advanced feature).
For example bulk-loading features may be a good idea. Or auto-detecting loop points, Or auto-key/velocity mapping...
Anyway, It would be a good idea to count with these when making GUI - they might not be used by a "novice", so they don't need to be dominant but a skilled user will probably use them a lot, so they must not be "hidden" either. In fact, they should have the exact sweet spot of temptation, so that a they will not be the first thing that new user clicks (thus assuming it's the main feature and dismissing the plugin as "complicated") but tempting enough that he is bound to click/notice it eventually while exploring the plugin for the first or second time (thus "discovering a cool trick").

I understand you. I also understand that you are very used to gsamp and therefore expect things to look like you have it in your mind for so long now.

But I'm also concerned with one thing that you seem to neglect: The worst you can do is creating a clutered interface. Putting all things in one place just for the sake of speed is, I repeat, understandable, but if it leads to a cluttered surface people won't be attracted either.

Look at this game screen:
http://i.imgur.com/QCk1r.jpg
The only one that would play like this is the guy who arranged it. If I were a new player and saw this - I'd keep away from that horror.

That's what I'm trying to prevent. For example, I could imagine a lot of people going "Why the heck do I have to look at 16 channels? I only have three soundfiles in this sample, yet I have to look at 13 empty lines. What a waste."

I'm not against your vision, just against cluttering the interface. I'm also very much caring about c), as you can tell from the work so far. Visual guides are the foundation of the layout. And my stomach hurts when reading "sacrifice clarity for speed if necessary". I would never sacrifice clarity. Do you remember my reaction after my first look at gsamp? It was exactly the clarity that was missing and that left me puzzled. That's why I said that the goal of the layout is a clean and tidy surface.

I'll do whatever you want. It is your baby after all. But if we sacrifice clarity and clutter the surface for the sake of speed, I won't be in wholeheartedly. This could mean I don't give 100%. Not on purpose, just un-consciously. (If you ever played a song with your band that the other members liked, but you didn't, then you know what I mean)

tulamide wrote:But I'm also concerned with one thing that you seem to neglect: The worst you can do is creating a clutered interface. Putting all things in one place just for the sake of speed is, I repeat, understandable, but if it leads to a cluttered surface people won't be attracted either.

Look at this game screen:
http://i.imgur.com/QCk1r.jpg
The only one that would play like this is the guy who arranged it. If I were a new player and saw this - I'd keep away from that horror.

Yeah, perhaps you took my words a bit more strongly than I meant them My point was to put things together strategically.
For example, let's say you have a working table and you need to put nails, screws, hammers and screwdrivers into two available drawers. One way to do it is to put tools into one drawer and materials into another. Another way is to put hammers and nails into one drawer and screwdriver with screws into second drawer. What I'm arguing here is, when you know you will need to nail 100 nails in a row instead of just "2 nails here 3 screws there", the second arrangement is far superior.
The word I'm looking for is ERGONOMIC. User should have direct access to stuff he is most likely to use next, even if it's not "intuitively" relevant/clear/related at first glance.

tulamide wrote:That's what I'm trying to prevent. For example, I could imagine a lot of people going "Why the heck do I have to look at 16 channels? I only have three soundfiles in this sample, yet I have to look at 13 empty lines. What a waste."

A valid concern. I think a compromise might be the best solution. In the top, there would be one bar of 16 cells horizontally. Clicking on specific cell would open the loading dialog and would load sample into that specific channel. It would also mark filled/empty channels. Below that, there would be a list of loaded samples, in exactly the way you made it. It both avoids unnecessary empty space, adds speed benefit and preserves clarity. Also there may be more than one way to add a wav file. Clicking the channel cell would be the "fast" way and clicking a usual "load wav" button somewhere would be the "clear" way. This behaviour would be consistent with my d) point - giving user an option to discover "tricks" that he may opt to use if he wishes to.
Another idea might be to replace the horizontal channel selector for each wav with simple "icon" on left of the wav name. The icon would show the channel number and would be horizontally dragable. While dragging, the top "channel cell bar" would be specially highlighting where the edited wav is currently.

tulamide wrote:I'll do whatever you want. It is your baby after all. But if we sacrifice clarity and clutter the surface for the sake of speed, I won't be in wholeheartedly. This could mean I don't give 100%. Not on purpose, just un-consciously.

I apologize if I sounded dictatorial about the design. I'm just throwing ideas in here for "peer review". This whole plugin was inspired by lack of certain features (or hardship of achieving them) in samplers I've worked with in practice. That may result in me overemphasising them (my original GUI is a testament to this ). Naturally, two heads are more than one, so don't shy from calling me out, when I'm making bad design choices

tulamide wrote:(If you ever played a song with your band that the other members liked, but you didn't, then you know what I mean)

Yeah, in fact, that one hit pretty close to home. Last week I left my metal band after 3 years, because I wasn't comfortable with the direction the band is heading musically. I promised to de-facto stay as a song-writer, but it's probably just a "buffer zone" to deal with the change.