question regarding gravitational models

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

question regarding gravitational models

mousaique
hello all,

a question regarding models that simulate gravitational systems:

-in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?

on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...

e.g. does the ugen GravityGrid2.ar work on this way? 
and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)

thank you,
j


Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

mousaique
hello again,
im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
common mapping? cross modulation? some function?
im just wondering at what level to start in trying dynamical systems...
suggestions appreciated, thanks!
jan

On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
hello all,

a question regarding models that simulate gravitational systems:

-in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?

on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...

e.g. does the ugen GravityGrid2.ar work on this way? 
and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)

thank you,
j



Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

bloodymortimer
well, clearly i have no idea in the Supercollider context, but at least
here's an answer.

i recall seeing this opcode 'planet' in the csound manual, & there's an
article about in the 'csound journal' ...

http://www.csoundjournal.com/issue9/FlutesInOrbit.html

i doubt that 's the answer you are looking for but it might get you started
...

i suppose the obvious take-away for me is that i would just try & model the
physics first as a discrete exercise, & then work out what to map them to
after that (a fairly arbitrary & experimental process most likely ...) but,
perhaps obviously enough, here the application seems to be sound
spatialisation & hence volume & panning ...

if you feel like reading some c source code you could always hunt it down &
look at that ...






--
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: question regarding gravitational models

Peter P.-2
In reply to this post by mousaique
* [hidden email] <[hidden email]> [2018-02-11 10:02]:

> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope
> of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in
> mutually influencing gravitational models) how can this interdependence be
> brought about in sc?
> how does one synth (or clusters of them) dynamically react to the
> parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
Perhaps try the pmpd library for Pure Data
http://drpichon.free.fr/pmpd/
and send control values over to SC via OSC...

P

_______________________________________________
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: question regarding gravitational models

Fredrik Olofsson
In reply to this post by mousaique
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#


_______________________________________________
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: question regarding gravitational models

mousaique
thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#

Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

clicksonnil
Hi, 

Maybe code here helps? You'll need to change the path for sound file output, and I've indicated some places you could play with various parameters or choices of what to listen to. 

Update step every sample, discretised update as basic approximation (there are more involved numerical approximation schemes like Runge-Kutta and beyond, but this is the quick first order "Euler method"). 

The GravityGrid SLUGens, and many other nonlinear dynamics oscillators in the SLUGens, would use similar procedures at heart in the C code source. 

best,
N


//a three body problem in 2 dimensions, in left-right, top-bottom quotient space ([-1,1]x[-1,1])
//inverse gravity acts between all bodies as an acceleration against vector inbetween them, strength determined by inverse square of distance (up to a limit)

//wraparound effect will lead to discontinuities in position and acceleration

