As of the current 1.5 Play firmware I believe that the Sample Attack and Decay settings are linked directly to the absolute start and end of the sample. This makes manual adjustments to the Start and End points and features like Random Sample Length far less intuitive and useful. In the case of Randomized Sample Length, there is no automatic means of smoothing the glitches from the randomly selected start and end points.
I was trying to create some quasi-granular effects with Sample Length randomization coupled with various Repeat structures. The results were very glitchy indeed. I assumed I could have the Randomizer chip the sample randomly and I would just apply a small Attack/Decay slopes to both ends to smooth out the glitches.
Proposed Relative Attack/Decay:
If the Sample Attack and Decay slopes could automatically follow the currently selected Sample Start and End points the “envelope” of the sample would be maintained regardless of Randomizing or manual adjustments to Start and End points. I would think this mode would be preferable as it makes the Attack and Decay settings more intuitive guaranteeing a slope up from 0 at the start and down to 0 at the end for any chosen start and end positions.
Update:
Maybe I’m not testing this correctly. Maybe it already is Relative and I’m just hearing unexpected results in this test. Still, even if set to 100%, the Decay appears to have little effect when chopping up a sample like this with Randomize Sample Length and that doesn’t seem to make sense.
I was wrong. The Attack and Decay slopes are already linked to the current Sample Start and End points. Nice job Polyend.
I was really hoping to use a long sample, chopped up via the Sample Length Randomizer and Repeats and then to smoothly fade in and out creating an envelope for this short, randomly selected Sample segment. The Attack slope does smooth the initial Sample glitch but since the repeats are very short, the randomly chosen Sample End is often nowhere close to the end of the repeat so the sample cuts off abruptly before it can reach the Decay slope.
The overall effect is still interesting but what I really need for a quasi-granular effect is a Fixed Length Sample Segment Randomizer and we don’t have that option. Too bad, it would be cool.
I once wanted to make a feature request that, instead of Sample Start and Sample End, there would be Sample Start and Sample Length controls. Effective sample end is just Sample Start + Sample Length. In this paradigm, positive Sample Length would make a sample to play forward, and conversely, negative Sample Length would make it play backwards, i.e. reverse. Dead simple.
First of all, it’s convenient, so if you want to play a different slice of a loop, you’d just need to move Sample Start and keep Sample Length intact. Fow now you have to adjust both.
Secondly, randomization/chance algorithms that affect sample position and timing would be much more usable and manageable.
There is an open question though as to how playback should behave when effective Sample Start + Sample Length exceeds actual sample length. For example, the sample is 1 sec long. Sample Start = 800ms, Sample Length = 400ms. I think in this case sample should play to the end and then fold back and play in reverse those missing 200ms.
sample length instead of sample end is a good idea .but when u have selected a track with different samples it will become relative in % not in ms for samplelength .right?
I don’t think this is quite as simple as it seems. (I think playing reverse may not be so simple as well, but that’s another thing.) The sample start and end points are not defined in time, but by samples (ie: in the sample rate of 44100hz). This makes sense when samples are played at different speeds for different pitches - times are changed, but sample points remain the same. We would need to take this in account in considering what is desirable. If you define the length played by time you may end up with undesirable effects. I can see the point of what you want - just not sure if it would be a good idea.
The sample start + samle length combo would work the exact same way as sample start + sample end works. It’s just a different representation of the same thing. Sample start = 500ms & sample length = 200ms is identical to having sample start = 500ms & sample end = 700ms. Actual sample length depends on the pitch. If you play C2, the sample length would effectively double just like with the current approach.
Here I was really overthinking. No issue at all. The knob won’t let you exceed actual sample length just like now you can’t set sample end that is longer than sample length.
That’s true from the users point of view - it might not be the same for the audio engine. It may not care about milliseconds at all, only what frame is to be played next and when, according to the internal cpu clock, (taking in to account to whatever pitch bend may be required). All I’m really saying is that something that may seem straightforward to us may have consequences.
