Cage-synth

Juist - dan zul je moeten wachten tot dit concept verderop in dit topic stap voor stap verder uitgewerkt wordt. Hoe het eindresultaat eruit gaat zien weet ikzelf namelijk ook nog niet. En zoals ik al vaker geschreven heb, dat nog niet alles bij voorbaat al vast ligt maakt zulke projecten voor mij nu juist interessant. Voor de bespreking van reeds bestaande synth's zijn er andere topics.
 
Wat is de range van je "draaiknoppen"/parameters?

Daar ben ik inmiddels over aan het nadenken. Als we m al te groot maken krijg je bij de conversie van C/m n-tallige getallen die met een rij nullen na de komma beginnen. Dat is niet handig. Dus er moet een bovengrens aan m komen. Om te beginnen wil ik dat de 2-tallige (= binaire) conversie van C/m niet met een rij nullen achter de komma begint. Dus moet: [imath] \frac{\mathrm{C}}{m} > 0,01_2 [/imath].

Is dit nog te volgen?
 
Is dit nog te volgen?

Ja, zo ongeveer wel. Ik verwacht ook nog geen rigoureuze, compleet sluitende verhandeling in dit stadium. :) Je zou 'ns kunnen kijken naar de progressie van decimalen (van elke n-tallige weergave), hoe de cijferreeks zich gaat herhalen. Voor het genereren van bruikbare, periodieke signalen.
 
Ja, zo ongeveer wel. Ik verwacht ook nog geen rigoureuze, compleet sluitende verhandeling in dit stadium. :) Je zou 'ns kunnen kijken naar de progressie van decimalen (van elke n-tallige weergave), hoe de cijferreeks zich gaat herhalen. Voor het genereren van bruikbare, periodieke signalen.

C is een rationale tijdsduur. En omdat we in de praktijk slechts met een eindig aantal cijfers kunnen werken, zal ook m steeds een rationale tijdsmaat moeten zijn. Dus zal C/m in onze berekeningen ook altijd een rationaal getal opleveren. (Zie Wikipedia voor rationale en irrationale getallen.) Er zal ook in de n-tallige representatie van C/m dus altijd uiteindelijk een repeterend patroon optreden.
 
Ja, dat snap ik. ;) Wat ik eigenlijk bedoel is dit:

dus altijd uiteindelijk een repeterend patroon optreden.

Een voorziening/instelling dat je als gebruiker dit kan beïnvloeden, zodat je sneller zo'n periodiek patroon krijgt, en/of van een zekere periode die je wenst. Een tweak dus, eventueel met een extra stuurvariabele oid.
 
De periode van C/m als n-tallig getal is afhankelijk van C, m en n (met n de basis van het n-tallige getal). Ik heb even op internet gezocht en er valt wel iets over die periode te zeggen, maar dat wordt wiskundig gezien een vrij ingewikkeld verhaal. Wel kun je met de tweede draaiknop van de Cage-synth de snelheid regelen waarmee de cijfers worden afgespeeld, dus als het signaal een hoorbare frequentie heeft dan is die frequentie door het draaien aan de tweede draaiknop in te stellen.
 
Als we m al te groot maken krijg je bij de conversie van C/m n-tallige getallen die met een rij nullen na de komma beginnen. Dat is niet handig. Dus er moet een bovengrens aan m komen. Om te beginnen wil ik dat de 2-tallige (= binaire) conversie van C/m niet met een rij nullen achter de komma begint. Dus moet: [imath] \frac{\mathrm{C}}{m} > 0,01_2 [/imath].

Daar zit nog een foutje in! :o:

Als [imath] \frac{\mathrm{C}}{m} = 0,011_2 [/imath] dan hebben we [imath] \frac{\mathrm{C}}{m} > 0,01_2 [/imath], maar dan begint C/m als tweetallig getal nog steeds met een nul na de komma (wat we nu juist niet willen). Dus eigenlijk moeten we eisen: [imath] \frac{\mathrm{C}}{m} > 0,01111..._2 [/imath]. Oftewel: [imath] \frac{\mathrm{C}}{m} > 0,1_2 [/imath].

[imath] \frac{\mathrm{C}}{m} > 0,1_2 [/imath]

[imath] \frac{\mathrm{C}}{m} > \, 1 \cdot 2^{-1} [/imath]

[imath] \frac{2 \mathrm{C}}{m} > 1 [/imath]

[imath] 2 \mathrm{C} > m [/imath]

[imath] m < 2 \mathrm{C} [/imath]

