Bug description (state clearly and simply):
Sampler waveform visualiser is not consistent, it displays 2 colours in some samples and blue or red colours in others + sometimes an empty square grid is visible.
Steps to reproduce (use numbered list):
Try loading different samples into sampler and see wether visualisation remains consistent.
So yeah, as discussed and requested, here’s the summary of my explanation/demo of the issues with the current waveform display:
The two-color stuff is unnecessary and confusing. We don’t need separate channels shown individually. It just needs to be a single, monochromatic and high-contrast conventional waveform draw, like the ER-301 is, and should allow easy and fast zooming (via, say, Left Shift + Turning Encoder) in down to the single-cycle level and (and back out), which should itself be represented as a single line. To quote Spinal Tap, “Simple, beautiful, classic.” No greater graphic detail is necessary - if we’re doing critical editing, it’ll be on a computer anyway. This is all about easy, fast and precise selection of lengths and defining loop points, etc.
I don’t need to see empty space in a layer of the sampler to indicate that there is a sample longer loaded into the sampler module. I think since I loaded them up I would know if their lengths were mismatched and this dead space after a short(er) Sample is useless to me IMHO.
Again, going back to the design of the (multi-)sampler itself… sharing these parameters across all eight samples provides convenience but not creative control over each sample which I would prefer myself.
I know that I could load multiple sampler modules each with one sample in them giving me this control of their individual parameters. Maybe having a delay in seconds/millisecond that you can apply to each sample before it starts might be a good thing as an option to align sample layers and/or add more creative effects like chorusing, flanging, delay when loading up similarly long samples?
There was a lot of thought that went into these kind of decisions. The reason this was done is so you could see where the sound starts in each channel when you zoom in, which makes it easier to accurately set the start point. If you don’t draw all the channels in different colours then the channels have to be averaged before drawing which might be less accurate.
But we will change this and just show the averaged data. Once this is done we won’t be able to change it back to how it was so hopefully no-one has any objections
On the SSP we have a colour display as well as the processing power to do more advanced visualisations (such as drawing every channel in a different colour, overlayed), which is why we implemented it like that. We have the possibility to innovate because of what our platform offers.
You can already go faster with the encoders when you turn them. When you push the zoom encoder it zooms in to the maximum level and pressing it again brings you back to the top level.
As far as I know we haven’t reached a decision here in the forum (see other threads on this including Push + Turn = Super Speed) on whether it should be SHIFT+encoder or whether it should just be a matter of turning faster to increase the parameter step. In any case it has to work accross all parameters, not just the zoom parameter.
Also, it is important to think about this carefully because if we implement this using the SHIFT key and then later on find a situation where the SHIFT key is needed for something else we might create additional work to re-engineer a bunch of stuff which eats away development time
The reason for this is that the start and length and xfd parameters work across all the slots of the sampler. There is only one start and length value calculated using the parameter and the length of the longest sample loaded.
In the previous implementation start and length would be calculated using the length of the sample in the slot, so the result was that a start of 0.3 and length of 0.4 for example would mean something totally different per sample slot, so start and length would jump all over the place as you paged through the sample slots.
There was confusion about how this worked, as reported here in the forum, so I changed the implementation to what it is today. We really thought hard about how to handle this and decided on using the length of the longest sample loaded to draw all the samples, drawing an empty region where necessary to make it clear that if you moved start/length it might end up in an empty region in one or more of the sample slots.
I could simplify the sampler module by removing the slots, so there is only one slot, and then there is no need to draw empty regions and the sample always fills the entire display. There will then only be one gate input and no 8 individual gate inputs (which was implemented before and requested by @SSPix@tiger001 and possibly others, to facilitate situations where you need percussion samples and want to load them into one sampler instance).
Additionally by removing the slots you will have less creative possibilities IMHO and might have to build some of what you now have in the patcher yourself.
I think that is a job for a simple delay module and from what I remember that is one of the modules that we were going to implement as part of the KS. Of course, getting to the implementation of those modules depends on how much other UI or workflow tweaks that have to be implemented
Not if they’re displayed as two different colors overlaid on each other. If we’re gonna have multiple channels displayed discretely, better to do it in the conventional manner where they each get their own “lane”, one under the other. I have no problem with that, but color thing doesn’t work for me at all.
I would prefer to have this option for percussive elements.
Keep up with the implementation, we can all work around as is until such time comes for workflow tweaks. I see this as a must for your company as the more modules available becomes more of a selling point. Or, you could work 24 hours a day and do both
we are talking other elements than waveform visualization here
but, to add to the confusion:
layering samples in one instance is an absolute must + can be a starting point for (coding) spread (over the keyboard) multisamples later
a simple delay parameter(pos & neg) should not be a separate module but incorporated in the 8 (separate!) layers
we are talking starting a sample later/sooner, not repeating a signal
i also find it strange that start & length parameter is for the 8 slots combined, in relation to the longest sample loaded - i’m sorry if this is due to my request earlier - so what if the parameter is jumping all over (pages) if different length samples are loaded, you load more different length samples than same length (in same instance) anyway
I think that splitting the current Sampler module into two different modules; Single & Multi might be a solution here. If we could have a Simple or Single Sampler module that only has one sample for the times when you don’t need anything else I believe that would be useful, at least for me anyway. Just make it lean and mean and without seeing all of the other ‘empty’ layers that you’d see now when only loading up one sample into the current modules design.
Obviously people like the functionality that the current (Multi) Sampler module has, myself included, so please don’t get rid of it! We’re just trying to make it better so it works for everyone which of course will take time to iron out the kinks and evaluating everyone’s opinion.
+5 @Mercurial This would be awesome to see the waveform overview of each sample loaded then you could see how long each sample is in relationship to each other. Obviously the SSP has plenty of screen real estate to accommodate this functionality, right? Here you would see vibrantly colored vertical lines that shows the start/length/xfd that are shared for all the samples loaded. Then just imagine that on each sample lane you could have the option to set another parameter called “start offset” that (indicated where in relation to the rest of the main/or current start/length/xfd settings are…) would advance or retard the current layer in relation to the main shared start cursor. Make sense?
Well, it’s important to be clear here about the use case -
I myself am not even thinking in terms of multiple independent samples loaded into a single instance of SAM (though I realize others may well be doing this) - I’m just trying to, as you say,
get the basic SAM functionality lean and mean for one mono/stereo/n-channel sample at a time.
I would start from that point and then move on to multi-sample handling after the basics are covered. To me, “basics” here means simple, smooth and clear waveform drawing as already specified, including easy zoom in/out, and the crossfade looping (which I haven’t had time to check out, but will today.) I don’t have a problem with purpose-built variations on SAM for different situations and material - the ER-301 has a few types of sample players - so that could well make sense. However, it would be most efficient to make a single instance of SAM have all the various functionality we’re positing here (multi-colored individual sample layer display, for instance) available with user checkboxes from one basic SAM module. So for instance, let’s say you start off with the simplest possible use case, which is loading one mono sample into a SAM just to play it by itself. You’d only see the one sample’s waveform drawn as specified, and that would be that, until you decide “hey, let’s add more sample layers, since I now want to deal with multiple samples.” At that point, you could simply choose “New Layer”, and add a sample to it, which would add a lane to the waveform display (colored differently or not, based on user preference), and keep doing this until you reach the max # of layers. And of course, the 8 total layers could be subdivided however you like, among any combo of mono/stereo/n-channel samples totaling 8. Maybe then you’d have the relative offsets you posited, as well. This way, you only need one type of SAM for these varying situations, and its functionality would be “expandable” at will, as you work, though the expanded functions would remain hidden until you actually needed them, keeping the UI as simple as possible for the situation at hand. It’s important to mention here that you also could opt to use the individual display lanes for single n-channel samples (from mono/stereo up to the 8 possible channels of .wav files that the SAM supports. Super useful.) Thoughts?
+1 @Mercurial I agree with the idea to get the basic traditional sampler functionality ironed out first (lean & mean) and then start expanding features once everyone is in agreement first. While an 8 channel multi-sampler with individual parameters and waveforms with delay/offsets is something that would be awesome let’s send a couple dogs into space first before we try to land on the moon. We’ll get there no doubt (and we are really close right now) but like @Mercurial said let’s concentrate on the core and simple functionality first. ️
the sampler already has the ability to load multiple samples in 8 different slots, but the confusion here is about what the meaning of start and length is, given that those parameters are shared across all 8 samples, and that those samples have different lengths when they are loaded. It seems users also want to modulate the 8 sample slots seperately which means that the sampler should be reduced to loading just one sample, so no more 8 slots per sampler. However, @tiger001 and @IvanS want to have multiple slots per sampler because they want to load drum sets and having to do that with multiple sampler modules becomes tedious for them.
This implies a lot of user interface / logic changes to how the sampler works and will require significant development. I think all of this can be done with the sampler how it is right now, the idea is that users build patches in the grid instead of us implementing more logic within the sampler module. We just have to address the above questions and issues that I mentioned.
The “slots” that are now in the sampler could be used for displaying the channels of the sample. But that means the sampler can then only load one sample, and not 8 individual ones like it can right now.
right now, the sampler offers you a lot of flexibility and all scenarios are covered. For some you have to use multiple sampler modules, but that is unavoidable. If I change the sampler so you can only load one sample, it will mean more work for some users, so nothing is gained IMHO.
displaying multiple channels or samples under each other in the sampler module won’t work because vertically there is not that much space. You could put multiple samples next to each other, because the display is wide, but that will be confusing I think.
if you load 8 drum samples, and you change start and/or length, and the actual length of the 8 samples is different, those start and length parameters will have a different meaning for those 8 samples. let’s say you have 2 samples with length 50,000 and 100,000 samples, and start and length are set to 0.3, for one sample you will have 0.3x50000 = 15000 and for the other 0.3x100000 = 30000. This means that your drum samples won’t start at the same “time” in those 8 samples which is probably great and interesting if your samples are pads or strings or textures, but not so great if we are talking about drum samples.
so that is why the logic has been changed from what it was (explanation above) to what it is now: there is an empty region shown in some samples if the loaded samples are different in length, and start and length are relative to the length of the longest sample loaded such that they mean the same thing across all samples (i.e. the start time is the same).