new user: Ugen / arate / krate constant rate random walks

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

new user: Ugen / arate / krate constant rate random walks

bloodymortimer
I would like to produce a random walk at audio & / or control rate ...

& the distinction i draw here between this & interpolated noise is that i
want the rate of change to be constant ... i.e. i want a jump from 0 to 1 to
take 10 times as long to execute as the walk from 0 to 0.1.

Applying a filter to LFNoise1 i guess could be a way to control the wide
leaps, but it would be much more elegant (& precise) from my perspective to
simply set a rate of traversal, & then next random value is generated at the
appropriately designated times / points.

Pwalk is the conceptual fit, but i am looking to create continuous
transitions in a SynthDef at audio rate most likely (i will shape the linear
output to provide a slow drifting dB modulator, but so that the rate of
drift remains constant / definable at x dB/second ...)

{Postscript: in browsing the extended documentation online, i found a
reference to http://doc.sccode.org/Classes/LFBrownNoise1.html - i think this
might be close to what i am looking for, but I'm not 100% sure ... if so, i
am happy to attempt to install the "Gendyn distributions" (?) & explore
further ...}



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

daniel-mayer

Am 05.02.2018 um 09:39 schrieb [hidden email]:

I would like to produce a random walk at audio & / or control rate ...

& the distinction i draw here between this & interpolated noise is that i
want the rate of change to be constant ... i.e. i want a jump from 0 to 1 to
take 10 times as long to execute as the walk from 0 to 0.1.

Applying a filter to LFNoise1 i guess could be a way to control the wide
leaps, but it would be much more elegant (& precise) from my perspective to
simply set a rate of traversal, & then next random value is generated at the
appropriately designated times / points.

Pwalk is the conceptual fit, but i am looking to create continuous
transitions in a SynthDef at audio rate most likely (i will shape the linear
output to provide a slow drifting dB modulator, but so that the rate of
drift remains constant / definable at x dB/second ...)

{Postscript: in browsing the extended documentation online, i found a
reference to http://doc.sccode.org/Classes/LFBrownNoise1.html - i think this
might be close to what i am looking for, but I'm not 100% sure ... if so, i
am happy to attempt to install the "Gendyn distributions" (?) & explore
further ...}


Accidentially I stumbled upon the same question some days ago. I got this functionality with a combination of Demand, Integrator and Fold and then defined it as a pseudo ugen. This is a kind of macro that builds a block of ugens in the described way when used within a SynthDef.

You can copy the code below, save it as an .sc file within the "Extensions" folder and recompile SC (for finding the Extensions folder see the help file "Using Extensions", you might have to generate it newly).


////////


// new1 and multiNew look opaque, but they just ensure multichannel expansion


BrownSweep : UGen {
*ar { |trig, rate = 0.00001, lo = -1, hi = 1, lag = 0|
^this.multiNew(\audio, trig, rate, lo, hi, lag)
}

*kr { |trig, rate = 0.00001, lo = -1, hi = 1, lag = 0|
^this.multiNew(\control, trig, rate, lo, hi, lag)
}

*new1 { |rate, trig, bsRate = 0.00001, lo = -1, hi = 1, lag = 0|
var add, sig, selector = this.methodSelectorForRate(rate);
add = Demand.perform(selector, trig, 0, Drand([-1, 1], inf) * bsRate);
sig = Integrator.perform(selector, add);
^Fold.perform(selector, sig, lo, hi).lag(lag);
}
}



BrownSweep2 : UGen {
*ar { |trig, dem = 1, lo = -1, hi = 1, lag = 0|
^this.multiNew(\audio, trig, dem, lo, hi, lag)
}

*kr { |trig, dem = 1, lo = -1, hi = 1, lag = 0|
^this.multiNew(\control, trig, dem, lo, hi, lag)
}

*new1 { |rate, trig, dem = 1, lo = -1, hi = 1, lag = 0|
var add, sig, selector = this.methodSelectorForRate(rate);
add = Demand.perform(selector, trig, 0, dem);
sig = Integrator.perform(selector, add);
^Fold.perform(selector, sig, lo, hi).lag(lag);
}
}


//////////


WARNING: with low slope values resp. low rates you can easily produce unwanted DC offsets !


BrownSweep is for passing slopes BrownSweep2 allows to pass sequence definitions of slopes per demand rate ugens.


{ BrownSweep.ar(Impulse.ar(500), 1e-3) }.plot(0.3)
{ BrownSweep.ar(Impulse.ar(500), 3e-3) }.plot(0.3)

{ BrownSweep.ar(Impulse.ar(500), 1e-3) ! 2 }.scope

