Fictional Modelling?

ProgHead

Gepokt en gemazeld
Lid sinds
26 februari 2019
Berichten
6.009
Locatie
Zeist
De bedoeling van dit topic is om physical modelling toe te passen op trillingsverschijnselen in werelden met andere natuurwetten dan die van onze eigen wereld, vandaar: fictional modelling. Hopelijk zal dat bij het ten gehore brengen dan verrassende geluiden opleveren die in soft synths gebruikt kunnen worden.
 

Hierboven is al iemand op hetzelfde spoor bezig. De vraag is nog even wat een handig freeware programma is om mee te gaan werken. In elk geval moeten er differentiaalvergelijkingen in geprogrammeerd of op gepatched kunnen worden.
 
Als dat niet zo was zo het nog interessanter zijn, maar het zoeken naar iets radicaal nieuws op zuiver wiskundig gebied heb ik inmiddels opgegeven. Dat is voor gewone stervelingen zoals ik tegenwoordig niet meer te doen. Dus ik houd het hier simpelweg bij differentiaalvergelijkingen, maar die dan net iets anders zijn dan we in de natuurkunde gewend zijn.

Echter om de sprong in het diepe niet te groot te maken begin ik met het modelleren van een klassiek geval: een trillende massa aan een veer. Als dat eenmaal werkt kunnen we dan (kleine) variaties bedenken in de vergelijkingen die zulke verschijnselen beschrijven. In physical modelling worden voor zover ik weet enkel de parameters binnen de bekende vergelijkingen gevarieerd, maar hier gaan we dan die vergelijkingen zelf aanpassen.
 
Goed - we hebben een massa m aan een veer met veerconstante R. De wrijvingsverliezen, de massa van de veer zelf, de zwaartekracht, etc. worden verwaarloosd. De momentane afwijking op tijdstip t van de massa m van de evenwichtsstand (x=0) geven we aan met x = x(t); en de momentane kracht van de veer op de massa m op tijdstip t als F = F(t). Dan geldt er voor de veer:

[imath] F = - \mathrm{R} \cdot x [/imath]

En geldt wegens Newtons F=m.a voor de massa m dat:

[imath] F = \mathrm{m} \cdot \frac{\mathrm{d}^2 x}{\mathrm{d} t^2} [/imath]

Zodat:

[imath] \frac{\mathrm{d}^2 x}{\mathrm{d} t^2} = - \frac{\mathrm{R}}{\mathrm{m}} \cdot x \,\,\,\,\,\,\,\,\,\,\,\, (1) [/imath]

Oftewel (voor de snelheid v = v(t) van de massa m) dat:

[imath] \frac{\mathrm{d} v}{\mathrm{d} t} = - \frac{\mathrm{R}}{\mathrm{m}} \cdot x \,\,\,\,\,\,\,\,\,\,\,\, (2) [/imath]
 
Als we de positie [imath] \mathrm{x}(t_0) [/imath] en de snelheid [imath] \mathrm{v}(t_0) [/imath] van de massa m op tijdstip [imath] t_0 [/imath] weten dan geldt er een tijdje [imath] \Delta t [/imath] later dat:

[imath] \mathrm{x}(t_0 + \Delta t) \approx \mathrm{x}(t_0) + \mathrm{v}(t_0) \Delta t \,\,\,\,\,\,\,\,\,\,\,\, (3) [/imath]

[imath] \mathrm{v}(t_0 + \Delta t) \approx \mathrm{v}(t_0) + \mathrm{a}(t_0) \Delta t \,\,\,\,\,\,\,\,\,\,\,\, (4) [/imath]

En deze benadering is des te beter naarmate [imath] \Delta t [/imath] kleiner gekozen wordt.
 
Als ik het goed zie zou het dan met de onderstaande programma-opzet moeten werken:

1. Vraag startwaarden voor xold en vold op.
2. Bereken xnew en vnew m.b.v. (1), (3) en (4).
3. Voer xnew als audio sample waarde uit.
4. Hernoem xnew en vnew als xold en vold .
5. Ga verder met 2.