//jumps parameters every half second
(
var source,file,data;
var sr = 44100;
var samplestep;
var baseacceleration = {{0.01.rand2}!2}!3;
//6 dimensions in phase space per point, 2 (x,y) each of position, velocity, acceleration
var phasespace = { ({1.0.rand2}!2) ++ ({0.05.rand2}!2) ++ ({0.02.rand2}!2)}!3;
var pairs = [[0,1],[0,2],[1,2]];
var strengthofgravity = 0.05;

samplestep = sr.reciprocal*500;

file = SoundFile.new.headerFormat_("WAV").sampleFormat_("int16").numChannels_(1).sampleRate_(sr);

file.openWrite("/Users/nickcollins/Desktop/threebody2doutput.wav");


//5 seconds worth
data = Signal.fill(sr*10, {|i|

var proximities, repulsions;

//swap data every half second
if(i%22050==0) {
phasespace = { ({1.0.rand2}!2) ++ ({0.5.rand2}!2) ++ ({0.2.rand2}!2)}!3;
baseacceleration = {{0.1.rand2}!2}!3;
strengthofgravity = exprand(0.005,50);
samplestep = sr.reciprocal*exprand(100,10000);
};

//"inverse gravity effect", actually a repulsion
proximities = pairs.collect{|pairing| {|j|
(phasespace[pairing[0]][j]) - (phasespace[pairing[1]][j])
}!2; };

//0.00005
repulsions = proximities.collect{|prox| var distance = (prox[0]*prox[0]) + (prox[1]*prox[1]); strengthofgravity * (if(distance>0.001,{(distance*distance).reciprocal},{0.001.squared.reciprocal})) };

//update phasespace
//update acceleration based on forces at play (assume all masses of 1)
phasespace[0][4] = baseacceleration[0][0] - (repulsions[0]*proximities[0][0]) - (repulsions[1]*proximities[1][0]);
phasespace[0][5] = baseacceleration[0][1] - (repulsions[0]*proximities[0][1]) - (repulsions[1]*proximities[1][1]);

phasespace[1][4] = baseacceleration[1][0] + (repulsions[0]*proximities[0][0]) - (repulsions[2]*proximities[2][0]);
phasespace[1][5] = baseacceleration[1][1] + (repulsions[0]*proximities[0][1]) - (repulsions[2]*proximities[2][1]);

phasespace[2][4] = baseacceleration[2][0] + (repulsions[1]*proximities[1][0]) + (repulsions[2]*proximities[2][0]);
phasespace[2][5] = baseacceleration[2][1] + (repulsions[1]*proximities[1][1]) + (repulsions[2]*proximities[2][1]);


//update velocity, update position, clipping and wrapping respectively
3.do {|j|
//avoid unconstrained acceleration
phasespace[j][4] = phasespace[j][4].clip(-1,1);
phasespace[j][4] = phasespace[j][5].clip(-1,1);

phasespace[j][2] = (phasespace[j][2] + (phasespace[j][4]*samplestep)).clip(-1,1);
phasespace[j][3] = (phasespace[j][3] + (phasespace[j][5]*samplestep)).clip(-1,1);

//could also fold
phasespace[j][0] = (phasespace[j][0] + (phasespace[j][2]*samplestep)).wrap(-1,1);
phasespace[j][1] = (phasespace[j][1] + (phasespace[j][3]*samplestep)).wrap(-1,1);
};

//could be any other position, velocity, acceleration too
phasespace[0][0]
//phasespace[1][3]
//phasespace[2][5] //etc, nicest results for velocity and acceleration
});

file.writeData(data);

file.close;
)


On 11 Feb 2018, at 12:18, [hidden email] wrote:

thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#


Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

mousaique
thanks very much nick! afaic this generates the waveform itself, on a sample to sample basis. 
i was rather thinking of applying gravitational models to existing synths, say clusters of 8 sine waves each, and let those interfere with eachother according to gravitational principles (hence my question, how to meake these clusters dynamically interact). its basically the same principle on a meta level, a kind of overall control structure...in any case i will take a close look at what you sent!

On Mon, Feb 12, 2018 at 1:32 AM, <[hidden email]> wrote:
Hi, 

Maybe code here helps? You'll need to change the path for sound file output, and I've indicated some places you could play with various parameters or choices of what to listen to. 

Update step every sample, discretised update as basic approximation (there are more involved numerical approximation schemes like Runge-Kutta and beyond, but this is the quick first order "Euler method"). 

The GravityGrid SLUGens, and many other nonlinear dynamics oscillators in the SLUGens, would use similar procedures at heart in the C code source. 

best,
N


//a three body problem in 2 dimensions, in left-right, top-bottom quotient space ([-1,1]x[-1,1])
//inverse gravity acts between all bodies as an acceleration against vector inbetween them, strength determined by inverse square of distance (up to a limit)

//wraparound effect will lead to discontinuities in position and acceleration

