(10.09.2020, 19:04)bornemju schrieb: [ -> ]könnte das weiterhelfen:
https://github.com/StuffAndyMakes/arduino-bezier
Ja Jürgen, kenne ich schon, trotzdem danke.
Du müsstest doch eigentlich zu dem Goniometer-Testcode und dem Gogosch-Code etwas sagen können, was man auch als Nichtfachmann verstehen kann?
Das Hauptproblem ist momentan nicht das (schnelle!!!) Zeichnen der Kurven (das Beste kommt zum Schluss), sondern die von der Audiolib bereitgestellten Audiosamples.
Die Gewinnung Dieser ist leider im Vergleich zum PC und den Desktop-Testmodulen unterirdisch schlecht.
Vor allem feuert das Ding pausenlos irgendwelche Querschläger in die Queue, wo eigentlich Ruhe sein sollte
Die Gogosch Implementierung (wo auch immer die so schnell herkam) schaue ich mir Morgen mal an, danke dafür.
So ein bisschen Erklärung dazu für alle Leser wäre sicher schön gewesen, aber was nicht ist, das ist halt nicht.
Falls ich überhaupt das Codefragment zum laufen bekomme, hoffe ich sehr, dass sich dann die Kurven (momentan sind es Punkte), so verhalten wie in der Desktopversion.
Kann ich mir aber nicht vorstellen, dafür sind die Audiosamples am Teensy einfach zu schlecht und ich weiß nicht warum.
Gogosch
Noch ein paar Anmerkungen zu Deinem Code, der Queue und den Samples:
Code:
double x = queueBufferleft[i]; // Left channel is mapped to x axis
double y = queueBufferRight[i]; // Right channel is mapped to y axis
Das verwirrt mich nun erst mal richtig
Was genau erwartet denn der Code aus den Puffern?
Schon aufbereitete DOUBLE, oder doch BYTES oder eher SHORTS?
Nehmen wir mal einen Block der Queue, der hat 128 Bytes.
Sauge ich mir die 128 Bytes ab, kommen auch 128 Bytes in den Puffer, ok,
Daraus gewinnen wir durch das Shiften Samples in SHORT, also genau die Hälfte, da ein SHORT aus zwei Bytes besteht.
So mache ich das, wie Du ja im mini Testcode sehen kannst.
Nur das ich 2Kb aus der Queue sauge. Das kostet eklig viel Zeit, da er ja wartet, bis 16 Blöcke a 128 Bytes neu in der Queue angekommen sind.
Nachdem Du mir ja den Tipp gabst, den Puffer in Bytes zu benutzen und daraus dann die Shorts zu generieren, hielt ich mich daran und es geht ja auch.
Interessanter Weise steht in der Beschreibung der Record-Queue (von Bytes keine Rede):
"Read a single audio packet. A pointer to a 128 sample
array of 16 bit integers is returned. NULL is returned if no packets are available."
Aha, toll!
Macht man nun ein Array als 16 Bit Integer, also SHORT, und füllt es mit dem oben erwähnten "single audio packet", kommen aber nur 64 Shorts in den Puffer.
Kann ich auch verstehen, aber warum zum Geier steht dort explizit:
A pointer to a 128 sample array of 16 bit integers is returned.
Was soll das? Fehler? Wahrscheinlich bin ich nur zu blöd.
Und nun kommst Du zur Krönung mit DOUBLE daher
.
Also was genau soll denn da nun rein?
Oder denke ich falsch?
Kann man bei C++ seine Datentypen wechseln wie Unterhosen?
Ich dachte, nur PHP vergleicht Äpfel mit Birnen
Vielleicht nur eine Namensgleichheit der Puffer bei Deinem Code und meinem?
Vielleicht stopfst Du da auch etwas rein, was nicht dokumentiert ist - ich weiß es einfach nicht.
Gute N8
PS: Das schönste an dieser Woche ist mein neues Auto, das macht alles ohne das ich raten muss
Hiermit gebe ich allen Lesern ein Auto-Eis aus! Lasst es euch schmecken und kleckert nicht