Hi Es gibt schon viele Synthesizer im Netz. Doch diese sind alle beschränkt und brauchen ein spezielles Format. Außerdem unterstützen sie nicht sehr viele Kanäle (meistens nur 4). Ich möchte einen Midisynthesizer bauen, so dass der µC nur die Mididatei einliest, ohne Umwandlung. Hier beginnen aber schon die Probleme: Atmega8 @16Mhz -> 16 mio Befehle/s Ausgangsformat 22050Hz @8bit (erstmal PWM, später 16bit DAC) (Tonausgabe werde ich über einen kleinene Buffer realisieren, der per Timerinterroupt dem HW-PWM übergeben wird) Midispezifikationen 16 Kanäle 88 (?) Töne pro Kanal 22050Hz * 16 * 88 = 31.046.400Hz -> Der Avr kann lange nicht alle Töne gleichzeitig spielen. Das ist das Hauptproblem. Es sind zu viele Tonkombinationen möglich. Midi arbeitet mit Befehlen wie Ton an/aus, d.h. man muss speichern welche Töne gerade aktiv sind. Platz zum speichern im SRAM: 16 Kanäle * 88bit = 176Byte Das ist akzeptabel, allersdings geht bei dieser speicherart die Performance drauf: Für das nächste Sample hat man 16Mhz / 22050Hz = ~725 Takte. Pro Kanal ~45 Takte. Wenn man um Zeit zu sparen immer ein Byte (also 8 Töne) abfragt, ob ein Ton darin aktiv ist, hat man pro Kanal schonmal 11 Abfragen: 88bit = 11Byte mögliche Töne pro Kanal. mit 11 Abfragen hat man aber schon die halbe Zeit verdödelt. Dazu kommt noch die Tonerzeugungsroutine, sollten Töne aktiv sein. Der Avr ist eindeutig zu langsam, bzw. nicht dafür geeignet. Mit einem CPLD sollte das einfacher sein. Trotzdem möchte ich versuchen so viel wie möglich aus ihm herauszuholen. 16 Kanäle werde ich wahrscheinlich nicht ohne weiteres schaffen. Gibt es ein besseres Konzept? Ist das ein falscher/zu ineffektiver Ansatz? Was schätzt ihr was mit Assembler möglich sein sollte?
Samuel K. schrieb: > Midispezifikationen > 16 Kanäle > 88 (?) Töne pro Kanal > > 22050Hz * 16 * 88 = 31.046.400Hz Das ist eine Milchmädchenrechnung die so nicht stimmt. Die Anzahl der Töne ist uninteressant. Entscheidend ist, welche Frequenzen du wie genau erzeugen können musst. Und die PWM kann ja auch gleich das Summensignal aller 16 Kanäle erzeugen. > Das ist das Hauptproblem. Das Hauptproblem ist, dass du noch keine Erfahrung mit PWM hast und nicht weißt, wie Tonerzeugung überhaupt funktioniert.
Jeder Synthesizer hat eine gewisse Anzahl an Stimmen (=gleichzeitig höhrbare Töne - früher meistens 16 oder 32, heute bereits 128 oder mehr), die bei einem multitimbralen Synthesizer über die z. B. 16 Kanäle (jedem Kanal kann ein eigenständiger Sound [Klavier, Orgel, Bass etc.] zugeordnet werden) dynamisch verteilt werden. D. h. schaffe ich es auf einem 16-stimmigen Synthesizer auf dem ersten Kanal gleichzeitig 16 Töne gleichzeitig zu spielen, dann bleiben für die anderen Kanäle in diesem Moment keine Stimmen mehr übrig. Spiele ich nur 14 Stimmen auf Kanal 1, dann bleiben noch zwei freie Stimmen, die ich frei auch auf andere Kanäle verteilen kann. Damit will ich sagen, dass man bei so einer Planung/Betrachtung nicht davon ausgehen sollte, dass es später möglich sein sollte auf jedem der 16 Kanäle im Extremfall alle 88 Stimmen (also in Summe 16*88=1408 Stimmen) gleichzeitig zu spielen. Eher andersrum... der geplante Synthesizer soll z. B. 32-stimmig sein und diese Stimmen sollen dynamisch auf 16 Kanäle verteilt werden. Die resultirenden Datenstrukturen für die Verwaltung der noch verfügbaren (also gerade nicht gespielten) Stimmen und der gerade gespielten Stimmen (auf welchem Kanal, welcher Ton etc.) sehen dann nämlich ganz anders aus. Aber das ist noch der einfache Part... die Tonerzeugung (digital? FM, PD, Sample-basiert, VirtualAnalog, Additiv, Subtraktiv) und die Mischung (digital?) spielen in einer anderen Liga. Gruß Christoph
Mit den AVRs wirst du nur wenige Stimmen in akzeptabler Qualität hinbekommen, wenn der Qualitätsanspruch etwas höher ist, dann ist sogar schon bei einer Stimme das Limit.
Karl Heinz Buchegger schrieb: > Samuel K. schrieb: > >> Midispezifikationen >> 16 Kanäle >> 88 (?) Töne pro Kanal >> >> 22050Hz * 16 * 88 = 31.046.400Hz > > Das ist eine Milchmädchenrechnung die so nicht stimmt. > Die Anzahl der Töne ist uninteressant. Entscheidend ist, welche > Frequenzen du wie genau erzeugen können musst. > > Und die PWM kann ja auch gleich das Summensignal aller 16 Kanäle > erzeugen. Das ist mir klar, doch die Rechenleistung fehlt um das zu addieren bei mehreren Tönen pro Kanal! >> Das ist das Hauptproblem. > > Das Hauptproblem ist, dass du noch keine Erfahrung mit PWM hast und > nicht weißt, wie Tonerzeugung überhaupt funktioniert. Leider habe ich schon einen kleinen Synthesizer zum Testen gebaut. Nur zum Testen heißt ich hab die Tonerzeugung per PWM getestet. Christoph schrieb: > Jeder Synthesizer hat eine gewisse Anzahl an Stimmen (=gleichzeitig > höhrbare Töne - früher meistens 16 oder 32, heute bereits 128 oder > mehr), die bei einem multitimbralen Synthesizer über die z. B. 16 Kanäle > (jedem Kanal kann ein eigenständiger Sound [Klavier, Orgel, Bass etc.] > zugeordnet werden) dynamisch verteilt werden. D. h. schaffe ich es auf > einem 16-stimmigen Synthesizer auf dem ersten Kanal gleichzeitig 16 Töne > gleichzeitig zu spielen, dann bleiben für die anderen Kanäle in diesem > Moment keine Stimmen mehr übrig. Spiele ich nur 14 Stimmen auf Kanal 1, > dann bleiben noch zwei freie Stimmen, die ich frei auch auf andere > Kanäle verteilen kann. Achso dann sind die Töne begrenzt. D.h. evtl. wäre es besser eine dynamische Liste mit den Tönen zu erstellen, wobei das wieder ein kleiner Aufwand für die Verwaltung ist. > Aber das ist noch der einfache Part... die Tonerzeugung (digital? FM, > PD, Sample-basiert, VirtualAnalog, Additiv, Subtraktiv) und die Mischung > (digital?) spielen in einer anderen Liga. Digital, per assembler schnipsel oder Sample (oder beides) hab ich geplant.
Hallo, viel Spaß dabei! Versuche ersteinmal einen Ton per Midiansteuerung auszugeben. Einen Sinus vieleicht? Also mit PITCH-Bend und so und Finetuning und PAN und und und... mfg
> Achso dann sind die Töne begrenzt. D.h. evtl. wäre es besser eine > dynamische Liste mit den Tönen zu erstellen, wobei das wieder ein > kleiner Aufwand für die Verwaltung ist. Ja, die Anzahl der gleichzeitig hörbaren Stimmen ist bei den Hardware-Synthesizern fast immer beschränkt. Der Grund ist, dass diese Hardware-Synthesizer nur eine beschränkte Anzahl von Oszillatoren (Stichwort VCO, DCO) haben. Dabei gilt im einfachsten Fall 1 Stimme=1 Oszillator. Kann aber bei komplexen Synthesearten auch 1 Stimme = 1-n Oszillatoren sein. Bei Software-Synthesizern ist die Anzahl der Oszillatoren oft variabel und hängt von der Rechenleistung des Computers ab, auf dem der Software-Synthesizer laufen gelassen wird. VCOs oder DCOs werden hier in Software nachgebildet und können bzgl. Anzahl (fast) beliebig skaliert werden. Im Grunde würde ich so vorgehen: Annahme: es soll ein Synthesizer mit z. B. 8 gleichzeitig spielbaren Stimmen realisiert werden. Gebraucht wird: - im einfachsten Fall werden hierfür 8 DCOs gebraucht, d. h. müssen per Hardware realisiert oder per Software implementiert werden - eine oder mehrere Datenstrukturen, aus der möglichst schnell der nächste freie DCO ermittelt werden kann, dem man den nächsten zu spielbaren Ton zuordnen kann bzw. bei DCO-Freigabe (weil der gespielte Ton beendet wurde) der jeweilige DCO wieder als frei markiert werden kann. Stichwort 'verkettete Listen'. Auch sollte man sich Gedanken machen was passieren soll, wenn z. B. bei einem 8-stimmigen Synthesizer 9 Tasten gleichzeitig gedrückt? Alternativen sind hier: - die 9'te gedrückte Taste erzeugt keinen Ton - die 9'te gedrückte Taste erzeugt einen Ton, dafür wird einer der ersten 8 Töne (obwohl die zugehörige Taste gedrückt wird) beendet. Frage hier... welcher Ton wird beendet? Alternativen: der tiefste, momentan gespielte Ton oder der bisher am längsten gespielte Ton wird beendet. Gruß Christoph
Hallo, schau dir mal Audio Codecs an (z.B. den TLV320AIC23). Da sind schon DACs/ADCs und Puffer drinnen, womit du dir die PWM und die diversen Audio-Verstaerker sparen kannst. Dennoch musst du den Audio codec natuerlich nach wie vor schnell genug mit Daten fuettern. Lg, Stefan
Wenn es kein AVR sein muß, ist vielleicht dieses fertige Objekt für den Parallax Propeller interessant: http://forums.parallax.com/showthread.php?111867-Music-Synthesizer-object-with-General-MIDI-sound-set&highlight=midi+ariba Bei Verwendung von einer internen CPU (der Prop hat 8 Cores) sind so 10 Stimmen möglich, bei zwei internen CPU's kann man mit dem Code 20 Stimmen erzeugen. Der Democode spielt direkt Level-0-Mididateien ab.
Schon mal bei Elm Chang geguckt ? Hört sich echt gut an (hatte ich mal nachgebaut) und der Code ist nachvollziehbar... http://elm-chan.org/works/mxb/report.html
mrno schrieb: > Wenn es kein AVR sein muß, ist vielleicht dieses fertige Objekt für den > Parallax Propeller interessant: Mir ging es in erster Linie darum, es selbst zu bauen und so viel wie möglich aus dem Avr herauszuholen. Christoph schrieb: > Annahme: es soll ein Synthesizer mit z. B. 8 gleichzeitig spielbaren > Stimmen realisiert werden. > > Gebraucht wird: > - im einfachsten Fall werden hierfür 8 DCOs gebraucht, d. h. müssen per > Hardware realisiert oder per Software implementiert werden > - eine oder mehrere Datenstrukturen, aus der möglichst schnell der > nächste freie DCO ermittelt werden kann, dem man den nächsten zu > spielbaren Ton zuordnen kann bzw. bei DCO-Freigabe (weil der gespielte > Ton beendet wurde) der jeweilige DCO wieder als frei markiert werden > kann. Stichwort 'verkettete Listen'. Ich hab mir das auch mal durchgerechnet: Die verkettete Liste wird wohl wirklich das effektivste sein. Danke für das Hintergrundwissen über Synthesizer, wird mir helfen. Stefan schrieb: > schau dir mal Audio Codecs an (z.B. den TLV320AIC23). > Da sind schon DACs/ADCs und Puffer drinnen, womit du dir die PWM und die > diversen Audio-Verstaerker sparen kannst. Wär wenn es mit PWM funktioniert für später eine Idee. Allerdings frag ich mich ob ich das gelötet bekomme. Die HW hab ich heute gebaut. Als Ausgang wie PWM + Gegentaktverstärker + Tiefpass. Für ein Midinterface brauch ich aber noch einen Optokoppler, den muss ich mir noch kaufen. Deswegen werde ich es erstmal über eine Mididatei im Flash versuchen.
Mach folgendes: Du machst mehrere (z.Bsp 8) Tongeneratoren (z.Bsp. FM-Synthese) Die Töne erzeugst Du dann per DDS in einer Interrupt-Service Routine. Im Hauptprogramm wertest Du dann die Ton-An und Ton-Aus Befehle aus. Bei Ton-An suchst Du einen freien Generator und wirfst den an. Bei Ton-Aus suchst Du nach den Tongenerator der gerade den Ton ausgibst und schaltest den aus. Ich hab mal eine FM-Synthese in grob 20 Tz pro Kanal gemacht. Das geht ganz gut. Die Hüllkurve ist dann nochmal schwieriger. Die kannst Du vielleicht alle n-Samples machen. Mit Buffern würde ich nicht arbeiten, das bringt nicht wirklich was. Das Schöne an elektronischer Musik ist ja, dass Du immer sagen kannst "Das soll so klingen". :)
Christian Berger schrieb: > Mach folgendes: > > Du machst mehrere (z.Bsp 8) Tongeneratoren (z.Bsp. FM-Synthese) > Die Töne erzeugst Du dann per DDS in einer Interrupt-Service Routine. > Im Hauptprogramm wertest Du dann die Ton-An und Ton-Aus Befehle aus. Bei > Ton-An suchst Du einen freien Generator und wirfst den an. Bei Ton-Aus > suchst Du nach den Tongenerator der gerade den Ton ausgibst und > schaltest den aus. Ist Im Prinzip das gleiche, nur dass ich vorhabe in der Hauptschleife die ganzen Töne zu erzeugen. Der Vorteil im Buffer liegt darin, dass wenn mal kurz mehr Rechenleistung gebraucht wird nicht einzelne Töne ausfallen müssen. Ich habe mir den Programmablauf so vorgestellt: Main: - Wenn Buffer voll nächsten Schritt überspringen - nächtes Sample berechnen und in Buffer schreiben - a) evtl. neue midi-Befehle auswerten - b) Mididatei aus Flash bei Bedarf weiterverarbeiten ISR: - nächstes Sample aus Buffer ausgeben Wenn der Buffer langsam leer werden sollte, kann das Programm die Samplingfrequenz runterfahren, mit dem Nachteil das hohe Töne geschluckt werden. > Ich hab mal eine FM-Synthese in grob 20 Tz pro Kanal gemacht. Das geht > ganz gut. Die Hüllkurve ist dann nochmal schwieriger. Die kannst Du > vielleicht alle n-Samples machen Kann man mit FM-Synthese wirklich gut Instrumente nachahmen? Irgendwie kann ich das nicht glauben. Muss ich erstmal ausprobieren. > Das Schöne an elektronischer Musik ist ja, dass Du immer sagen kannst > "Das soll so klingen". :) Wobei ich finde, dass sich das Εrnst B✶ schrieb: > Den Link kennst du: http://www.linusakesson.net/hardware/chiptune.php ? nicht einmal so schlecht anhört. Ich glaube ich habe das schon mal gehört, jedoch wieder vergessen.
So, ich hab mal angefangen zu programmieren. Bisher hab ich nur einzelne Töne getestet in Sinus und Rechteckform. lineare (?) Hüllkurzen hab ich für Attack und Decay verwendet, Release hab ich noch nicht programmiert. Mein Problem ist gerade das ich midi nicht ganz verstanden habe. In einer Datei stehen die Datenbytes nacheinander. Irgendwo muss es aber da einen Zeiteinheit geben, die sagt nach x ms kommt der nächste Befehl an die Reihe. Orientiert habe ich mich an dieser Seite: http://home.snafu.de/sicpaul/midi/midi3.htm Diese Seite http://jakob-werner.de/Midi/Dateiaufbau.htm sagt schon mehr aus, trotzdem werde ich nicht schlau daraus. Heißt 24 Midizyklen pro Mentronomschlag, dass 24 Befehle pro Schlag verarbeitet werden? Zur Klangerzeugung: Im Internet stehen haufenweise Dinge über Effekte, Filter und Modulationen, aber nichts darüber, wie man konkret ein bestimmtes Instrument nachahmen kann. Der Sinus mit langsamen Attack und Decay hört sich schon annähernd nach Streicher an. Aber wie man das besser hinbekommt weiß ich auch nicht.
Ich verstehe immer weniger... http://jakob-werner.de/Midi/Dateiaufbau.htm Warum wird hier geschrieben, dass die Dauer der Note mit übergeben wird? Die wird doch durch den NoteOff Befehl signalisiert.
Um Naturinstrumente nachzuahmen, kommst du mit klassischer subtraktiver Synthese nicht zu realistischen Ergebnissen. Dazu werden entweder Samples verwendet oder Physical Modelling. Was den Dateiaufbau angeht: es handelt sich dabei wohl um die Beschreibung eines Standard-MIDI-Files, das ist im Grunde eine Steuerdatei für einen Sequenzer. Darin steht z.B. wie lange eine Note zu klingen hat, der Sequenzer setzt das dann entsprechend in Note On/Off-Befehle um und sendet diese zum richtigen Zeitpunkt an den Klangerzeuger.
@Samuel K. Wieso implementierst Du die MIDI-Datei Verarbeitung? Das ist normalerweise eine Aufgabe, die einem Sequenzer vorbehalten ist. Ich würde mich zuerst auf die Klangerzeugung konzentrieren und dem Ding zum Testen eine MIDI-IN Schnittstelle (da gibt es recht viele Beispiel im Internet) verpassen und zum Abspielen von MIDI-Dateien einen Sequenzer auf dem PC/Mac nutzen. Und erst wenn alles einigermaßen läuft würde ich darüber nachdenken MIDI-Dateien nativ zu verarbeiten. Gruß Christoph
> http://jakob-werner.de/Midi/Dateiaufbau.htm > Warum wird hier geschrieben, dass die Dauer der Note mit übergeben wird? > Die wird doch durch den NoteOff Befehl signalisiert. Wo wird die Dauer der Note übergeben? Gruß Christoph
Christoph schrieb: > @Samuel K. > > Wieso implementierst Du die MIDI-Datei Verarbeitung? Das ist > normalerweise eine Aufgabe, die einem Sequenzer vorbehalten ist. Ich > würde mich zuerst auf die Klangerzeugung konzentrieren und dem Ding zum > Testen eine MIDI-IN Schnittstelle (da gibt es recht viele Beispiel im > Internet) verpassen und zum Abspielen von MIDI-Dateien einen Sequenzer > auf dem PC/Mac nutzen. Und erst wenn alles einigermaßen läuft würde ich > darüber nachdenken MIDI-Dateien nativ zu verarbeiten Da hast du Recht. Ich bin inzwischen auch zu diesem Entschluss gekommen. Ich werde erstmal ein eigenes Format benutzen und später versuchen midi zu verarbeiten. Christoph schrieb: >> http://jakob-werner.de/Midi/Dateiaufbau.htm >> Warum wird hier geschrieben, dass die Dauer der Note mit übergeben wird? >> Die wird doch durch den NoteOff Befehl signalisiert. > > Wo wird die Dauer der Note übergeben? Hier:
1 | 9045 6E81 20 Spiele Note A in der 5 Oktave |
2 | (siehe Tabelle 4:) |
3 | 9 = Note ein 0=Kanal 1 |
4 | 45 = Note A in der 5 Oktave |
5 | 6E = Anschlagstärke |
6 | 81 = Dauer der Note |
Ich bin gerade dabei die Tonerzeugung, welche ich erst in C geschrieben habe in Assembler zu übersetzen. Wobei ich das ziemlich einfach finde, obwohl das mein erstes Assemblerprojekt ist. Die ISR , welche den Buffer ausgibt dauert durchschnittlich 18,2 Takte inklusiv Aufruf (6 Takte) und reti (4 Takte). Ich werde den Avr erstmal mit 8Mhz programmieren, da ich gemerkt habe, dass ich keinen 16Mhz Quarz habe.
1 | ;**************************************************** |
2 | ;* Gepufferte PWM-Ausgabe * |
3 | ;* * |
4 | ;* Minimale Laufzeit: 18 Takte (15x) * |
5 | ;* Maximale Laufzeit: 21 Takte (1x) * |
6 | ;* Durchschn. Laufzeit: 18,1875 Takte * |
7 | ;* CPU-Belastung: 7,1 % * |
8 | ;* * |
9 | ;* Verwendete Register: tim0ovf, X-Pointer, * |
10 | ;* isrtemp * |
11 | ;* * |
12 | ;**************************************************** |
13 | |
14 | ;Timer0 OVF Interrupt Handler: Gepufferte Ausgabe der Samples per PWM |
15 | TIM0_OVF: ; 6 : |
16 | in isrtemp, SREG ; 1 : SREG sichern |
17 | |
18 | Ld tim0ovf, X+ ; 2 : nächstes Byte aus Ringpuffer lesen |
19 | sts OCR1AL, tim0ovf ; 2 : 11 Takte bis zum neuen PWM Wert schreiben |
20 | |
21 | cpi XL, LOW(BUFEND) ; 1 : X-Pointer am Ende des Buffers |
22 | breq BUFOVF ; 1 : Wenn ja, X-Buffer zurücksetzen |
23 | ; : BREQ wird hier genommen, da nur in 1 von 16 ISR Aufrufen zu BUFOVF gesprungen werden muss |
24 | |
25 | out SREG, isrtemp ; 1 : SREG zurückschreiben |
26 | reti ; 4 : |
27 | ;--- |
28 | ;18 |
29 | |
30 | |
31 | BUFOVF: ; 1 : |
32 | ldi XH, HIGH(BUF) ; 1 : X-Pointer mit Startadresse |
33 | ldi XL, LOW(BUF) ; 1 : des Buffers laden |
34 | |
35 | out SREG, isrtemp ; 1 : SREG zurückschreiben |
36 | reti ; 4 : |
37 | ;--- |
38 | ;21 |
39 | |
40 | ;**************************************************** |
Schneller geht das nicht, oder?
Als ich den Tiefpass baute, habe ich einfach die Schaltung http://www.mikrocontroller.net/articles/Klangerzeugung genommen. Wenn ich die Grenzfrequenz nach
berechne, komme ich auf
Das ist eigentlich zuwenig, aber ich habe es erstmal gelassen. Trotzdem ergeben sich diese komischen Wellenformen. Meiner Meinung nach eindeutig wegen PWM. Eine Wavedatei habe ich auch noch angehängt. Aufgenommen habe ich das ganze mit 96kHz mit meiner Soundkarte (ein Oszi besitze ich leider nicht). Samplerate des Synthesizers liegt bei 31250Hz. Das es nicht wirklich wie Sinus aussieht kommt zum Ganzen noch dazu.
Mir fällt gerade ein, dass die Schwingung so komisch aussieht, da das ja 2 Sinus addiert sind. Wenn ich mit Audacity einen Tiefpass um 1khHz nutze. Erscheint eine ziemlich saubere Schwingung (mit 200Hz noch besser). Stimmt meine obrige Rechnung etwa nicht? Die ist doch genau nach der Formel.
Mit einem einfachen RC-Tiefpass bekommst Du das PWM-Signal nicht besser weg. Dein Ohr ist ein besserer Tiefpass und die hohen PWM-Frequenzen hörst Du eh nicht mehr. Das einzige Problem könnten die Hochtöner in Deiner Anlage sein die eventuell unter den hohen Frequenzen "leiden". 1Khz fg ist etwas wenig, ich habe immer 3kHz verwendet, das klingt besser.
chris schrieb: > Mit einem einfachen RC-Tiefpass bekommst Du das PWM-Signal nicht besser > weg. Dein Ohr ist ein besserer Tiefpass und die hohen PWM-Frequenzen > hörst Du eh nicht mehr. In der dem Sample höre ich ein sehr hohes Pfeifen. Das Problem ist, je tiefer der Ton ist, desto überlagernder wird es. > Das einzige Problem könnten die Hochtöner in > Deiner Anlage sein die eventuell unter den hohen Frequenzen "leiden". > 1Khz fg ist etwas wenig, ich habe immer 3kHz verwendet, das klingt > besser. Die Hohen Frequenzen werden ja zu schwach gedämpft: Die höchsten Punkte des Spektrumanalysers sind 141Hz (Cis), 205Hz (Gis), 7686Hz und 15816. Die letzten beiden deutlich gedämpft, aber trotzdem herausragend. Ich hab jetzt einen Tiefpass 2. Ordnung gebaut, der klingt besser.
Samuel K. schrieb: > mrno schrieb: >> Wenn es kein AVR sein muß, ist vielleicht dieses fertige Objekt für den >> Parallax Propeller interessant: > > Mir ging es in erster Linie darum, es selbst zu bauen und so viel wie > möglich aus dem Avr herauszuholen. Zum Selbstbauen wäre für sowas ein dsPIC sinniger. Der hat mindestens die dreifache Rechenleistung, breitere Register, extra DSP-Befehle und es gibt auch welche, die ein extra Interface für I2C oder AC97 Codecs haben. Ein dsPIC30F4011 im DIL40 kostet bei Reichelt 5.90. Man muss sich ja die Sache nicht mit Gewalt unnötig kompliziert machen. Sag ich zumindest. fchk
Wenn ich mich recht erinnere (ich las den Thread kleckerweise, also nicht in einem Rutsch), arbeitest Du mit dem Mega8 mit 16 MHz. Damit erreichst Du am 8-Bit-Timer eine PWM-Frequenz von 62,5 kHz. Mit einem Tiny85, der mit internem Takt von 8 MHz rattert, erreichst Du dank interner PLL für Timer1 eine PWM-Frequenz von 250 kHz. Diese lässt sich schon etwas leichter ausfiltern, da reicht ein einfacher RC-Tiefpass. Und nein, ich will keinen Synthesizer mit AVR bauen, es reicht mir, dass ich damit halbwegs brauchbare einfache Soundmodule für Gartenbahn-Loks realisieren kann. ...
Hannes Lux schrieb: > Wenn ich mich recht erinnere (ich las den Thread kleckerweise, also > nicht in einem Rutsch), arbeitest Du mit dem Mega8 mit 16 MHz. Damit > erreichst Du am 8-Bit-Timer eine PWM-Frequenz von 62,5 kHz. Ich musste leider feststellen, dass ich keinen 16MHz Quarz habe, deswegen hab ich erstmal die internen 8Mhz des Atmega88 genommen. > Mit einem Tiny85, der mit internem Takt von 8 MHz rattert, erreichst Du > dank interner PLL für Timer1 eine PWM-Frequenz von 250 kHz. Diese lässt > sich schon etwas leichter ausfiltern, da reicht ein einfacher > RC-Tiefpass. Das war mir noch nicht bekannnt, geht das auch mit den Atmegas? Tiny scheidet trotzdem aus, da HW-Multiplizierer fehlt. Ich hab mir inzwischen auch ein 16bit DAC bestellt, mal schauen wie sich das anhören wird.
Samuel K. schrieb: > Hannes Lux schrieb: >> Wenn ich mich recht erinnere (ich las den Thread kleckerweise, also >> nicht in einem Rutsch), arbeitest Du mit dem Mega8 mit 16 MHz. Damit >> erreichst Du am 8-Bit-Timer eine PWM-Frequenz von 62,5 kHz. > > Ich musste leider feststellen, dass ich keinen 16MHz Quarz habe, > deswegen hab ich erstmal die internen 8Mhz des Atmega88 genommen. Dann hast Du nur 31,25 kHz PWM-Frequenz. Das ist Telefon-Qualität und hat mir für die Ausgabe der Glocke einer Schranke (mit Modellbauservos als Antriebe) geradeso gereicht. > >> Mit einem Tiny85, der mit internem Takt von 8 MHz rattert, erreichst Du >> dank interner PLL für Timer1 eine PWM-Frequenz von 250 kHz. Diese lässt >> sich schon etwas leichter ausfiltern, da reicht ein einfacher >> RC-Tiefpass. > > Das war mir noch nicht bekannnt, Dafür gibt es Datenblätter. > geht das auch mit den Atmegas? Nein, leider nicht. PLL für den Timer ist meines momentanen Wissens nach nur bei Tiny25/45/85, Tiny24/44/84, Tiny15, Tiny26 und Tiny261/461/861 implementiert. > Tiny > scheidet trotzdem aus, da HW-Multiplizierer fehlt. Tja, man kann nicht immer alles haben... > > Ich hab mir inzwischen auch ein 16bit DAC bestellt, mal schauen wie sich > das anhören wird. Der wird Dir nicht nützen, denn mit 16-Bit-Sounderzeugung ist der AVR hoffnungslos überfordert. Zumindest, wenn man das Endprodukt "Synthesizer" nennen will. ...
Hannes Lux schrieb: > Der wird Dir nicht nützen, denn mit 16-Bit-Sounderzeugung ist der AVR > hoffnungslos überfordert. Zumindest, wenn man das Endprodukt > "Synthesizer" nennen will. Mal schauen was sich machen lässt;) Zudem ist es eine Herausforderung das in Asm zu schreiben. Ich bin gespannt wann ich den Überblick verliere - das ist ein Spaghetticode ohne Ende. Da ich gerade sowieso nur 8bit PWM nutze, nehme ich eine 8bit Sinustabelle, sobald der 16bit DAC da ist, werde ich das verwenden: http://www.mikrocontroller.net/articles/AVR_Arithmetik/Sinus_und_Cosinus_%28Lineare_Interpolation%29#_note-3.4.6 Der Pausenbefehl funktioniert nicht ganz. Liegt das daran, dass PWM im Normalen Modus nie 0 sein kann?
Mit nem TLC7528 (2 8-BitWandler mit gemeinsamen paralell-Interface+Latch), Reichelt, 1,60 Euro würd das ganze Projekt vermutlich bissl lockerer laufen. Mit PWM - absolut falscher Anfang. Mit TLC ist 100 khz Sampling (Timer-Interrupt) und noch genug Rechenzeit für anderes kein Thema.
t-Felde schrieb: > Mit nem TLC7528 (2 8-BitWandler mit gemeinsamen > paralell-Interface+Latch), > Reichelt, 1,60 Euro würd das ganze Projekt vermutlich bissl lockerer > laufen. Mit PWM - absolut falscher Anfang. > Mit TLC ist 100 khz Sampling (Timer-Interrupt) und noch genug Rechenzeit > für anderes kein Thema. Ich habe hier leider keinen DAC. Deswegen erstmal mit den Mitteln, welche mir zu Verfügung stehen. Eine Parallele Ansteuerung wäre vielleicht wirklich vorteilhaft. Bei 2 Bytes in der ISR per SPI zu schieben rechne ich mit 24 Takten, was leider deutlich langsamer als 8bit PWM, mit zuzeit ~13.2 Takten, ist.
Mit nem DAC haste halt wirkliche 8 Bit, mit jenseit 100 khz beschränkt sich der Rest auf nen OP als Impedanzwandler und RC-Glied. Der TLC7528 unterstützt Voltage-Mode, das Datenblatt von Analog Devices (das von TI sagt da nix zu) offenbart allerdings das die Referenz in diesem Fall nicht höher als 2,5 Volt liegen soll. Aber für Audio-Out ist das alles OK. Wenn nur diese Versandkosten nicht wären, was ?
Samuel K. schrieb: > Ich habe hier leider keinen DAC. Deswegen erstmal mit den Mitteln, > welche mir zu Verfügung stehen. Eine Parallele Ansteuerung wäre > vielleicht wirklich vorteilhaft. Ja, ein vernünftiges, der Aufgabe angemessenes Hardwarekonzept hätte durchaus Vorteile. Anderswo werden die Audiosamples per DMA auf das Data Converter Interface (DCI) geschoben. Da hast Du die Probleme, die Du aktuell aufgrund ungeeigneter Hardware hast, nicht mehr. fchk
Frank K. schrieb: > Da hast Du die Probleme, die Du aktuell > aufgrund ungeeigneter Hardware hast, nicht mehr. Ich möchte das einfach aus dem Avr probieren. Lerneffekt in Assembler ist auch gewollt. Anbei gut 30 Sekunden, des ersten richtigen Stücks, welches der Synthesizer spielt. 3 von 4 Kanälen werden genutzt. Bisher nur Sinus ohne Hüllkurven. t-Felde schrieb: > Mit nem DAC haste halt wirkliche 8 Bit, mit jenseit 100 khz > beschränkt sich der Rest auf nen OP als Impedanzwandler und > RC-Glied. Der TLC7528 unterstützt Voltage-Mode, das Datenblatt > von Analog Devices (das von TI sagt da nix zu) offenbart allerdings das > die Referenz in diesem Fall nicht höher als 2,5 Volt liegen soll. > Aber für Audio-Out ist das alles OK. > Wenn nur diese Versandkosten nicht wären, was ? Ich bestell ihn ja bei der nächsten Reichelt Bestellung. Einzeln wäre das 1,60€+3€ Aufschlag (<10€) + 5,70€ Versang = 10,30€!
Hier eine Version mit nachträglichem softwareseitigem Tiefpass. Vom PWM sieht und man nun nichts mehr. Leider kratzt es immer noch bei den hohen Tönen. Vielleicht Clipping, Audacity ist aber komischerweise nicht voll ausgesteuert. Ich merke gerade: In der MP3 Kompression hört man das kratzen fast nicht mehr.
Das hier ist mit dem Atmega-Sid: http://www.roboterclub-freiburg.de/atmega_sound/atmegasid_V1.0.mp3 Den Controller habe ich über einen RC-Tiefpass an die Anlage angeschlossen. Mann kann beim Glockenton die Schwebungen hören, die bei der Überlagerung der 3 Dreiecksschwingungen entstehen. Sehr gut kann man auch die verwendeten Hüllkurven am leiser werden der Töne erkennen. Es ist meiner Meinung nach verwunderlich, dass sich das Ganze noch so gut anhört, weil für die Dynamik ( also die Amplitude ) der einzelnen Oszillatoren nur 256/3 der PWM bleiben.
Die Hüllkurven funktionieren jetzt auch. Jetzt geht es langsam zur Tonerzeugung: Verschiedene Klänge wären schonmal nicht schlecht. In diesem Projekt http://www.linusakesson.net/hardware/chiptune.php sollen sie (wenn ich mich nicht verlesen habe) nur Sägezahn verwenden. Sägezahn in Audacity klingt allerdings nicht so doll. Vielleicht kann mir einer ein paar Tipps geben wie man einfach (für den avr) verschiedene Klänge erzeugt. Wenn ich das mit FM-Synthese machen wollte müsste ich für ein Klavier min. 10 Obertöne zum normalen Ton mischen. Vielleicht könnte man mit Modulation Obertonreichenfrequenzen mehr erreichen. Wie simuliert man eigentlich ein Schlagzeug am Besten? Das sind keine konstante Frequenzen mehr. Gibt es eine Seite im Internet welche solche Waveformen enthält. Damit könnte man auch gut Physical Modeling machen.
Google mal nach "jesper minidds". Wenn man das Increment des Phasenakkus variiert moduliert man die Frequenz. Das ganze in 2 Buffer pusten und mehrfach durchführen. DA-Wandler dann einfach zwischen den Buffern umschalten. In einem wird gerechnet, der andere wird gerade ausgegeben. Wär nen Ansatz für AVR.
Samuel K. schrieb: > Wie simuliert man eigentlich ein Schlagzeug am Besten? Das sind keine > konstante Frequenzen mehr. Gibt es eine Seite im Internet welche solche > Waveformen enthält. Damit könnte man auch gut Physical Modeling machen. Kennst Du noch die sogenannten Soundtracker von vor 20 Jahren? Das Zeugs war damals auf dem Amiga sehr verbreitet. Konzept: Du hast n Audiokanäle, die gleichzeitig abgespielt werden. Jeder Kanal hatte eine Liste von Takten, jeder Takt bestand aus einer Liste von Noten und Pausen plus Effekte plus Verweis auf das jeweilige Instrument oder Sample. Die Takte konnten wiederverwendet werden. Die Instrumente werden durch digitalisierte Samples erzeugt, die Tonhöhen durch Variation der Samplerate beim Abspielen. CPU-Belastung war minimal - die Amiga Soundhardware hat das meiste selber gemacht. Gabs später auch unter DOS und Windows, nachdem es für den PC brauchbaren Sound gab. Das Konzept erwies sich als ziemlich flexibel, wurde aber durch MP3 und Konsorten obsolet. Der Dump aus Playlisten und Samples nannte sich "Module" (.mod) .mod war auf die Amiga Soundhardware (4 Kanäle, 8 Bit, Big Endian) zugeschnitten und mehr oder weniger ein reiner Memory Dump der Software. Später kamen dann noch andere Varianten für mehr Kanäle, 16 Bit Samples etc hinzu. (.stm, .669, .xm) usw. Im Netz gibts hinreichend viele Audiodateien, und WinAmp kann die auch abspielen (ansonsten Delitracker etc nehmen). Dieses Konzept ist eigentlich ziemlich einfach umzusetzen, die passende Hardwarearchitektur vorausgesetzt. Samples brauchen halt Speicherplatz, und zwar nicht zu knapp. fchk Nachtrag: Lies das! http://de.wikipedia.org/wiki/Tracker_%28Musik%29
vor 20 Jahren.....da hab ich gerade den Atari 520st bearbeitet. Der hatte so nen Soundkäfer von Yamaha. M68000 32bit interne Register und fetter linearer Adressraum ist aber net AVR. Ich schätz mal auch auf den großen AVR'S wird es a bissl knapp mit dem Flash, und breite Wege nach außen brauchen auch nen paar Takte.
>In >diesem Projekt http://www.linusakesson.net/hardware/chiptune.php sollen >sie (wenn ich mich nicht verlesen habe) nur Sägezahn verwenden. Sägezahn >in Audacity klingt allerdings nicht so doll. Ein Sägezahn klingt ziemlich rau. Dreiecksschwingungen klingen hingegen fast wie ein Sinus, wie Du beim SID hören kannst: http://www.roboterclub-freiburg.de/atmega_sound/atmegasid_V1.0.mp3 Dort gibt es nämlich nur die Wellenformen Dreieck, Sägezahn, Rechteck und Rauschen. Die Wellenformen werden alle via DDS erzeugt: http://de.wikipedia.org/wiki/Direct_Digital_Synthesis Wenn Du einen Sinus brauchst, kannst Du einfach eine Tabelle anlegen und mit dem DDS-Pointer die Werte aus der Tabelle lesen.
In der aktuellen Make: gibt es ein Project für nen Synth mit nem Picaxe.
Frank K. schrieb: > Kennst Du noch die sogenannten Soundtracker von vor 20 Jahren? Das Zeugs > war damals auf dem Amiga sehr verbreitet. Bin leider erst 16 :( Frank K. schrieb: > Die Instrumente werden durch digitalisierte Samples erzeugt, die > Tonhöhen durch Variation der Samplerate beim Abspielen. CPU-Belastung > war minimal - die Amiga Soundhardware hat das meiste selber gemacht. > Gabs später auch unter DOS und Windows, nachdem es für den PC > brauchbaren Sound gab. Das Konzept erwies sich als ziemlich flexibel, > wurde aber durch MP3 und Konsorten obsolet. Darauf wird es hinauslaufen, wenn es eine Vielzahl von Klängen geben soll. Ich überlege mir gerade ob es Sinn machen würde einen Atmega8515 mit einem Flashrom zu versehen, der die Klänge speichert. I2C und SPI wären für die Klangerzeugung zu langsam. chris schrieb: > http://de.wikipedia.org/wiki/Direct_Digital_Synthesis > Wenn Du einen Sinus brauchst, kannst Du einfach eine Tabelle anlegen und > mit dem DDS-Pointer die Werte aus der Tabelle lesen. Ohne die Theorie zu wissen habe ich es (wenn ich es richtig verstanden habe) genau so gemacht: De Tontabelle enthält Zahlen, welche pro Durchlauf auf den Index der Klangtabelle addiert werden.
Samuel K. schrieb: >> Kennst Du noch die sogenannten Soundtracker von vor 20 Jahren? Das Zeugs >> war damals auf dem Amiga sehr verbreitet. > > Bin leider erst 16 :( Die Gnade der späten Geburt. > Frank K. schrieb: >> Die Instrumente werden durch digitalisierte Samples erzeugt, die >> Tonhöhen durch Variation der Samplerate beim Abspielen. CPU-Belastung >> war minimal - die Amiga Soundhardware hat das meiste selber gemacht. >> Gabs später auch unter DOS und Windows, nachdem es für den PC >> brauchbaren Sound gab. Das Konzept erwies sich als ziemlich flexibel, >> wurde aber durch MP3 und Konsorten obsolet. > > Darauf wird es hinauslaufen, wenn es eine Vielzahl von Klängen geben > soll. Ich überlege mir gerade ob es Sinn machen würde einen Atmega8515 > mit einem Flashrom zu versehen, der die Klänge speichert. I2C und SPI > wären für die Klangerzeugung zu langsam. Sagte ich nicht bereits, dass Du auf der falschen Plattform unterwegs bist? Schau Dir mal an, wie groß die Samples bzw die .mods sind, dann merkst Du es vielleicht selber. fchk
SRAM's wären fix, und man kann die Daten mit ner Knopfzelle erhalten, wenn man Teile mit LOW-Standby Current benutzt. Betankung über UART. Braucht aber PORTS en Masse.
t-Felde schrieb: > SRAM's wären fix, und man kann die Daten mit ner Knopfzelle erhalten, > wenn man Teile mit LOW-Standby Current benutzt. > Betankung über UART. > Braucht aber PORTS en Masse. Ich dachte da ich sowieso fast nur lesen muss, wäre ein Flash besser geeignet. 6MB/s sollten die auch schaffen. Gerade hab ich eher mehr PRobleme einen guten Midikonverter zu programmieren. Ich habe mal schnell einen gefrickelt (mithilfe von dieser Lib: http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx), aber der hält die Timing nicht genau ein.
MEHRERE Module mit großen Megas wären wohl am einfachsten, die z.B. auf nen Summierer gehen oder wo der Output des einen die Referenzspannung für den R2R-Wandler des nächsten ist. Da hat man dann Rechenleistung, ist skalierbar und billig ist es auch. Und bei 8-Bit R2R-Wandlern die hintereinander hängen hat es dann schon mehr als nur 8 Bit Dynamik. Ist aber eher was für DDS-Geschichten.
Vielleicht noch was um Anregungen für den Sound zu holen: http://belogic.com/uzebox/index.asp Auch nur ein AVR, der nebenher noch Sound macht :-)
>Damit könnte man auch gut Physical Modeling machen. Probier mal den Karplus-Strong Algorithmus. Damit kannst Du Seiteninstrumente simulieren ( z.B. E-Gitarre ). Hab ich schon auf dem AVR gemacht, hört sich genial an.
t-Felde schrieb: > MEHRERE Module mit großen Megas wären wohl am einfachsten, > die z.B. auf nen Summierer gehen oder wo der Output des > einen die Referenzspannung für den R2R-Wandler des nächsten ist. > Da hat man dann Rechenleistung, ist skalierbar und billig ist > es auch. Und bei 8-Bit R2R-Wandlern die hintereinander > hängen hat es dann schon mehr als nur 8 Bit Dynamik. > Ist aber eher was für DDS-Geschichten. Also bei jetziger Konfiguration komme ich auf ca. 1.5Mhz pro Kanal. D.h. 10 Kanäle sind bei 16Mhz drin. Und wenn nicht alle die ganze Zeit spielen können es auch 16 sein. Oder der Mega wird auf 24Mhz übertaktet. Zu den Kosten: 16x2€=32€ für einen kleinen Synthesizer. Das ist für mich nicht billig. Ich werde versuchen die Kosten unter 10€ zu halten.
Oh Sorry. Ich nahm an das du mehr investieren willst, da du Anfangs des Threads 16 Bit angepeilt hattest. Viel Spaß !
> MEHRERE Module mit großen Megas wären wohl am einfachsten, Oder mit Attnys http://www.hobby-roboter.de/forum/viewtopic.php?f=5&t=3
t-Felde schrieb: > Oh Sorry. > Ich nahm an das du mehr investieren willst, da du Anfangs des Threads > 16 Bit angepeilt hattest. > Viel Spaß ! Mit einer Tabelle 16bit 256 Werte, werden die Werte erst gedoppelt bei f = Samplerate / 256. In meinem Fall ~120Hz. Zwischenschritte könnte man mit einer Heuristik glätten. chris schrieb: >> MEHRERE Module mit großen Megas wären wohl am einfachsten, > Oder mit Attnys > http://www.hobby-roboter.de/forum/viewtopic.php?f=5&t=3 Das finde ich übertrieben. Die Attinys können ja nicht mal mul. Wie der die Hüllkurven effektiv berechnet ist mir Schleierhaft. Meine Mix Routine ohne mul möchte ich mir gar nicht vorstellen:
1 | ldd temp4, Y+hucuc ;Hüllkurvenwert laden |
2 | ;Lautstärke |
3 | ldd temp3, Y+vol |
4 | mulsu temp2, temp4 ;Highbytes multiplizieren |
5 | add sample, r0 |
6 | adc sample2, r1 |
7 | mulsu temp2, temp3 ;Lowbyte der Volume mit Highsample multiplizieren |
8 | add sample, r1 |
9 | adc sample2, nullreg |
10 | mul temp, temp4 ;Lowsample mit Highvolume multiplizieren (unsigned) |
11 | add sample, r1 |
12 | adc sample2, nullreg |
chris schrieb: > Probier mal den Karplus-Strong Algorithmus. Damit kannst Du > Seiteninstrumente simulieren ( z.B. E-Gitarre ). Hab ich schon auf dem > AVR gemacht, hört sich genial an. Sieht interessant aus, dennoch tendiere ich wahrscheinlich zu Tabellen, da das 1. schneller geht und 2. ich sowieso ein paar Tabelle anlegen werde.
Haeh schrieb: > midi synth mit msp430fr5739 > http://www.43oh.com/forum/viewtopic.php?f=9&t=1176 Nicht schlecht. Das Stück soll meiner auch spielen können. Außerdem hat er in seiner Beschreibung mir einen Tipp gegeben, wie ich ganze 4 Takte in der Hauptroutine sparen könnte. So komme ich von 51 Takten auf 47. Meine Gedanken zum großen Wavetable: An den Atmega8515 könnte man einen externen Flash anschließen, nur gibts die entweder nur als OTP oder zu klein oder zu teuer. Ein 128KB SRAM gibts bei reichelt schon für 1,85€. Um die Daten bei Start in den Ram zu laden kann man eine SD-Karte als Wavetablespeicher+Musik nehmen. Der Mega8515 hat zwar nur 512B Ram, kann aber zum SD-Kartenlesen den externen benutzen. Sollte der Flash nicht reichen, wäre es möglich eine größere Funktionsblöcke (natürlich nicht den Synthesizer) in den Ram zu packen und diesen dann als Flash zu verkaufen. Um Ramdaten zu lesen muss man nur eine Ram-lese Funktion aus dem Flash aufrufen. Ist das so machbar oder gibt es bessere Lösungen? Der Reichelt Ram hat leider nur 70ns, d.h. ab 14Mhz muss ich ein Waitstate bis 28Mhz einbauen. Wenn ich den µC übertakten sollte werde ich wahrscheinlich sowieso nur bis 24Mhz gehen (50%). Der MIDI-Konverter funktioniert endlich halbwegs und die die Musik ist mehrere KB groß, d.h. die SD-Karte sollte bald her.
>Sieht interessant aus, dennoch tendiere ich wahrscheinlich zu Tabellen, >da das 1. schneller geht und 2. ich sowieso ein paar Tabelle anlegen >werde. Das wird sich aber nicht so gut anhören, weil eine Gitarrensound relativ lange zum ausklingen braucht. Ausserdem kannst Du die Seiten mehrmals hintereinander zupfen, während der alte Ton noch ausklingt.
Samuel K. schrieb: > Die Attinys können ja nicht mal mul. Wie der > die Hüllkurven effektiv berechnet ist mir Schleierhaft. mul ist auch nur add ;-) kostet auf dem tiny nur Zeit und damit Stimmen. Beitrag "2-Kanal ADSR-Synthesizer für ATTinies(85, 2313 u.a.)" Hier habe ich sogar bei Decay und Release 1/x^2 verwendet, insgesamt 7 SW-Multiplikationen alle 512 Takte. Alles nur eine Frage der Umsetzung. Aber wenn's um den Sound bzw. Synthesizer und nicht um den Tiny geht kann man sich sowohl die Mühe als auch den Rechenaufwand sparen und nimmt besser einen ATmega. Mark
>Das finde ich übertrieben. Die Attinys können ja nicht mal mul. Wie der >die Hüllkurven effektiv berechnet ist mir Schleierhaft. Meine Mix >Routine ohne mul möchte ich mir gar nicht vorstellen: Naja, wenn Dir Rechenleistung so wichtig ist, dann würde ich nen LPCExpresso für 25 Euro kaufen: http://ics.nxp.com/lpcxpresso/ Da lässt sich Synthesizer-mässig schon etwas mehr als mit'm Atmega bewerkstelligen.
Mark L. schrieb: > Samuel K. schrieb: >> Die Attinys können ja nicht mal mul. Wie der >> die Hüllkurven effektiv berechnet ist mir Schleierhaft. > > mul ist auch nur add ;-) kostet auf dem tiny nur Zeit und damit Stimmen. > Beitrag "2-Kanal ADSR-Synthesizer für ATTinies(85, 2313 u.a.)" > Hier habe ich sogar bei Decay und Release 1/x^2 verwendet, insgesamt 7 > SW-Multiplikationen alle 512 Takte. Ich hab eine Hüllkurvenauflösung von 8bit. Berechnet wird ebenfalls alle 512 Takte. Das ganze dauert im worst case 143 Takte. Im Durchschnitt eher 100. Attiny wird jetzt sowieso überflüssig, da ich das XMEM Interface vom Atmega8515 ausprobieren werde. chris schrieb: > Naja, wenn Dir Rechenleistung so wichtig ist, dann würde ich nen > LPCExpresso für 25 Euro kaufen: > http://ics.nxp.com/lpcxpresso/ > > Da lässt sich Synthesizer-mässig schon etwas mehr als mit'm Atmega > bewerkstelligen. Das ist mir alles klar, aber: -erster Assembler Projekt (vorher nur c) -Avr endlich mal auslasten können
>-erster Assembler Projekt (vorher nur c)
Als Assemblerprojekt ist das sehr gut geeignet. Postest Du das Ergebnis?
Eine Audio-Datei wäre nicht schlecht.
Gruß,
chris
Übrigens: Der Karplus-Stron Algortihmus wäre ziemlich einfach zu implementieren: 1. einen Ringbuffer erzeugen 2. Den Ringbuffer mit Zufallswerten füllen 3. Im den Mittelwert aus 2 Werten bilden und in den Ringbuffer zurückschreiben. Das ganze immer zyklisch durchlaufen. Die Länge des Ringbuffers und die Geschwindigkeit, mit der er durchlaufen wird ergibt die Frequenz des Gitarrensignals.
chris schrieb: > Als Assemblerprojekt ist das sehr gut geeignet. Postest Du das Ergebnis? > Eine Audio-Datei wäre nicht schlecht. Ja ich werde das Ergebnis posten. Allerdings ist der Code jetzt noch ziemlich unaufgeräumt und zu wenig kommentiert um als Außenstehender durchzublicken. Ich hab heute mal den Schaltplan für die HW gemacht, da muss ich aber nochmal genauer drüber schauen, es könnten noch Fehler drin sein. Hmm, den letzte (und besten) Test hab ich leider nicht aufgenommen. Ich kann aber beim nächsten mal wieder eine Audiodatei posten. Bisher ist es nur ein 4Kanal Sinus mit Hüllkurven (ADSR). chris schrieb: > Übrigens: Der Karplus-Stron Algortihmus wäre ziemlich einfach zu > implementieren: > > 1. einen Ringbuffer erzeugen > 2. Den Ringbuffer mit Zufallswerten füllen > 3. Im den Mittelwert aus 2 Werten bilden und in den Ringbuffer > zurückschreiben. Das ganze immer zyklisch durchlaufen. > > Die Länge des Ringbuffers und die Geschwindigkeit, mit der er > durchlaufen wird ergibt die Frequenz des Gitarrensignals. Naja die Tabelle ist auch schnell: Freqzähler laden: 2 Takte Ext. Sram-Byte lesen: 3 Takte Freqzähler erhöhen: 2 Takte speichern: 2 Takte -------------------------------- 9 Takte Ich befürchte das jeder Algo zu langsam wäre. Evtl könnte man sie aber als Klang 128+ optional einbauen.
So, ein Sample zu wiederholen scheint doch nicht so einfach. Ich habe heute ein Klavierton aufgenommen und eine Schwingung in der Mitte herausgeschnitten. Leider klingt es mehr nach Orgel als Klavier. Kann man nicht einfach eine Schwingung wiederholen oder ist das zu primitiv? Anbei der Test, der sich nach Orgel anhört (4 Kanäle). Das Stück ist nichts besonderes - es ist jedoch nicht so einfach Mididateien ohne Schlagzeug mit max. 4 Tönen gleichzeitig zu finden.
Auch noch den Anhang vergessen... Der Atmega8 ist übrigens jetzt schon ziemlich ausgereizt. Der Synthesizer Code braucht zwar nur 600B, das Stück dafür 5KB.
Du musst Dir GEdanken machen, welche Effekt da rein sollen. Nur so ein GEzierpe ist keine Verbsserung zu dem Kram, der überall ladbar ist.
Hi Kleiner Zwischenstand: Ich habe mich doch wieder umentschieden, obwohl die Platine schon geätzt und bestückt war. Das Projekt soll ohne große HW auskommen. Einen DA kann man natürlich trotzdem nutzen. Ich hätte es nicht für möglich gehalten, aber 1 Kanal / Mhz ist möglich! Und das ohne Einschränkungen zur bisherigen Funktionalität. Allerdings sind die Kanäle bisher auf 17 begrenzt (bleibt wahrscheinlich auch so). Version 0.4 beinhaltet zusätzlich: - 5 Intrumente (beliebig erweiterbar, universelle 8Byte ADSR-Hüllkurvenkonfiguration) - Volume für jeden Kanal An alle Skeptiker: Die Samples der Intrumente sind zwar 8bit, gemischt wird aber mit 16bit (zumindest in der ab der nächsten Version, fehlen nur noch ein paar kleine Änderungen). Das kostet 1.3 Takte / Kanal mehr. Leider wachsen die Anforderungen des Synth stetig. Zurzeit bin ich bei 1KB für den Code + 264Byte / Instrument + Musik. Rambedarf bei 17 Kanälen beträgt ~670Byte. Mul ist erforderlich. Eine Portierung auf Attinys würde schätzungsweise nur 6 Kanäle schaffen. Code kommt bald nach. Gruß, Samuel
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.