//jumps parameters every half second
(
var source,file,data;
var sr = 44100;
var samplestep;
var baseacceleration = {{0.01.rand2}!2}!3;
//6 dimensions in phase space per point, 2 (x,y) each of position, velocity, acceleration
var phasespace = { ({1.0.rand2}!2) ++ ({0.05.rand2}!2) ++ ({0.02.rand2}!2)}!3;
var pairs = [[0,1],[0,2],[1,2]];
var strengthofgravity = 0.05;

samplestep = sr.reciprocal*500;

file = SoundFile.new.headerFormat_("WAV").sampleFormat_("int16").numChannels_(1).sampleRate_(sr);

file.openWrite("/Users/nickcollins/Desktop/threebody2doutput.wav");


//5 seconds worth
data = Signal.fill(sr*10, {|i|

var proximities, repulsions;

//swap data every half second
if(i%22050==0) {
phasespace = { ({1.0.rand2}!2) ++ ({0.5.rand2}!2) ++ ({0.2.rand2}!2)}!3;
baseacceleration = {{0.1.rand2}!2}!3;
strengthofgravity = exprand(0.005,50);
samplestep = sr.reciprocal*exprand(100,10000);
};

//"inverse gravity effect", actually a repulsion
proximities = pairs.collect{|pairing| {|j|
(phasespace[pairing[0]][j]) - (phasespace[pairing[1]][j])
}!2; };

//0.00005
repulsions = proximities.collect{|prox| var distance = (prox[0]*prox[0]) + (prox[1]*prox[1]); strengthofgravity * (if(distance>0.001,{(distance*distance).reciprocal},{0.001.squared.reciprocal})) };

//update phasespace
//update acceleration based on forces at play (assume all masses of 1)
phasespace[0][4] = baseacceleration[0][0] - (repulsions[0]*proximities[0][0]) - (repulsions[1]*proximities[1][0]);
phasespace[0][5] = baseacceleration[0][1] - (repulsions[0]*proximities[0][1]) - (repulsions[1]*proximities[1][1]);

phasespace[1][4] = baseacceleration[1][0] + (repulsions[0]*proximities[0][0]) - (repulsions[2]*proximities[2][0]);
phasespace[1][5] = baseacceleration[1][1] + (repulsions[0]*proximities[0][1]) - (repulsions[2]*proximities[2][1]);

phasespace[2][4] = baseacceleration[2][0] + (repulsions[1]*proximities[1][0]) + (repulsions[2]*proximities[2][0]);
phasespace[2][5] = baseacceleration[2][1] + (repulsions[1]*proximities[1][1]) + (repulsions[2]*proximities[2][1]);


//update velocity, update position, clipping and wrapping respectively
3.do {|j|
//avoid unconstrained acceleration
phasespace[j][4] = phasespace[j][4].clip(-1,1);
phasespace[j][4] = phasespace[j][5].clip(-1,1);

phasespace[j][2] = (phasespace[j][2] + (phasespace[j][4]*samplestep)).clip(-1,1);
phasespace[j][3] = (phasespace[j][3] + (phasespace[j][5]*samplestep)).clip(-1,1);

//could also fold
phasespace[j][0] = (phasespace[j][0] + (phasespace[j][2]*samplestep)).wrap(-1,1);
phasespace[j][1] = (phasespace[j][1] + (phasespace[j][3]*samplestep)).wrap(-1,1);
};

//could be any other position, velocity, acceleration too
phasespace[0][0]
//phasespace[1][3]
//phasespace[2][5] //etc, nicest results for velocity and acceleration
});

file.writeData(data);

file.close;
)


On 11 Feb 2018, at 12:18, [hidden email] wrote:

thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#



Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

clicksonnil
coupled oscillators via local feedback in the ugen graph, with simple gravity-like dynamics in 1D (note block size delay feedback, you can reduce delay to a sample via s.options.blockSize = 1)

I haven't got the best operating ranges here, can be tweaked in many ways, but hopefully enough of a demo to get you underway...

best
N

//caution, noisy!

(
{

var numoscillators = 8; //rich even with 1 or 2!
var feedback = LocalIn.ar(numoscillators);
var oscillators;
var rates = {rrand(1,200.1)}!numoscillators;
var perturb;

perturb = {|i| ({|j| if(i!=j){(feedback[i]-feedback[j]).squared.max(0.001).reciprocal}{0} }!numoscillators).sum; }!numoscillators;

oscillators = Phasor.ar(0,SampleRate.ir*((MouseY.kr(0.001,0.1,'exponential')*rates)+(MouseX.kr(0,0.01)*perturb)),-1,1);

LocalOut.ar(oscillators);

Pan2.ar(LeakDC.ar(Mix(oscillators)),0);

}.scope
)


On 12 Feb 2018, at 12:39, [hidden email] wrote:

thanks very much nick! afaic this generates the waveform itself, on a sample to sample basis. 
i was rather thinking of applying gravitational models to existing synths, say clusters of 8 sine waves each, and let those interfere with eachother according to gravitational principles (hence my question, how to meake these clusters dynamically interact). its basically the same principle on a meta level, a kind of overall control structure...in any case i will take a close look at what you sent!

