Hi, ich möchte mir einen Hardware-Sequencer bauen, und habe dazu ein paar Fragen zur Auswahl der Hardware. Geplant ist ein 16-Spuriger/64-Step-Sequencer der WAV-Samples und Synth-Algorithmen (bzw. eingebaute Synth-Hardware) triggern soll. Das Teil soll später 47 Buttons, 18 Drehregler sowie 4 kleine TFT-Displays steuern können. (Ich habe letztes Jahr eine Android-App (in JAVA) geschrieben welche genau das macht, doch stieß ich sehr schnell an Grenzen wenn es darum ging mehrere Samples zeitgleich zu triggern. Daher nun der Versuch mit der dafür geeigneten Hardware.) - Anfangs hatte ich ein Auge auf den Rasp PI3 geworfen, doch die Frage ist, ob er das von der Leistung her macht(?) - Dann war da noch der Gedanke, einen Arduino für die Steuerung der Buttons/Knöpfe/Displays zu nehmen und die Sounds von einem Rasp-PI3 oder einem Axoloti (axoloti.com) erzeugen zu lassen. - Es stellt sich mir die Frage, kann ich nicht direkt z.B. einen ARM Cortex irgendwo drauflöten (lassen?) und auf z.B. ein EEPROM ein kompilierte Software (?). Falls ja, welche Programmiersprache müsste (könnte) ich nehmen? C ist nicht grade meine Stärke, aber wenn es nicht anders geht, dann nehm ich auch das in Kauf :) Könnte mir jemand ein paar Tips geben, was ich bei der Auswahl der Hardware beachten sollte? Welche Hardware dafür geeignet wäre? Wie man da am besten vorgeht? Beste Grüße
:
Verschoben durch User
@General Error (generalerror) >Geplant ist ein 16-Spuriger/64-Step-Sequencer der WAV-Samples und >Synth-Algorithmen (bzw. eingebaute Synth-Hardware) triggern soll. Das >Teil soll später 47 Buttons, 18 Drehregler sowie 4 kleine TFT-Displays >steuern können. >- Anfangs hatte ich ein Auge auf den Rasp PI3 geworfen, doch die Frage >ist, ob er das von der Leistung her macht(?) Könnte sein, aber man braucht halt einen recht leistungsfähigen Audio-Treiber. Wenn du wirklich 16 Tonspuren haben willst, muss das wohl per CPU gemischt werden, denn die Hardware kann das AFAIK nicht allein. Das sollte eine 1GHz CPU aber hinkriegen >- Dann war da noch der Gedanke, einen Arduino für die Steuerung der >Buttons/Knöpfe/Displays zu nehmen und die Sounds von einem Rasp-PI3 oder >einem Axoloti (axoloti.com) erzeugen zu lassen. AUA! Die paar Tasten wertet die Himbeere mit Links aus, man muss sie nur mittels Schieberegister am SPI einlesen. >- Es stellt sich mir die Frage, kann ich nicht direkt z.B. einen ARM >Cortex irgendwo drauflöten (lassen?) und auf z.B. ein EEPROM ein >kompilierte Software (?). ??? >Könnte mir jemand ein paar Tips geben, was ich bei der Auswahl der >Hardware beachten sollte? Welche Hardware dafür geeignet wäre? Wie man >da am besten vorgeht? Mit Köpfchen.
Hi, danke für die schnelle Antwort :) >>- Es stellt sich mir die Frage, kann ich nicht direkt z.B. einen ARM >>Cortex irgendwo drauflöten (lassen?) und auf z.B. ein EEPROM ein >>kompilierte Software (?). >??? also ich habe bei vielen DIY-Sachen gesehen, dass sich Leute Schaltpläne zeichnen, diese dann z.B. an http://dirtypcbs.com/ senden, und ein Board zurückbekommen auf welches sie dann die CPU, Speicher und was noch benötigst wird drauflöten. Mir stellt sich die Frage ob das nicht der richtige Weg wäre, auch wenn ich von Elektronik (noch) keine Ahnung habe(?) >>- Dann war da noch der Gedanke, einen Arduino für die Steuerung der >>Buttons/Knöpfe/Displays zu nehmen und die Sounds von einem Rasp-PI3 oder >>einem Axoloti (axoloti.com) erzeugen zu lassen. >AUA! Die paar Tasten wertet die Himbeere mit Links aus, man muss sie nur >mittels Schieberegister am SPI einlesen. würde die Leistung des PI3 denn ausreichen um alle Taster, sowie die 4TFT's und dazu noch die den Sequencer sowie die Sound-Engine zu steuern?
General E. schrieb: > also ich habe bei vielen DIY-Sachen gesehen, dass sich Leute Schaltpläne > zeichnen, diese dann z.B. an http://dirtypcbs.com/ senden, und ein Board > zurückbekommen auf welches sie dann die CPU, Speicher und was noch > benötigst wird drauflöten. Mir stellt sich die Frage ob das nicht der > richtige Weg wäre, auch wenn ich von Elektronik (noch) keine Ahnung > habe(?) Das mag für Leute die sich auskennen einfach so gehen, aber für einen Anfänger ist es doch ordentlich viel Arbeit und auch viel Neues. Wenn du das Ergebnis willst: vergiss es. Wenn du was lernen willst und dir das Ergebnis so gut wie egal ist: mach es so. General E. schrieb: > Falls ja, welche Programmiersprache müsste > (könnte) ich nehmen? C ist nicht grade meine Stärke Alternativ könntest du C++ nehmen. Du wirst dich bei nem einfachen ARM auch ordentlich umsehen müssen wie das mit dem realtime-zeug klappt, also einfach ein hingerotztes C Programm wird vermutlich nur schlecht funktionieren. Es läuft darauf raus: - Du willst als Ergebnis ein Gerät: Kauf dir n Pi3 oder ähnliches und schau dass es läuft. Da gibts bestimmt fertige Tools die das tun was du willst. - Du willst als Ergebnis das wissen wie man so ein Gerät bauen kann: Lege das Projekt für ein Jahr zur seite, kauf dir ein STM32 Discovery Board und fang an ein bisschen damit zu spielen und mal Audio zu erzeugen und so.
General E. schrieb: > (Ich habe letztes Jahr eine Android-App (in JAVA) geschrieben welche > genau das macht, doch stieß ich sehr schnell an Grenzen wenn es darum > ging mehrere Samples zeitgleich zu triggern. Daher nun der Versuch mit > der dafür geeigneten Hardware.) > > - Anfangs hatte ich ein Auge auf den Rasp PI3 geworfen, doch die Frage > ist, ob er das von der Leistung her macht(?) Das Problem hast Du doch in jeder Programmiersprache und auf jeder Plattform. Nehmen wir mal an, Java sei schnell genug. Du brauchst einen Timer, der Dir einen zuverlässigen Sample-Takt liefert. Der Kode dafür wird wahrscheinlich nicht portabel zwischen Android-Phone, Raspi und Arduino. Eventuell brauchst Du sogar Hardware zur Takterzeugung, aber das siehst Du erst, wenn Deine Software richtig funktioniert. Wenn Du auf diesen Timer reagierst in einem Callback oder einer Interrupt-Routine (ich habe nicht die geringste Ahnung, wie man einen Hardware-Interrupt in einem Java-Programm behandeln kann), dann kannst Du tatsächlich mehrere Aktionen gleichzeitig auslösen, indem Du mehrere Threads aufweckst, die auf das gleiche Ereignis warten. In Java baut man das mit wait() und notifyall(), soweit ich weiß. Java läuft übrigens auch auf dem Raspi. Hast Du schon mit mehreren Threads in Java gearbeitet und Dir über Synchronisation von Threads Gedanken gemacht? Gruß Georg
@General Error (generalerror) >>>- Es stellt sich mir die Frage, kann ich nicht direkt z.B. einen ARM >>>Cortex irgendwo drauflöten (lassen?) und auf z.B. ein EEPROM ein >>>kompilierte Software (?). >>??? >also ich habe bei vielen DIY-Sachen gesehen, dass sich Leute Schaltpläne >zeichnen, diese dann z.B. an http://dirtypcbs.com/ senden, und ein Board >zurückbekommen auf welches sie dann die CPU, Speicher und was noch >benötigst wird drauflöten. Mir stellt sich die Frage ob das nicht der >richtige Weg wäre, auch wenn ich von Elektronik (noch) keine Ahnung >habe(?) Die Frage ist richtig, die Antwort aber das Gegenteil von dem, was du erwartest. Das Schaltplanzeichnen ist einfach. Die Schwierigkeit liegt im Berechnen und Planen der Funktionalität. Dazu braucht es viel Sachkenntnis. Also nix für Anfänger. >würde die Leistung des PI3 denn ausreichen um alle Taster, sowie die >4TFT's und dazu noch die den Sequencer sowie die Sound-Engine zu >steuern? Locker. Da gähnt der noch. Wobei TFT zu allgmein ist. Welche Displays sollen angesteuert werden? 4x 4k? ;-)
General E. schrieb: > Geplant ist ein 16-Spuriger/64-Step-Sequencer der WAV-Samples und > Synth-Algorithmen (bzw. eingebaute Synth-Hardware) triggern soll. Das > Teil soll später 47 Buttons, 18 Drehregler sowie 4 kleine TFT-Displays > steuern können. General E. schrieb: > - Anfangs hatte ich ein Auge auf den Rasp PI3 geworfen, doch die Frage > ist, ob er das von der Leistung her macht(?) Warum sollte die Leistung nicht reichen? Im Prinzip lief die Grundfunktion doch schon vor 25 Jahren auf nem 8Mhz Atari ST ruckel- und fehlerfrei. https://www.youtube.com/watch?v=uhTrBXhGF4k Wenn dazu allerdings auf deinen 4 TFTs opulente Animationen gezeigt werden sollen, dann bestimmen eher diese den Bedarf an CPU und Grafikleistung. Das kann der geneigte Leser ja nun nicht wissen...
@ musikus (Gast) >Warum sollte die Leistung nicht reichen? Naja, wenn man so manchmal sieht, wie ruckelig selbst einfachste Apps teilweise laufen . . . >Im Prinzip lief die Grundfunktion doch schon vor 25 Jahren auf nem 8Mhz >Atari ST ruckel- und fehlerfrei. >Youtube-Video "Atari ST mit Notator und Cubase" Tja, das kann man sich heute kaum noch vorstellen, wie viel man damals mit so wenig Hardwareleistung erreicht hat!!! Es war ne geile Zeit . . . https://www.youtube.com/watch?v=KyMT8MDaxqo#t=0m59s
Georg B. schrieb: > Du brauchst einen Timer, der Dir einen zuverlässigen Sample-Takt > liefert. Der Kode dafür wird wahrscheinlich nicht portabel zwischen > Android-Phone, Raspi und Arduino. Eventuell brauchst Du sogar Hardware > zur Takterzeugung, aber das siehst Du erst, wenn Deine Software richtig > funktioniert. > > Wenn Du auf diesen Timer reagierst in einem Callback oder einer > Interrupt-Routine (ich habe nicht die geringste Ahnung, wie man einen > Hardware-Interrupt in einem Java-Programm behandeln kann), dann kannst > Du tatsächlich mehrere Aktionen gleichzeitig auslösen, indem Du mehrere > Threads aufweckst, die auf das gleiche Ereignis warten. In Java baut man > das mit wait() und notifyall(), soweit ich weiß. > > Java läuft übrigens auch auf dem Raspi. Hast Du schon mit mehreren > Threads in Java gearbeitet und Dir über Synchronisation von Threads > Gedanken gemacht? Hi Georg, vielen Dank für deine Antwort. Ja, ich hatte in Java schon erste berührungen mit Threads. Mit Sample-Takt meinst zu z.B. die Midi-Clock, richtig?
Falk B. schrieb: > @General Error (generalerror) >>also ich habe bei vielen DIY-Sachen gesehen, dass sich Leute Schaltpläne >>zeichnen, diese dann z.B. an http://dirtypcbs.com/ senden, und ein Board >>zurückbekommen auf welches sie dann die CPU, Speicher und was noch >>benötigst wird drauflöten. Mir stellt sich die Frage ob das nicht der >>richtige Weg wäre, auch wenn ich von Elektronik (noch) keine Ahnung >>habe(?) > > Die Frage ist richtig, die Antwort aber das Gegenteil von dem, was du > erwartest. Das Schaltplanzeichnen ist einfach. Die Schwierigkeit liegt > im Berechnen und Planen der Funktionalität. Dazu braucht es viel > Sachkenntnis. > Also nix für Anfänger. Hi, könnte man sowas nicht outsourcen? :) .. wenn ich einen Anforderungs-Katalog erstelle, dass mir jemand die Anforderungen kalkuliert und einen Schaltplan dazu erstell? Falls ja, in welchen Preis-Rahmen würde man sich da bewegen? >>würde die Leistung des PI3 denn ausreichen um alle Taster, sowie die >>4TFT's und dazu noch die den Sequencer sowie die Sound-Engine zu >>steuern? > > Locker. Da gähnt der noch. Wobei TFT zu allgmein ist. Welche Displays > sollen angesteuert werden? 4x 4k? ;-) Ich hatte an 4x 3,5"-Farb-TFT's gedacht.. kein touch.. aber eben mit einer hohen auflösung. Das Sequencer-GUI sollte schon am ende was hermachen, sprich hüllkurven-Visualisierung, Equalizer, LFO-Visualisierung, etc.
Hi, musikus schrieb: > Warum sollte die Leistung nicht reichen? > Im Prinzip lief die Grundfunktion doch schon vor 25 Jahren auf nem 8Mhz > Atari ST ruckel- und fehlerfrei. > https://www.youtube.com/watch?v=uhTrBXhGF4k > Wenn dazu allerdings auf deinen 4 TFTs opulente Animationen gezeigt > werden sollen, dann bestimmen eher diese den Bedarf an CPU und > Grafikleistung. Das kann der geneigte Leser ja nun nicht wissen... ja, das wäre aber ein reiner midi-sequencer. Hierbei habe ich keine Bedenken, dass sowas problemlos machbar ist. Meine Bendenken bez. der Leistungsfähigkeit sind darin begründet, da ich gerne den sequencer und die sound-engine (sprich expander mit all seinen Funktionen (sample-start/-end; start-postition, pitch, etc.), die ganzen Effenkte(laaaange delays, reverbs, etc.) und anderen kram wie Hüllkurven, LFO's .. alles mit der dazugehörigen visualisierung auf den displays, von einem Prozessor steuern würde.
@General Error (generalerror) >> Also nix für Anfänger. >könnte man sowas nicht outsourcen? :) .. Bastler sourcen out? Hmmm. >wenn ich einen >Anforderungs-Katalog erstelle, dass mir jemand die Anforderungen >kalkuliert und einen Schaltplan dazu erstell? > Falls ja, in welchen >Preis-Rahmen würde man sich da bewegen? Zuviel für dich. Da kommen mal fix 20-30h zusammen, und da ist noch nicht allzu viel passiert. Tendentiell geht da mal fix in Richtung 100h. Einen Profi kannst du nicht bezahlen, da geht das Leben ab 60 Eur/h los. Bleibt bestenfalls ein freundlicher Hobbybastler mit Know How und Interesse am Projekt. Stell deine Anforderungen zusammen und schreib eine Anfrage im Forum Markt. Mal sehen was passiert ;-) >Ich hatte an 4x 3,5"-Farb-TFT's gedacht.. kein touch.. aber eben mit >einer hohen auflösung. Wie hoch denn? Viel mehr als 640x480 ist da doch kaum sinnvoll, auch wenn es heute Smartphones mit nahezu HD-Auflösung gibt. > Das Sequencer-GUI sollte schon am ende was >hermachen, sprich hüllkurven-Visualisierung, Equalizer, >LFO-Visualisierung, etc. Wozu dann 4 TFTs? Ist es nicht viel besser EINEN zu nehmen. Den kann man nämlich direkt an die Himbeere mit HDMI anschließen, einfacher geht's kaum ;-)
@ General Error (generalerror) >Leistungsfähigkeit sind darin begründet, da ich gerne den sequencer und >die sound-engine (sprich expander mit all seinen Funktionen >(sample-start/-end; start-postition, pitch, etc.), die ganzen >Effenkte(laaaange delays, reverbs, etc.) und anderen kram wie >Hüllkurven, LFO's .. alles mit der dazugehörigen visualisierung auf den >displays, von einem Prozessor steuern würde. kann man machen, kriegt man auch mit der Himbeere an sich hin, aber ob DU das mit deinem Wissensstand schaffst, ist eine andere Frage. Mit Java wirst du nicht weit kommen, denn das ist na lahme Ente. Da braucht man gescheites C oder C++ und ne gute Portion Know How von Treiberprogrammierung. Je weniger Know How man selber hat, umso mehr muss man auf fertige Module in Form von Soft- und Hardware zurückgreifen und kann diese nur mehr oder weniger geschickt konfigurieren und kombinieren.
Falk B. schrieb: > Naja, wenn man so manchmal sieht, wie ruckelig selbst einfachste Apps > teilweise laufen . . . Du wirst immer eine Programmierer-Programmiersprachen-Framework-OS Kombination finden, die es schafft, fast beliebige Rechenleistung mit elementaren Anwendungen auf irgendwelchen belanglosen Nebenschauplätzen zu verbraten.
Falk B. schrieb: > Bastler sourcen out? Hmmm. > Zuviel für dich. Da kommen mal fix 20-30h zusammen, und da ist noch > nicht allzu viel passiert. Tendentiell geht da mal fix in Richtung 100h. > Einen Profi kannst du nicht bezahlen, da geht das Leben ab 60 Eur/h los. > Bleibt bestenfalls ein freundlicher Hobbybastler mit Know How und > Interesse am Projekt. Stell deine Anforderungen zusammen und schreib > eine Anfrage im Forum Markt. Mal sehen was passiert ;-) ja, bastler hin oder her, ich möchte am ende schon etwas solides haben. ich wäre durchaus bereit zu investieren, wenn ich auch nicht grade finanziell stark aufgestellt bin. Eine weitere Idee wäre es den sequencer als reinen Midi-Sequencer zu coden der zuwätlich halt noch die Displays steuert.. und das Processing des Sounds von integrierter Hardware erledigen zu lassen. Schaue mich grade um was es da so gibt. Wäre das eine Option für mein Vorhaben? Oder würdet ihr da eher abraten? >>Ich hatte an 4x 3,5"-Farb-TFT's gedacht.. kein touch.. aber eben mit >>einer hohen auflösung. > > Wie hoch denn? Viel mehr als 640x480 ist da doch kaum sinnvoll, auch > wenn es heute Smartphones mit nahezu HD-Auflösung gibt. 640x480 sollte ausreichen :) > Wozu dann 4 TFTs? Ist es nicht viel besser EINEN zu nehmen. Den kann man > nämlich direkt an die Himbeere mit HDMI anschließen, einfacher geht's > kaum ;-) die 4x TFT's sind nötig um die Anforderungen zu erfüllen. Je nachdem in welchen Modi des Sequencers man sich befindet, sollen verschiedene Parameter-Gruppen auf verschiedenen Displays ausgespielt werden. Hatte anfangs auch nur mit einem - größeren - Display geplant, mich letztendlich aber doch für 4x Displays entschieden, da so das Handling einfacher und übersichtlicher wird.
Falk B. schrieb: >>Leistungsfähigkeit sind darin begründet, da ich gerne den sequencer und >>die sound-engine (sprich expander mit all seinen Funktionen >>(sample-start/-end; start-postition, pitch, etc.), die ganzen >>Effenkte(laaaange delays, reverbs, etc.) und anderen kram wie >>Hüllkurven, LFO's .. alles mit der dazugehörigen visualisierung auf den >>displays, von einem Prozessor steuern würde. > > kann man machen, kriegt man auch mit der Himbeere an sich hin, aber ob > DU das mit deinem Wissensstand schaffst, ist eine andere Frage. Mit Java > wirst du nicht weit kommen, denn das ist na lahme Ente. Da braucht man > gescheites C oder C++ und ne gute Portion Know How von > Treiberprogrammierung. > > Je weniger Know How man selber hat, umso mehr muss man auf fertige > Module in Form von Soft- und Hardware zurückgreifen und kann diese nur > mehr oder weniger geschickt konfigurieren und kombinieren. Hatte zuletzt bei der Android-App ebenfalls auf C++ zurückgriefen müssen, auch wenn es schwer war, weil Java es nicht verkraftet hat. Es gibt Leute die mir erzählt haben, das sei auch rein mit Java möglich.. hat bei mir nicht geklappt :/ warum Treiberprogrammierung? Könntest du mir das kurz erläutern, stehe da ein bisschen auf m Schlauch(?)
@ General Error (generalerror) >ja, bastler hin oder her, ich möchte am ende schon etwas solides haben. >ich wäre durchaus bereit zu investieren, wenn ich auch nicht grade >finanziell stark aufgestellt bin. Naja, versuch erstmal einen Testaufbau zusammenzuschustern. >Eine weitere Idee wäre es den sequencer als reinen Midi-Sequencer zu >coden der zuwätlich halt noch die Displays steuert.. und das Processing >des Sounds von integrierter Hardware erledigen zu lassen. Schaue mich >grade um was es da so gibt. Wäre das eine Option für mein Vorhaben? Ja. >640x480 sollte ausreichen :) OK, aber die Frage ist, wieviel und vor allem wie schnell dort was dargestellt werden soll. Das bestimmt den Verbindungsaufwand. Es gibt diverse TFTs in dem Format, die man relativ einfach per SPI/UART/I2C ansteuern kann, aber die sind nicht sonderlich schnell und auch eher nicht für Animationen geeignet. http://www.lcd-module.de/produkte/ediptft.html >die 4x TFT's sind nötig um die Anforderungen zu erfüllen. Du meinst deine Spielereien ;-) > Je nachdem in >welchen Modi des Sequencers man sich befindet, sollen verschiedene >Parameter-Gruppen auf verschiedenen Displays ausgespielt werden. Hatte >anfangs auch nur mit einem - größeren - Display geplant, mich >letztendlich aber doch für 4x Displays entschieden, da so das Handling >einfacher und übersichtlicher wird. Auch ein großes LCD kann man in 4 kleine Teile aufteilen, nicht erst seit es Windows gibt ;-) Machbar ist fast alles, die Frage ist immer nur mit welchem materiellen, finanziellen und technischem Aufwand.
@ General Error (generalerror) >> Je weniger Know How man selber hat, umso mehr muss man auf fertige >> Module in Form von Soft- und Hardware zurückgreifen und kann diese nur >> mehr oder weniger geschickt konfigurieren und kombinieren. >warum Treiberprogrammierung? Könntest du mir das kurz erläutern, stehe >da ein bisschen auf m Schlauch(?) Je nachdem, welche Art von Software es schon gibt bzw. auf welche man zurück greifen kann, muss man mehr oder auch weniger nah an die Hardwareprogrammierung ran. Je tiefer man rein muss, umso aufwändiger wird es.
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.