xen osc | using random vals for x and y values

Question

hello,

i just try to create a adsr envelope with random attacktime using the xenoscillator.

running the xen with  a 1 hz frequency and using

{(((1 hz tick) nextRandom) * 0.5 - 0.5)}  

as the apropriate xvalue for the attacktime, results in a curvy envelope with alot of jittering. even though the other x + y values are set to fixed values and xen´s smoothing param sits at its default value of 0.5 (linear transitions).

what i expected was a adsr env with andom attacktimes for each new cycle (at 1 hz). maybe the frequency of the xenosc and the frequency of the random expression doesnt match?
any ideas how to fix that?

thanks, jo

Comments

"{(((1 hz tick) nextRandom) * 0.5 - 0.5)}  as the apropriate xvalue for the attack time"
Where (which parameter field & in which Array position) is this value used?

Is your goal to have an ADSR that repeats once per second and has a random attack time?

---

thanks for your reply,
the random attack expression was used directly in the xvalues field at the 2nd position. 
using a constant prototype with the same expression ( without the curly braces) works better… i.e.-. lesser jittering. but very  irregular it creates a single spike or a curves, specially with bigger random values…

here is how the xvalues param field now looks like:

-1
{ [constant prototype with random attack expr] L }
{(( [constant prototype with random attack expr] L + 1) + !Decay) - 1}
{(([ constant prototype with random attack expr] L + 1) +  !Decay + !Hold) - 1}
!Release 

and the yvalues field:

0
1
!Sustain
!Sustain
0
0

here is the sound … just in case. 

http://kyma.symbolicsound.com/qa/?qa=blob&qa_blobid=1573422871462901598

ps.  yes, what i had in mind was a adsr with random attack that repeats each second.

---

Why don't you use the AR prototype and use the same trigger for triggering the envelope and for getting a new random value for the attack time? Easier to handle and you can have exponential slopes

---

cause iam interested in random based envelopes with more than 4 segments. i also thought about lfos with custom made waveforms and changing freqrates, and amplitudes over time for more complex modulations. here is something very similar for max:

http://designingsound.org/2013/04/generating-complexity-in-max/

---

Just skimmed through as I'm not really familiar with max but I'm surr you can do the same with kyma by using some xenOscs and function generators and combine them in various ways. Have fun!

Answer 1

Here's the way I would think of it (very similar to what you are already doing).

First, we want something that repeats at a constant rate (once per second).  Then we want to warp it a little (creating random attack durations, leaving the other durations alone).  Whenever I think of warping, I think of the InputOutputCharacteristic.

So I took the OscillatorTimeIndex as a linear time index.  Then warped it through the InputOutputCharacterstic mapping InValues:

{| atkDur p |
atkDur := (1 s random seed: 997) abs vmin: (1 - !DecayDur - !ReleaseDur).
(Array  with: -1
        with: (p := -1 + (2 * atkDur))
        with: (p := (p + (2 * !DecayDur)) vmin: 1)
        with: (1 - (2 * !ReleaseDur) vmax: p)
        with: 1)}

so the start and end times (-1 and 1) are fixed.  The interior points are warped, depending on the random duration of the first segment.  We pick a random atkDur, then the release segment has to move right or left depending on the length of that atkDur segment.  The releaseDur segment is computed relative to the last point (which is the end of the envelope).

The OutValues give the levels of the ADSR: 0 at the begining, 1 by the end of the attack, a sustain level under control of a fader, and 0 at the end of the envelope.

0 1 !Sustain !Sustain 0

This gives a steady, repeating envelope whose internal segments are warped according to the random duration of the attack.

Here's an example.

Comments

your usage/reassigning of p is really clever ;) makes the whoke thing really readable and slick

---

oh and while we are at it: the update field of the IOCharacteristic should be samplerate so you can update the warping function only when the ramp at the input resets. I can't think of another way to handle it, do you?

---

ah, this is a great sound ssc. i like the logic as well. until now i didn't fully understood the io characteristic. :-) this is pretty good explanation of it. thanks.

it seems that for my task the osc-timeindex and io-car combi does the same thing as the xenosc… but maybe is bit more flexible, is that right? or is there a specific difference of this to alternatives i should be aware of?