[imath] m < 2 \cdot 273 \, \mathrm{s} [/imath]

[imath] m < 546 \, \mathrm{s} [/imath]
 
Voor een n-tallig getal met n > 2 moeten we dan evenzo eisen: [imath] \frac{\mathrm{C}}{m} > 0,1_n [/imath].

[imath] \frac{\mathrm{C}}{m} > 0,1_n [/imath]

[imath] \frac{\mathrm{C}}{m} > \, 1 \cdot n^{-1} [/imath]

[imath] \frac{n \mathrm{C}}{m} > 1 [/imath]

[imath] n \mathrm{C} > m [/imath]

[imath] m < n \mathrm{C} [/imath]

[imath] m < n \cdot 273 \, \mathrm{s} [/imath]

De eerder gevonden bovengrens van m voor de twee-tallige getallen volstaat dus zeker ook voor alle n-tallige getallen met n > 2.
 
Is er ook een zinnige ondergrens voor m? Net zoals het handig is wanneer het gegenereerde signaal direct na de komma begint zo is het ook handig wanneer het niet eerder dan de komma begint. Dat laatste kunnen we bewerkstelligen door te eisen dat: C/m < 1. Dat wil zeggen: C < m. De gevonden onder- en bovengrens tezamen leveren dus op:

[math] \mathrm{C} < m < 2 \mathrm{C} [/math][math] 273 \, \mathrm{s} < m < 546 \, \mathrm{s} [/math]
 
Het menselijk gehoor heeft een bereik voor geluidfrequenties tussen ongeveer 20 en 20.000 Hertz. Met twee opeenvolgende cijfers (een top en een dal) kun je met de Cage-synth een golf maken, maar met nog minder cijfers gaat dat niet. De maximaal haalbare frequentie van een grondgolf die de Cage-synth nog kan genereren is dus v/2, waarin v de cijfersnelheid zoals ingesteld met de tweede draaiknop is. Willen we ook de hoogst hoorbare tonen nog net kunnen voortbrengen dan moet er dus gelden: [imath] v_{max} / 2 = 20.000 \, \mathrm{Hz} [/imath]. Zodat: [imath] v_{max} = 40.000 \, \mathrm{Hz} [/imath].
 
De laagst mogelijke frequentie van de gegenereerde tonen is mede afhankelijk van het aantal cijfers achter de komma dat er berekend wordt, tenzij we de cijfersnelheid v willekeurig klein mogen maken. In dat laatste geval kun je zelfs met twee cijfers nog wel een enkele blokgolf van willekeurig lage frequentie genereren.
 
Ik zit nu even met de vraag wat praktisch haalbaar is voor het aantal berekende cijfers achter de komma. Wie weet daar meer van?
 
Ik zit nu even met de vraag wat praktisch haalbaar is voor het aantal berekende cijfers achter de komma. Wie weet daar meer van?

Hoe bedoel je dit? In het algemeen zul je snel tegen de limiet aanlopen van het type variabele die je gebruikt bij het programmeren. Het lijkt me dat je hiervoor een algoritme moet bedenken als je (veel) meer cijfers wil, en helemaal als het n-tallig moet zijn. Ik denk dat het probleem waar je op een gegeven moment tegenaan loopt de rekensnelheid is die je tot je beschikking hebt, als het in real time zou moeten werken.
 
Als de twee draaiknoppen zijn ingesteld hangt het alleen nog van de aangeslagen toets af wat voor geluid er uit de synth komt. In een extreem geval kan het dus zijn dat je even moet wachten tot de synth klaar is met het uitrekenen van de bijpassende signalen voor alle toetsen bij de ingestelde standen van de draaiknoppen. Er bestaan wetenschappelijke programma's waarmee je honderden of duizenden cijfers kunt berekenen. Ik zal waarschijnlijk zoiets als Python moeten gebruiken om meer dan simpele blieb-blieb geluidjes te krijgen. Met Python heb ik al eens eerder gewerkt dus dat moet te doen zijn.
 
Je zou 'ns kunnen kijken naar de progressie van decimalen (van elke n-tallige weergave), hoe de cijferreeks zich gaat herhalen. Voor het genereren van bruikbare, periodieke signalen.

Dit biedt een mogelijke oplossing: we zouden de draaiknop kunnen vervangen door een draaischakelaar waaronder je dan alleen de interessante waarden van m (de presets die leuke geluiden opleveren) stopt. De hele zaak kun je dan van tevoren op je gemak door een wetenschappelijk programma laten doorrekenen, vervolgens stop je de resultaten in een software rompler.
 
Back
Top