On Mon, Feb 12, 2018 at 1:32 AM, <[hidden email]> wrote:
Hi, 

Maybe code here helps? You'll need to change the path for sound file output, and I've indicated some places you could play with various parameters or choices of what to listen to. 

Update step every sample, discretised update as basic approximation (there are more involved numerical approximation schemes like Runge-Kutta and beyond, but this is the quick first order "Euler method"). 

The GravityGrid SLUGens, and many other nonlinear dynamics oscillators in the SLUGens, would use similar procedures at heart in the C code source. 

best,
N


//a three body problem in 2 dimensions, in left-right, top-bottom quotient space ([-1,1]x[-1,1])
//inverse gravity acts between all bodies as an acceleration against vector inbetween them, strength determined by inverse square of distance (up to a limit)

//wraparound effect will lead to discontinuities in position and acceleration

//jumps parameters every half second
(
var source,file,data;
var sr = 44100;
var samplestep;
var baseacceleration = {{0.01.rand2}!2}!3;
//6 dimensions in phase space per point, 2 (x,y) each of position, velocity, acceleration
var phasespace = { ({1.0.rand2}!2) ++ ({0.05.rand2}!2) ++ ({0.02.rand2}!2)}!3;
var pairs = [[0,1],[0,2],[1,2]];
var strengthofgravity = 0.05;

samplestep = sr.reciprocal*500;

file = SoundFile.new.headerFormat_("WAV").sampleFormat_("int16").numChannels_(1).sampleRate_(sr);

file.openWrite("/Users/nickcollins/Desktop/threebody2doutput.wav");


//5 seconds worth
data = Signal.fill(sr*10, {|i|

var proximities, repulsions;

//swap data every half second
if(i%22050==0) {
phasespace = { ({1.0.rand2}!2) ++ ({0.5.rand2}!2) ++ ({0.2.rand2}!2)}!3;
baseacceleration = {{0.1.rand2}!2}!3;
strengthofgravity = exprand(0.005,50);
samplestep = sr.reciprocal*exprand(100,10000);
};

//"inverse gravity effect", actually a repulsion
proximities = pairs.collect{|pairing| {|j|
(phasespace[pairing[0]][j]) - (phasespace[pairing[1]][j])
}!2; };

//0.00005
repulsions = proximities.collect{|prox| var distance = (prox[0]*prox[0]) + (prox[1]*prox[1]); strengthofgravity * (if(distance>0.001,{(distance*distance).reciprocal},{0.001.squared.reciprocal})) };

//update phasespace
//update acceleration based on forces at play (assume all masses of 1)
phasespace[0][4] = baseacceleration[0][0] - (repulsions[0]*proximities[0][0]) - (repulsions[1]*proximities[1][0]);
phasespace[0][5] = baseacceleration[0][1] - (repulsions[0]*proximities[0][1]) - (repulsions[1]*proximities[1][1]);

phasespace[1][4] = baseacceleration[1][0] + (repulsions[0]*proximities[0][0]) - (repulsions[2]*proximities[2][0]);
phasespace[1][5] = baseacceleration[1][1] + (repulsions[0]*proximities[0][1]) - (repulsions[2]*proximities[2][1]);

phasespace[2][4] = baseacceleration[2][0] + (repulsions[1]*proximities[1][0]) + (repulsions[2]*proximities[2][0]);
phasespace[2][5] = baseacceleration[2][1] + (repulsions[1]*proximities[1][1]) + (repulsions[2]*proximities[2][1]);


//update velocity, update position, clipping and wrapping respectively
3.do {|j|
//avoid unconstrained acceleration
phasespace[j][4] = phasespace[j][4].clip(-1,1);
phasespace[j][4] = phasespace[j][5].clip(-1,1);

phasespace[j][2] = (phasespace[j][2] + (phasespace[j][4]*samplestep)).clip(-1,1);
phasespace[j][3] = (phasespace[j][3] + (phasespace[j][5]*samplestep)).clip(-1,1);

//could also fold
phasespace[j][0] = (phasespace[j][0] + (phasespace[j][2]*samplestep)).wrap(-1,1);
phasespace[j][1] = (phasespace[j][1] + (phasespace[j][3]*samplestep)).wrap(-1,1);
};

//could be any other position, velocity, acceleration too
phasespace[0][0]
//phasespace[1][3]
//phasespace[2][5] //etc, nicest results for velocity and acceleration
});

file.writeData(data);

file.close;
)