You'll notice high frequencies occuring in above example. This inevitably comes from folding to a given range. We can avoid that by taking a slope in a way that bounds are a multiple of the value changes from trigger to trigger.


E.g. with a sample rate of 44100 and a trigger rate of 441 the values change in steps of exactly 0.1, so folding from bounds -1, 1 doesn't produce "intermediate" peaks.

{ BrownSweep.ar(Impulse.ar(441), 1e-3) }.plot(0.3)

{ BrownSweep.ar(Impulse.ar(441), 1e-3) ! 2 }.play


BTW: See also DemandEnvGen, it is useful for defining stochastic waveforms


Regards

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------





  
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

daniel-mayer

... I forgot the BrownSweep2 examples

{ BrownSweep2.ar(Impulse.ar(500), Drand([1, 3] * 0.001, inf)) }.plot(0.3)
{ BrownSweep2.ar(Impulse.ar(500), Drand([1, 3, -1, -3] * 0.001, inf)) }.plot(0.3)

{ BrownSweep2.ar(Impulse.ar(441), Dseq([1, 2, -1, Drand([0, -2], 1)] * 0.001, inf)) ! 2 }.play


Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------

Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
In reply to this post by daniel-mayer
BAM!

wow, impressive.

i almost feel that might be a little deep for me just at the moment ... &
it's a little disheartening to hear that this was indeed such a problematic
exercise, but in due course if this proves to be best option, once i get a
bit more SC experience, great, i'll give it a go!

the 'On Demand' / D this'n'that Ugens i was looking at ... may i ask briefly
what the easiest solution is to simply demand at krate &, if feasible, arate
from those Ugens?

in the meantime, for prototyping purposes, i may simply look at generating
random envelope trajectories ...

will there be some sort of conflict that arises if i set \durations &
\deltas in significantly shorter time spans in comparison to the envelope
times? (say a 20 second envelope trajectory provided to a note of duration
10 seconds ...) (apologies for the speculative query here ... i'm about to
head to bed so no more SC dabbling for me this evening ...)

perhaps to ask that another related way, will smooth releases be executed
even if the sustain envelope point is not reached? (indeed, this will be my
next experiment tomorrow evening to check all this out ...)







--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

daniel-mayer



Am 05.02.2018 um 12:31 schrieb [hidden email]:

the 'On Demand' / D this'n'that Ugens i was looking at ... may i ask briefly
what the easiest solution is to simply demand at krate &, if feasible, arate
from those Ugens?

E.g.

{ Duty.ar(SampleDur.ir, 0, Dseq([1, -2, 3, -4, 5])) }.plot(0.0002)

{ Duty.kr(ControlDur.ir, 0, Dseq([1, -2, 3, -4, 5])) }.plot(0.02)


in the meantime, for prototyping purposes, i may simply look at generating
random envelope trajectories ...

will there be some sort of conflict that arises if i set \durations &
\deltas in significantly shorter time spans in comparison to the envelope
times? (say a 20 second envelope trajectory provided to a note of duration
10 seconds ...) (apologies for the speculative query here ... i'm about to
head to bed so no more SC dabbling for me this evening ...)


In some cases you hit limits e.g. with envelope segments shorter than control duration,


Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------

Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

Glen Fraser
I would like to produce a random walk at audio & / or control rate ...

& the distinction i draw here between this & interpolated noise is that i
want the rate of change to be constant ...

That sounds like exactly what Slew (kr, ar) is for: setting the slew rate (aka the maximum rate of change of a signal).  So maybe something like this would be another approach?

(
// Random walk (from -24 to 0 dB) with maximum rate of change of 6 dB/second
{
var rndImpulse = Dust2.kr(5, 0.4);
// Or, if you prefer a constant-rate random impulse, swap for this:
// var rndImpulse = HPZ1.kr(LFDNoise0.kr(5, 0.5));
var rndWalk = Integrator.kr(rndImpulse, 1).fold(-2, 2).linlin(-2, 2, 0, -24);
var slewWalk = Slew.kr(rndWalk, 6, 6);
[rndWalk, slewWalk];
}.plot(duration: 4, minval: -24, maxval: 0)
)

You can also specify different up versus down slew rates, e.g. if you wanted the volume to go up slower (3 dB/sec) than it goes down (18 dB/sec):

var slewWalk = Slew.kr(rndWalk, 3, 18);

Hope that helps,
Glen.


On Mon, Feb 5, 2018 at 1:12 PM, <[hidden email]> wrote:



Am 05.02.2018 um 12:31 schrieb [hidden email]:

