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 
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:

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 takeaway 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://newsupercollidermailinglistsforumsusethese.2681727.n2.nabble.com/SuperColliderUsersNewUsethisf2676391.html _______________________________________________ scusers mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/eastudios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/scusers/ search: http://www.listarc.bham.ac.uk/lists/scusers/search/
@bloodymortimer

In reply to this post by mousaique
* [hidden email] <[hidden email]> [20180211 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... http://drpichon.free.fr/pmpd/ and send control values over to SC via OSC... P _______________________________________________ scusers mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/eastudios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/scusers/ search: http://www.listarc.bham.ac.uk/lists/scusers/search/ 
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 nongraphical 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 # _______________________________________________ scusers mailing list info (subscription, etc.): http://www.birmingham.ac.uk/facilities/eastudios/research/supercollider/mailinglist.aspx archive: http://www.listarc.bham.ac.uk/marchives/scusers/ search: http://www.listarc.bham.ac.uk/lists/scusers/search/ 
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. 
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 RungeKutta 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 leftright, topbottom 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 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:

coupled oscillators via local feedback in the ugen graph, with simple gravitylike 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:

nice, thank you! but what is precisely the factor that makes the dynamics gravitylike in this case? On Mon, Feb 12, 2018 at 6:40 PM, <[hidden email]> wrote:

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:

Free forum by Nabble  Edit this page 