On 11 Feb 2018, at 12:18, [hidden email] wrote:

thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#




Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

mousaique
nice, thank you! but what is precisely the factor that makes the dynamics gravity-like in this case?

On Mon, Feb 12, 2018 at 6:40 PM, <[hidden email]> wrote:
coupled oscillators via local feedback in the ugen graph, with simple gravity-like dynamics in 1D (note block size delay feedback, you can reduce delay to a sample via s.options.blockSize = 1)

I haven't got the best operating ranges here, can be tweaked in many ways, but hopefully enough of a demo to get you underway...

best
N

//caution, noisy!

(
{

var numoscillators = 8; //rich even with 1 or 2!
var feedback = LocalIn.ar(numoscillators);
var oscillators;
var rates = {rrand(1,200.1)}!numoscillators;
var perturb;

perturb = {|i| ({|j| if(i!=j){(feedback[i]-feedback[j]).squared.max(0.001).reciprocal}{0} }!numoscillators).sum; }!numoscillators;

oscillators = Phasor.ar(0,SampleRate.ir*((MouseY.kr(0.001,0.1,'exponential')*rates)+(MouseX.kr(0,0.01)*perturb)),-1,1);

LocalOut.ar(oscillators);

Pan2.ar(LeakDC.ar(Mix(oscillators)),0);

}.scope
)


On 12 Feb 2018, at 12:39, [hidden email] wrote:

thanks very much nick! afaic this generates the waveform itself, on a sample to sample basis. 
i was rather thinking of applying gravitational models to existing synths, say clusters of 8 sine waves each, and let those interfere with eachother according to gravitational principles (hence my question, how to meake these clusters dynamically interact). its basically the same principle on a meta level, a kind of overall control structure...in any case i will take a close look at what you sent!

On Mon, Feb 12, 2018 at 1:32 AM, <[hidden email]> wrote:
Hi, 

Maybe code here helps? You'll need to change the path for sound file output, and I've indicated some places you could play with various parameters or choices of what to listen to. 

Update step every sample, discretised update as basic approximation (there are more involved numerical approximation schemes like Runge-Kutta and beyond, but this is the quick first order "Euler method"). 

The GravityGrid SLUGens, and many other nonlinear dynamics oscillators in the SLUGens, would use similar procedures at heart in the C code source. 

best,
N


//a three body problem in 2 dimensions, in left-right, top-bottom quotient space ([-1,1]x[-1,1])
//inverse gravity acts between all bodies as an acceleration against vector inbetween them, strength determined by inverse square of distance (up to a limit)

//wraparound effect will lead to discontinuities in position and acceleration