the 'On Demand' / D this'n'that Ugens i was looking at ... may i ask briefly
what the easiest solution is to simply demand at krate &, if feasible, arate
from those Ugens?

E.g.

{ Duty.ar(SampleDur.ir, 0, Dseq([1, -2, 3, -4, 5])) }.plot(0.0002)

{ Duty.kr(ControlDur.ir, 0, Dseq([1, -2, 3, -4, 5])) }.plot(0.02)


in the meantime, for prototyping purposes, i may simply look at generating
random envelope trajectories ...

will there be some sort of conflict that arises if i set \durations &
\deltas in significantly shorter time spans in comparison to the envelope
times? (say a 20 second envelope trajectory provided to a note of duration
10 seconds ...) (apologies for the speculative query here ... i'm about to
head to bed so no more SC dabbling for me this evening ...)


In some cases you hit limits e.g. with envelope segments shorter than control duration,


Greetings

Daniel

-----------------------------
www.daniel-mayer.at
-----------------------------


Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
The journey so far ...

essentially, this is a kind of 'pseudo granular' set up i guess ... just
with long, streaming, retriggering 'sine - tides' ...

i am curious now to determine how difficult it might be to 'internalise' the
whole retrigger process within a single event call to an expanded SynthDef
that incorporates its own internal event rescheduler ... this would avoid
the need to polyphony manage, assign Groups etc as discussed back in the
initial post (where i endeavour to change chords on this process essentially
... hopefully in real-time & sequencing contexts ...)

the Slew thing needs a bit of work but it was very much in the ballpark & a
nice illustrative example for a number of reasons, thank you Glen. I will no
doubt get to Rolling my own Ugens Daniel, however at this stage it is very
much still a case of minimising potential sources of error ...

anyway, 'end of chapter 1', & now i have proved to myself something like
this is possible & relatively painless to execute, i think i will backtrack
through some basics of Patterns & Envelopes & Gates & triggers etc for a bit
... more conventional initiate level stuff ... Sample loading ...
dictionaries ...

but at the same time if anyone can see a way to 'encapsulate' this
functionality within single Event drivers then i'm happy to learn more on
the topic ... so here's the 'design sketch number 1' & thanks to you all for
helping me focus my initial explorations in a more directly relevant way.

(

~slew_wanderer = {

        //
http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/new-user-Ugen-arate-krate-constant-rate-random-walks-td7637798.html#a7637809

        var rndImpulse = Dust2.kr(5, 0.4);
        var rndWalk = Integrator.kr(rndImpulse, 1).fold(-2, 2).linlin(-2, 2, 0,
-18);
        var slewWalk = Slew.kr(rndWalk, 2, 2);
        slewWalk

};

SynthDef.new(\drifty_mcdriftface, {

        | freq = 440,gate = 1 |
        var sig,env,envgen;

        env = Env.adsr(0.01,0.3,0.4,0.1);
        envgen = EnvGen.ar(env,gate, doneAction:2);
        sig = SinOsc.ar(freq, 0, 0.1);
        sig = sig * envgen;
        sig = sig * ~slew_wanderer.value.dbamp;
        Out.ar(0,sig!2);

}).add;


// a function with arguments
~pow2dist_args = { arg exp;  2**rand2(exp) };


~pbindtemplate = {

        arg mn;

        Pbind(

                \instrument, \drifty_mcdriftface,
                \midinote, mn,

                // the function with arguments returns a value
                // so it needs to be set inside another function
                // (also note the dot between function & argumets)
                \dur, Pfunc({~pow2dist_args.(6.0)})

        );

};

// ******************************************
// the p-bind return is an EventStreamPlayer

~vox_a = ~pbindtemplate.value(54);
~vox_b = ~pbindtemplate.value(57);
~vox_c = ~pbindtemplate.value(59);
~vox_d = ~pbindtemplate.value(61);
~vox_e = ~pbindtemplate.value(64);

~vox_a.play;
~vox_b.play;
~vox_c.play;
~vox_d.play;
~vox_e.play;

)











--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
sorry, postscript ... in terms of MIDI control, that current version probably
works quite well as a template ... each key down spawning a new Pbind with
the key number passed in as the parameter ... Perhaps that's simply the
model for the 'scene changing' version also ...

then there's plan B .. where a single trigger attacks all active notes /
pitches, but monophonically, so more like a random arpeggiator ...





--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

ddw_music
In reply to this post by bloodymortimer
bloodymortimer wrote
> i almost feel that might be a little deep for me just at the moment ... &
> it's a little disheartening to hear that this was indeed such a
> problematic exercise, but in due course if this proves to be best option,
> once i get a bit more SC experience, great, i'll give it a go!