Waarbij de loop dan zo moet worden ingesteld dat die precies een sampletijd lang (gelijk aan [imath] \Delta t [/imath]) duurt.
 
Het was even zoeken maar met onderstaande Csound progje als loop-opzet moet ik verder kunnen:

Code:
<CsoundSynthesizer>

<CsOptions>
-odac
</CsOptions>

<CsInstruments>
sr = 44100
ksmps =  1
nchnls = 2
0dbfs = 1

instr 1
kf = 440
kres timeinsts
aOut = sin(2*$M_PI*kf*kres)
outs aOut, aOut
endin
</CsInstruments>

<CsScore>
i 1 0 6
</CsScore>

</CsoundSynthesizer>

Gezien de voortgebrachte toon wordt de "instr1 sectie" kennelijk gedurende 6 sec met de sample rate in een loop doorlopen. Dat is het soort loop dat ik nodig heb.
 
Laatst gewijzigd:
Jammer genoeg zie ik net dat deze aanpak voor het modelleren heel snel (binnen een paar seconden) uit de hand loopt. Er zou een constante harmonische trilling uit moeten komen, maar het signaal explodeert al snel. Kennelijk is de sample tijd ([imath] = \Delta t [/imath]) hier nu nog te groot. Maar of daar op mijn computer iets aan te doen is...?
 
Dat weet ik, en daarom kan ik nu ook nog controleren of mijn computer simulatie klopt. Mijn bedoeling is om eerst voor een simpel geval een draaiend progje te maken, en dan later als alles eenmaal goed draait situaties te simuleren die niet langer analytisch zijn op te lossen. Maar het lijkt erop dat ik zelfs nu bij dit simpele geval van de simulatie van een massa aan een veer met Csound al vast loop...
 
Ah, ja. Hier wat code, de benadering van het probleem lijkt me eigenlijk hetzelfde en het zou dan toch ook met Csound moeten kunnen. Maar je kunt het even vergelijken met je eigen werk.
 
Dat ziet er inderdaad hetzelfde uit als wat ik gedaan heb. Ik zal nog eens preciezer kijken waar het bij mijn progje in Csound mis gaat.
 
Mijn Csound progje gaat nog goed voor frequenties minder dan een paar Hz, daarboven explodeert het signaal al binnen korte tijd.
 
Proberen of je kunt zien dat er een relatie is tussen de frequentie en delta-t, waarbij het net goed of net fout gaat? De methode lijkt dus wel te werken, dan moeten de tijdstapjes inderdaad wellicht wat fijnmaziger.
 
Is het niet zo dat het massa veer systeem instabiel wordt (dus gaat oscilleren met een steeds grotere amplitude) omdat er geen of niet genoeg demping in het model is opgenomen?
 
Proberen of je kunt zien dat er een relatie is tussen de frequentie en delta-t, waarbij het net goed of net fout gaat? De methode lijkt dus wel te werken, dan moeten de tijdstapjes inderdaad wellicht wat fijnmaziger.

De stapjes zijn nu al 1 sample tijd, wat het minimum is. Ik zal eens kijken hoever de sample rate te verhogen is, en wat daarmee te winnen valt.

Net geprobeerd: dat helpt niet veel.
 
Laatst gewijzigd:
Is het niet zo dat het massa veer systeem instabiel wordt (dus gaat oscilleren met een steeds grotere amplitude) omdat er geen of niet genoeg demping in het model is opgenomen?

Het aanbrengen van een demping zou een manier kunnen zijn om het exploderen van het signaal te verhinderen, maar bij lage frequenties gaat het wel goed dus ideaal gesproken zou het introduceren van een demping (in deze fase van het onderzoek) nog niet nodig moeten zijn.
 
Weet niet of dat te doen is, maar we zouden het slow motion gedrag van het systeem kunnen simuleren, en dat resultaat dan later weer op de ware snelheid kunnen afspelen. Dan is het niet meer real-time, maar voorlopig gaat het er toch enkel om of er interessante geluiden uit komen.
 
Back
Top