//jumps parameters every half second
(
var source,file,data;
var sr = 44100;
var samplestep;
var baseacceleration = {{0.01.rand2}!2}!3;
//6 dimensions in phase space per point, 2 (x,y) each of position, velocity, acceleration
var phasespace = { ({1.0.rand2}!2) ++ ({0.05.rand2}!2) ++ ({0.02.rand2}!2)}!3;
var pairs = [[0,1],[0,2],[1,2]];
var strengthofgravity = 0.05;

samplestep = sr.reciprocal*500;

file = SoundFile.new.headerFormat_("WAV").sampleFormat_("int16").numChannels_(1).sampleRate_(sr);

file.openWrite("/Users/nickcollins/Desktop/threebody2doutput.wav");


//5 seconds worth
data = Signal.fill(sr*10, {|i|

var proximities, repulsions;

//swap data every half second
if(i%22050==0) {
phasespace = { ({1.0.rand2}!2) ++ ({0.5.rand2}!2) ++ ({0.2.rand2}!2)}!3;
baseacceleration = {{0.1.rand2}!2}!3;
strengthofgravity = exprand(0.005,50);
samplestep = sr.reciprocal*exprand(100,10000);
};

//"inverse gravity effect", actually a repulsion
proximities = pairs.collect{|pairing| {|j|
(phasespace[pairing[0]][j]) - (phasespace[pairing[1]][j])
}!2; };

//0.00005
repulsions = proximities.collect{|prox| var distance = (prox[0]*prox[0]) + (prox[1]*prox[1]); strengthofgravity * (if(distance>0.001,{(distance*distance).reciprocal},{0.001.squared.reciprocal})) };

//update phasespace
//update acceleration based on forces at play (assume all masses of 1)
phasespace[0][4] = baseacceleration[0][0] - (repulsions[0]*proximities[0][0]) - (repulsions[1]*proximities[1][0]);
phasespace[0][5] = baseacceleration[0][1] - (repulsions[0]*proximities[0][1]) - (repulsions[1]*proximities[1][1]);

phasespace[1][4] = baseacceleration[1][0] + (repulsions[0]*proximities[0][0]) - (repulsions[2]*proximities[2][0]);
phasespace[1][5] = baseacceleration[1][1] + (repulsions[0]*proximities[0][1]) - (repulsions[2]*proximities[2][1]);

phasespace[2][4] = baseacceleration[2][0] + (repulsions[1]*proximities[1][0]) + (repulsions[2]*proximities[2][0]);
phasespace[2][5] = baseacceleration[2][1] + (repulsions[1]*proximities[1][1]) + (repulsions[2]*proximities[2][1]);


//update velocity, update position, clipping and wrapping respectively
3.do {|j|
//avoid unconstrained acceleration
phasespace[j][4] = phasespace[j][4].clip(-1,1);
phasespace[j][4] = phasespace[j][5].clip(-1,1);

phasespace[j][2] = (phasespace[j][2] + (phasespace[j][4]*samplestep)).clip(-1,1);
phasespace[j][3] = (phasespace[j][3] + (phasespace[j][5]*samplestep)).clip(-1,1);

//could also fold
phasespace[j][0] = (phasespace[j][0] + (phasespace[j][2]*samplestep)).wrap(-1,1);
phasespace[j][1] = (phasespace[j][1] + (phasespace[j][3]*samplestep)).wrap(-1,1);
};

//could be any other position, velocity, acceleration too
phasespace[0][0]
//phasespace[1][3]
//phasespace[2][5] //etc, nicest results for velocity and acceleration
});

file.writeData(data);

file.close;
)


On 11 Feb 2018, at 12:18, [hidden email] wrote:

thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#





Reply | Threaded
Open this post in threaded view
|

Re: question regarding gravitational models

clicksonnil
Let's try general relativity (or an early 'simple' solution) then

//https://en.wikipedia.org/wiki/File:Newton_versus_Schwarzschild_trajectories.gif
(
{

var phasespacedim = 6; 
var feedback = LocalIn.ar(phasespacedim);
var r, phi;
var rdot, rdotdot, phidot, phidotdot;
var update = MouseX.kr*5;  //0 to 1

rdotdot = ((-1/((feedback[0]).max(0.00001).squared)) + ((feedback[0]-(10*MouseY.kr))*((feedback[3]).squared)) + DC.ar(0)).fold(-10,10);
phidotdot = (((-2)*(feedback[2])*(feedback[3]))/((feedback[0]).max(0.00001)) + DC.ar(0)).fold(-10,10);

rdot = (((feedback[2]) + (update*rdotdot)) + Impulse.ar(0)).fold(-100,100);
phidot = (((feedback[2]) + (update*(pi/10)*phidotdot)) + Impulse.ar(0)).fold(-pi,pi);

//initialise with single sample impulse
r = (Impulse.ar(0)+ (feedback[0]) + (update*rdot)).fold(-100,100);
phi = (DC.ar(0)+ (feedback[1]) + (update*(pi/100)*phidot)).fold(-pi,pi);

LocalOut.ar([r,phi,rdot,phidot,rdotdot,phidotdot]);

Pan2.ar(LeakDC.ar(((r * cos(phi)).poll)*0.01),0);

}.scope
)

s.options.blockSize_(1) //try different values (giving different update delays), 64 or 1 or other...




On 12 Feb 2018, at 18:37, [hidden email] wrote:

nice, thank you! but what is precisely the factor that makes the dynamics gravity-like in this case?

On Mon, Feb 12, 2018 at 6:40 PM, <[hidden email]> wrote:
coupled oscillators via local feedback in the ugen graph, with simple gravity-like dynamics in 1D (note block size delay feedback, you can reduce delay to a sample via s.options.blockSize = 1)