Every system makes some things easy and other things harder... and when
you're starting out, you have no way to guess what is easy and what is hard.

For this problem, I would generate envelope breakpoints that meet the slope
requirement (using D* units) and feed them to a DemandEnvGen unit. (I'm
surprised nobody thought of DemandEnvGen so far in this thread.) E.g.,

1. Calculate the time until the next breakpoint.

2. If the maximum slope is +m or -m, then the maximum distance to travel in
this step is +-m * time... which becomes a random number boundary.

3. The "traveling" is done by an integrator: in D* terms, a Dseries.

The D units get tricky when you need the same result in multiple places --
here, 'time' influences both the maximum step size and the envelope segment
duration. We usually use Dstutter to repeat values. I'm not at my computer
now so I can't hack up a quick demo, but I think this approach would give
you exact control over the slope.


> the 'On Demand' / D this'n'that Ugens i was looking at ... may i ask
> briefly what the easiest solution is to simply demand at krate &, if
> feasible, arate from those Ugens?

To calculate sample-by-sample values from D units: Duty.ar(SampleDur.ir,
...). Not fast but it works, at least for short synths.


> will there be some sort of conflict that arises if i set \durations &
> \deltas in significantly shorter time spans in comparison to the envelope
> times?

No, these are all fine.

Releases: An envelope segment is always:

- Start: The envelope's current value. (NOT the previous breakpoint value.)
So it's always continuous.
- End: The next breakpoint value.
- Time.
- Curve type.

hjh

PS Sorry if this is a duplicate post -- unstable network at the moment.



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
Thanks for those suggestions Dr. HJH ... (just Googled ...)

As i want to get to grips with the nuances of exploiting the envelopes, i'll
explore this strategy as an alternative design. Or rather perhaps (more in
line with the second half of your reply ...) simply generating trajectories
(as per your algorithm ...) & passing them in to the amp envelope of the
synth as arguments on a note by note basis ... especially if this 'value
pickup' behaviour is available out the box ...

I think the aim here really is to come up with some templates that
approximate my (not entirely earth-shattering) 'legacy' ideas from csound, &
refine them into specifics as the picture emerges of where SC is going to
enable me to hopefully push & develop my ideas into something more
accomplished. Hence this opening salvo of 'strategy surveys' on my part ...

Basically I am beginning to suspect i was reinventing a large part of the SC
language wheel in Python (including classes for 'event', 'stream' ... etc
..), & without the realtime interactivity ... & if it ever proves necessary,
i can always explore driving csound from S.C. via OSC ... but the reality is
FFT & sine waves represented 95% of what i did with it ... & using it to
convert .txt files of generated score to MIDI ...











--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Aw: [sc-users] Re: new user: Ugen / arate / krate constant rate random walks

daniel-mayer
In reply to this post by ddw_music

> Gesendet: Dienstag, 06. Februar 2018 um 11:16 Uhr
> Von: [hidden email]
> An: [hidden email]
> Betreff: [sc-users] Re: new user: Ugen / arate / krate constant rate random walks
>

> For this problem, I would generate envelope breakpoints that meet the slope
> requirement (using D* units) and feed them to a DemandEnvGen unit. (I'm
> surprised nobody thought of DemandEnvGen so far in this thread.) E.g.,


Well I pointed to it :)

... though I didn't give an example.
Definitely DemandEnvGen is a versatile UGen for that kind of meta control.


> Gesendet: Dienstag, 06. Februar 2018 um 10:24 Uhr
> Von: [hidden email]
> An: [hidden email]

>
> i am curious now to determine how difficult it might be to 'internalise' the
> whole retrigger process within a single event call to an expanded SynthDef
> that incorporates its own internal event rescheduler ... this would avoid
> the need to polyphony manage, assign Groups etc as discussed back in the
> initial post (where i endeavour to change chords on this process essentially
> ... hopefully in real-time & sequencing contexts ...)

Your example leads to a decision often to be made in SC: should we do things via server or language ?

There's no general answer, sometimes it's a matter of taste, sometimes there are good reasons to do it here or there, often tasks can be split. You'll find your prefered answers after working a while in SC. However I think combinatorial stuff (everything that can smoothly be done with help of SC's smart
array methods, especially harmonic calculations etc) is far more convenient to be done in language.

Regards

Daniel

-------------------------
http://daniel-mayer.at
-------------------------





_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: Aw: [sc-users] Re: new user: Ugen / arate / krate constant rate random walks