I haven't got the best operating ranges here, can be tweaked in many ways, but hopefully enough of a demo to get you underway...

best
N

//caution, noisy!

(
{

var numoscillators = 8; //rich even with 1 or 2!
var feedback = LocalIn.ar(numoscillators);
var oscillators;
var rates = {rrand(1,200.1)}!numoscillators;
var perturb;

perturb = {|i| ({|j| if(i!=j){(feedback[i]-feedback[j]).squared.max(0.001).reciprocal}{0} }!numoscillators).sum; }!numoscillators;

oscillators = Phasor.ar(0,SampleRate.ir*((MouseY.kr(0.001,0.1,'exponential')*rates)+(MouseX.kr(0,0.01)*perturb)),-1,1);

LocalOut.ar(oscillators);

Pan2.ar(LeakDC.ar(Mix(oscillators)),0);

}.scope
)


On 12 Feb 2018, at 12:39, [hidden email] wrote:

thanks very much nick! afaic this generates the waveform itself, on a sample to sample basis. 
i was rather thinking of applying gravitational models to existing synths, say clusters of 8 sine waves each, and let those interfere with eachother according to gravitational principles (hence my question, how to meake these clusters dynamically interact). its basically the same principle on a meta level, a kind of overall control structure...in any case i will take a close look at what you sent!

On Mon, Feb 12, 2018 at 1:32 AM, <[hidden email]> wrote:
Hi, 

Maybe code here helps? You'll need to change the path for sound file output, and I've indicated some places you could play with various parameters or choices of what to listen to. 

Update step every sample, discretised update as basic approximation (there are more involved numerical approximation schemes like Runge-Kutta and beyond, but this is the quick first order "Euler method"). 

The GravityGrid SLUGens, and many other nonlinear dynamics oscillators in the SLUGens, would use similar procedures at heart in the C code source. 

best,
N


//a three body problem in 2 dimensions, in left-right, top-bottom quotient space ([-1,1]x[-1,1])
//inverse gravity acts between all bodies as an acceleration against vector inbetween them, strength determined by inverse square of distance (up to a limit)

//wraparound effect will lead to discontinuities in position and acceleration

//jumps parameters every half second
(
var source,file,data;
var sr = 44100;
var samplestep;
var baseacceleration = {{0.01.rand2}!2}!3;
//6 dimensions in phase space per point, 2 (x,y) each of position, velocity, acceleration
var phasespace = { ({1.0.rand2}!2) ++ ({0.05.rand2}!2) ++ ({0.02.rand2}!2)}!3;
var pairs = [[0,1],[0,2],[1,2]];
var strengthofgravity = 0.05;

samplestep = sr.reciprocal*500;

file = SoundFile.new.headerFormat_("WAV").sampleFormat_("int16").numChannels_(1).sampleRate_(sr);

file.openWrite("/Users/nickcollins/Desktop/threebody2doutput.wav");


//5 seconds worth
data = Signal.fill(sr*10, {|i|

var proximities, repulsions;

//swap data every half second
if(i%22050==0) {
phasespace = { ({1.0.rand2}!2) ++ ({0.5.rand2}!2) ++ ({0.2.rand2}!2)}!3;
baseacceleration = {{0.1.rand2}!2}!3;
strengthofgravity = exprand(0.005,50);
samplestep = sr.reciprocal*exprand(100,10000);
};

//"inverse gravity effect", actually a repulsion
proximities = pairs.collect{|pairing| {|j|
(phasespace[pairing[0]][j]) - (phasespace[pairing[1]][j])
}!2; };

//0.00005
repulsions = proximities.collect{|prox| var distance = (prox[0]*prox[0]) + (prox[1]*prox[1]); strengthofgravity * (if(distance>0.001,{(distance*distance).reciprocal},{0.001.squared.reciprocal})) };

//update phasespace
//update acceleration based on forces at play (assume all masses of 1)
phasespace[0][4] = baseacceleration[0][0] - (repulsions[0]*proximities[0][0]) - (repulsions[1]*proximities[1][0]);
phasespace[0][5] = baseacceleration[0][1] - (repulsions[0]*proximities[0][1]) - (repulsions[1]*proximities[1][1]);

phasespace[1][4] = baseacceleration[1][0] + (repulsions[0]*proximities[0][0]) - (repulsions[2]*proximities[2][0]);
phasespace[1][5] = baseacceleration[1][1] + (repulsions[0]*proximities[0][1]) - (repulsions[2]*proximities[2][1]);

phasespace[2][4] = baseacceleration[2][0] + (repulsions[1]*proximities[1][0]) + (repulsions[2]*proximities[2][0]);
phasespace[2][5] = baseacceleration[2][1] + (repulsions[1]*proximities[1][1]) + (repulsions[2]*proximities[2][1]);


//update velocity, update position, clipping and wrapping respectively
3.do {|j|
//avoid unconstrained acceleration
phasespace[j][4] = phasespace[j][4].clip(-1,1);
phasespace[j][4] = phasespace[j][5].clip(-1,1);

phasespace[j][2] = (phasespace[j][2] + (phasespace[j][4]*samplestep)).clip(-1,1);
phasespace[j][3] = (phasespace[j][3] + (phasespace[j][5]*samplestep)).clip(-1,1);

//could also fold
phasespace[j][0] = (phasespace[j][0] + (phasespace[j][2]*samplestep)).wrap(-1,1);
phasespace[j][1] = (phasespace[j][1] + (phasespace[j][3]*samplestep)).wrap(-1,1);
};

//could be any other position, velocity, acceleration too
phasespace[0][0]
//phasespace[1][3]
//phasespace[2][5] //etc, nicest results for velocity and acceleration
});

file.writeData(data);

file.close;
)