ddw_music
daniel-mayer wrote
>> For this problem, I would generate envelope breakpoints that meet the
>> slope
>> requirement (using D* units) and feed them to a DemandEnvGen unit. (I'm
>> surprised nobody thought of DemandEnvGen so far in this thread.) E.g.,
>
> Well I pointed to it :)
>
> ... though I didn't give an example.
> Definitely DemandEnvGen is a versatile UGen for that kind of meta control.

I missed it then... certainly DemandEnvGen didn't get the attention it
deserves, for this use.

(
a = { |maxSlope = 1|
        var time = Dstutter(3, Dwhite(0.05, 0.1, inf)),
        maxStep = time * maxSlope,
        step = Dwhite(maxStep.neg, maxStep, inf),
        accumulator = Dseries(0.5, step, inf);
        DemandEnvGen.ar(accumulator, time)
}.plot(duration: 0.25);
)

This almost works, but there's a weird off-by-one bug in Dstutter. I'll log
it.

hjh



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
Reply | Threaded
Open this post in threaded view
|

Re: Aw: [sc-users] Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
OK back to tick this one off the list.

Thanks HJH ... i like this but i think (as a positive rather than a
negative) this gives me another slight variant to explore, as i realise my
original idea (to express perhaps more clearly ...) was simply to have
constant 'slope' in the +ve or -ve direction between random points. But the
simplicity of execution & true 'demand' like nature of what you have done (&
the resultant plots ...) appeal ...

i have prototyped the below (which i add here for completeness but also i
think it demonstrates i am beginning to piece the concepts & syntax together
more effectively ... so hope to demonstrate i am beginning to benefit from
the tutelage ...)

But it's not a true 'on demand', but i think doing it this way would still
enable greater flexibility than generating stock EnvGen trajectories for
each note (in a Synth Def they would be limited to a fixed number of
breakpoints i believe?)

anyway, this is the kind of behaviour i was after, & i assume the Dstutter
'bug' you report is to do with the fact that, as Daniel was explaining to me
in the context of my crossfading 'quasi-granular' discussion, "Drate ugens
behave like streams in the language. If you poll them twice they are
forwarded twice." ... are you perhaps, in your example code, polling 3 times
(?) or is there indeed a bug ...

Here's my take. As a learning exercise, if there is a way to achieve this as
a 'pure' on demand i'd be happy to hear of it ...

(


~trajectory_calc = {

        // dBs per second
        |time = 60, rate = 1, dbrange = -24|

        var dBnext, dBnow, dBdistance, tnext, tdifference, dBlist, tlist, tnow = 0;

        dBlist = List(0);
        tlist = List(0);

        dBnow = rrand(-24,0);
        dBlist.add(dBnow);

        while ({tnow < time},
                {
                        dBnext = {rrand(-24,0)}.value;
                        dBlist.add(dBnext);
                        dBdistance = abs(dBnow-dBnext);

                        tdifference = dBdistance * rate.reciprocal;
                        tlist.add(tdifference);

                        tnow = tnow + tdifference;
                        dBnow = dBnext;

                        //tlist.postln;
                        //dBlist.postln;

                };

        );

        [dBlist,tlist]

};

)

(
{

        var target,dur,envlists,env, sin;

        envlists = ~trajectory_calc.(60,4).value;
        envlists.postln;

        target = Dseq(envlists[0]);
        dur = Dseq(envlists[1]);
        env = DemandEnvGen.ar(target, dur, shape: 1, curve: 0, gate: 1).dbamp;
        sin = SinOsc.ar(220,0,0.5)*env;
        Out.ar([0,1],sin);
}.scope.play;

)



-----
@bloodymortimer
--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
@bloodymortimer
Reply | Threaded
Open this post in threaded view
|

Re: Aw: [sc-users] Re: new user: Ugen / arate / krate constant rate random walks

bloodymortimer
I'm getting warm (i think) but i haven't been quite able to nail it (2 1/2 hours later ...)

here's the latest attempt to hack the 'pure Demand' solution ...

I'm trying to use Dseries as the 'accumulator', but i keep running out of bounds ...

i could wrap it, but it will be better if it's moving around 'inside the Target Zone' rather than 'bouncing off the walls' ...

(
a = { |slope = 4|

    var env,accum,time,step,dBinit,dB,dBprev =rrand(-24,0) ;
   
    dB = Dstutter(2,Dwhite(-24, 0, inf));
    step = dB-dBprev;
    time = abs(step)*slope.reciprocal;
   
    // start at dBstart, step is the dBdistance
    accum = Dseries(dBprev, step, inf);
    env = DemandEnvGen.ar(accum, time);
    dBprev = dB;
    env;

}.plot(duration: 20);
)
@bloodymortimer