On 11 Feb 2018, at 12:18, [hidden email] wrote:

thanks for the answers. 
im still thinking a step before, meaning understanding the principle/ inner architecture of such a sonification system: 
where would the physics calculations belong (how do they even look?), what gets mapped and how, how is dynamic interdependence brought about etc...
i will take a look at the TraerPhysics Quark maybe theres some insights for me there!



On Sun, Feb 11, 2018 at 12:37 PM, <[hidden email]> wrote:
try to decide at which rate your physics calculations need to run.  do you really need them to update at .ar, .kr or is it enough with say 60 times per second?  i believe it's only for a few very special corner cases you'd really need to run at audiorate.  and those could probably also be taken care of with some interpolation.
so i suggest you write the physics code and mapping in sclang.  everything will be much easier and you can connect and map synth parameters directly instead of going via busses.  or at least prototype in sclang before trying to write audio rate plugins.

there are also premade physics systems for sclang to play around with.  i recently updated the port of TraerPhysics to include a non-graphical example.  it's modelling a system with particles connected via springs in gravity.  it updates at a rate of 1000/sec.
https://raw.githubusercontent.com/redFrik/TraerPhysics/master/HelpSource/Quarks/TraerPhysics/Examples/particle_system_without_graphics.scd
to run it...
Quarks.install("TraerPhysics")
or
Quarks.update("TraerPhysics")

_f

> 11 feb. 2018 kl. 10:02 skrev [hidden email]:
>
> hello again,
> im wrapping my mind around this one, so ill try to reformulate it in hope of an answer :)
> if sound parameters become interdependent (as i imagine it to be e.g. in mutually influencing gravitational models) how can this interdependence be brought about in sc?
> how does one synth (or clusters of them) dynamically react to the parameters of a second synth (or nth one)?
> common mapping? cross modulation? some function?
> im just wondering at what level to start in trying dynamical systems...
> suggestions appreciated, thanks!
> jan
>
> On Fri, Feb 2, 2018 at 3:04 PM, Jan Ferreira <[hidden email]> wrote:
> hello all,
>
> a question regarding models that simulate gravitational systems:
>
> -in what way is the interference between gravitational systems to be understood on an audio synthesis level? is it a form of cross modulation, implying some sort of feedback?
>
> on a general level, im trying to understand in what way reciprocity of mutually influencing systems could be programmed...
>
> e.g. does the ugen GravityGrid2.ar work on this way?
> and does someone know what waveform generator underlies this ugen? (is the waveform itself chaotically generated?)
>
> thank you,
> j
>
>
>


  #|
     fredrikolofsson.com     musicalfieldsforever.com
  |#