Bitte geben Sie einen Grund für die Verwarnung an
Der Grund erscheint unter dem Beitrag.Bei einer weiteren Verwarnung wird das Mitglied automatisch gesperrt.
Arduino - Programmierung
Zitat von Montre im Beitrag #89
Du sagtest, mit Hall-Sensoren geht keine Matrix.
Müsste auch anders gehen, und zwar mit Transistoren.
Der Hall Sensor schickt doch ein HIGH (irgendwas zwischen 3,5 und 5V) an den Output Pin, wenn der Magnet in die Nähe kommt und ein LOW, wenn der Magnet wieder weg ist.
Jetzt baust du dir deine Matrix, die "Schalter" sind NPN-Transistoren. Die Hallsensoren gehen mit ausreichend dimensionierten Widerstand auf das mittlere Beinchen (hier brauchst du nur noch ca. 0,8V von den 5V), damit schaltet der Transistor durch und lässt Spannung vom Kollektor zum Emitter. So als wenn ein mechanischer Schalter betätigt worden wäre.
Die Schaltgeschwindigkeit von z.B. dem BC337 Transistor liegt bei 35 MHz, da ist also auch keine Latenz spürbar.
Zur meiner Performance-Frage Arduino 2560 mit 16 MHz hatte ich mir notiert:
Sabine hat die Zeit gemessen und kommt für das Scannen von 30 Pedaltasten auf 75µs (0,075 ms).
Damit könnte man die 30 Tasten 13333 mal pro Sekunde scannen.
Pro Taste = 2,5µs
61 Tasten = 152,5µs
32 Tasten = 80µs
Beispielrechnung:
5 Manuale = 305 Tasten = 762,5µs
160 Register/Pistons = 400µs
5M + P + Reg. = 1.242,5µs = 1,2425 ms
#93
Ich würde Reed Schalter bevorzugen. Hall Sensoren sind zwar eine nette Sache, aber bei einem Manual mit fiktiv deinem Projekt 200 mal ist einfach etwas groß als Projekt.
Ich sehe da einige Probleme. Hall Sensoren reagieren auf ein Magnetfeld. Wie willst du sicherstellen, dass die benachbarten Sensoren nicht auf das selbe Magnetfeld reagieren? In einem Pedal sind die Abstände recht groß, in einem Manual eher nicht. Du müsstest also eine Regelelektronik pro Sensor mit bauen um das justieren zu können. Fertige Module gibt es auch, aber die kosten aktuell um die 3-8 Euro. Bei fiktiv 200 Tasten könntest du dir eine fertige Lösung vom Orgelbauer bauen lassen, nur für die Kosten der Sensoren.
Reed-Schalter hat Sabine nicht genommen, wegen befürchteter Vibrationen.
In einem Selbstbau-Projekt hat jemand Hall-Sensoren verwendet, die mit einem Heißkleber auf einer Lochrasterschiene befestigt wurden. Da gab es keine Probleme. Die Magneten sollten halt so dimensioniert sein, dass sie die Nachbartaste nicht "mitnehmen".
Das Problem, von dem Christian berichtet, habe ich eher von Reed Sensoren gehört, wenn man die fürs Manual verwendet. Eben aus dem Grund, dass die Abstände geringer sind, als beim Pedal, und dann benachbarte Tasten mitreagieren.
Für Manual taugen Hall Sensoren offenbar, Pascal Leray hat alle seine Manuale so midifiziert.
https://www.youtube.com/watch?v=vhInfcWWsQE&t
(ab 5:10 sieht man mal das Innere der Orgel)
#96
Es gibt für alles ein Für und Wieder.
Bei meinem Pedal habe ich auch Reeds genommen. Nie Probleme gehabt. Ich musste nicht einmal entprellen. Ich habe einen anderen Ansatz gewählt. Im Normalzustand, also wenn ein Pedal nicht gedrückt wird befindet sich der Magnet in der Nähe vom Schalter. Das lässt sich gut einstellen, so dass der Schalter erst in der Endstellung geschlossen wird. Drücke ich das Pedal, dann öffnet sich der Kontakt und somit kann nichts prellen. Beim loslassen prellt dann auch nicht viel.
Zitat von Brassmann im Beitrag #95
Offener Spieltisch Pascal Leray
(ab 5:10 sieht man mal das Innere der Orgel)
Das ist interessant, weil die Sensoren nicht hinter der Taste positioniert sind, sondern leicht seitlich. Vielleicht wird dadurch der Nebeneffekt vermieden.
#98
#99
Ich habe mich jetzt noch einmal daran gesetzt ein Programm für den Pi Pico zu schreiben, welches keine zusätzlichen Bibliotheken benötigt. Meine ältere Lösung welche auch hier im Thread steht nutzte ja Adafruit. Diese Lösung hier ist sehr rudimentär. Ich dachte mir, ich werfe sie einfach mal hier mit rein. Vielleicht nutzt sie bei deinem Vorhaben:
Hier die simple Version
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
import machine
import time
# Define the pins for the rows and columns of the keypad
row_pins = [2, 3, 4, 5, 6, 7, 8]
column_pins = [9, 10, 11, 12, 13, 14, 15]
# Define the MIDI codes for each key
key_codes = [
0x90, 60, 100, # C4
0x90, 62, 100, # D4
0x90, 64, 100, # E4
0x90, 65, 100, # F4
0x90, 67, 100, # G4
0x90, 69, 100, # A4
0x90, 71, 100, # B4
0x90, 72, 100, # C5
]
# Initialize the keypad
keypad = machine.keypad(row_pins, column_pins)
# Main loop
while True:
# Read the state of the keypad
state = keypad.read()
# Check if any key is pressed
for row in range(8):
for column in range(8):
if state[row][column]:
# Send the MIDI code for the pressed key
machine.midi.send_note_on(key_codes[row * 8 + column], 127)
# Wait for a short time
time.sleep(0.1)
Und hier noch einmal zusätzlich mit dem entprellen der Tasten:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import machine
import time
# Define the pins for the rows and columns of the keypad
row_pins = [2, 3, 4, 5, 6, 7, 8]
column_pins = [9, 10, 11, 12, 13, 14, 15]
# Define the MIDI codes for each key
key_codes = [
0x90, 60, 100, # C4
0x90, 62, 100, # D4
0x90, 64, 100, # E4
0x90, 65, 100, # F4
0x90, 67, 100, # G4
0x90, 69, 100, # A4
0x90, 71, 100, # B4
0x90, 72, 100, # C5
]
# Initialize the keypad
keypad = machine.keypad(row_pins, column_pins)
# Main loop
while True:
# Read the state of the keypad
state = keypad.read()
# Check if any key is pressed
for row in range(8):
for column in range(8):
if state[row][column]:
# Send the MIDI code for the pressed key
machine.midi.send_note_on(key_codes[row * 8 + column], 127)
# Wait for a short time
time.sleep(0.01)
# Check if the key is still pressed
state_new = keypad.read()
if state_new[row][column]:
# The key is still pressed
continue
# The key is no longer pressed
machine.midi.send_note_off(key_codes[row * 8 + column], 127)
Und die letzte Version ist für alle, die kein HEX nutzen wollen bei den Tastencodes :)
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import machine
import time
# Define the pins for the rows and columns of the keypad
row_pins = [2, 3, 4, 5, 6, 7, 8]
column_pins = [9, 10, 11, 12, 13, 14, 15]
# Define the MIDI codes for each key
key_codes = {
0: 60, # C4
1: 62, # D4
2: 64, # E4
3: 65, # F4
4: 67, # G4
5: 69, # A4
6: 71, # B4
7: 72, # C5
}
# Initialize the keypad
keypad = machine.keypad(row_pins, column_pins)
# Main loop
while True:
# Read the state of the keypad
state = keypad.read()
# Check if any key is pressed
for row in range(8):
for column in range(8):
if state[row][column]:
# Send the MIDI code for the pressed key
machine.midi.send_note_on(key_codes[row * 8 + column], 127)
# Wait for a short time
time.sleep(0.01)
# Check if the key is still pressed
state_new = keypad.read()
if state_new[row][column]:
# The key is still pressed
continue
# The key is no longer pressed
machine.midi.send_note_off(key_codes[row * 8 + column], 127)
Stehen die Libs auch für C zur Verfügung? Mir widerstrebt es, auf so Kleinstgeräten die Rechenzeit fürs interpretieren des Codes zu verplempern.
Aber mit C/C++ gehts auch:
Zitat
Standard-C/C++-Bibliotheken werden zusammen mit APIs für den Zugriff auf die Hardware des RP2040 unterstützt, einschließlich DMA, IRQs und der Vielzahl von Peripheriegeräten mit fester Funktion und PIO (Programmable IO).
Darüber hinaus bietet das SDK übergeordnete Bibliotheken für den Umgang mit Timern, USB, Synchronisation und Multi-Core-Programmierung sowie zusätzliche High-Level-Funktionen, die mit PIO erstellt wurden, wie z. B. Audio. Das SDK kann verwendet werden, um alles zu erstellen, von einfachen Anwendungen oder vollwertigen Laufzeitumgebungen wie MicroPython bis hin zu Low-Level-Software wie dem On-Chip-Bootrom des RP2040 selbst.
Das der Pico zwei Kerne hat, ist ja schon cool.
#101
Zitat von Montre im Beitrag #100
Mir widerstrebt es, auf so Kleinstgeräten die Rechenzeit fürs interpretieren des Codes zu verplempern.
So pauschal kann man das nicht sagen. Es kommt auf den Anwendungsfall an. Einige Dinge sind mit c++ nahezu doppelt so schnell, andere Dinge sind mit Python nahe doppelt so schnell. Für unsere Zwecke wo keine komplexen Berechnungen und andere Dinge laufen wird der Unterschied kaum ins Gewicht fallen.
Python lässt sich eben sehr viel besser Debuggen.
#103
Zitat von Montre im Beitrag #102
Python ist in C/C++ implementiert und kann nicht schneller sein. Max. gleich schnell :-)
Nicht unbedingt. Wenn du Berechnungen oder Bibliotheken nutzt, dann kann es durchaus sein, dass der eine Weg mit dem langsameren Interpreten schneller zu Ziel führt als der andere Weg mit dem schnelleren Code :)
Wenn es nur auf Geschwindigkeit in einem Benchmark ankommt, dann hätte sich Python nicht zu einer der wichtigsten Sprachen in der Forschung, Astronomie und Mathematik entwickelt oder? Ein Compiler bügelt viel unsinnigen Code wieder gerade, ein Interpret hingegen arbeitet jede Zeile genau so ab, wie geschrieben.
Ein simples Beispiel:
2
3
4
wert = 0
for( i = 1; i <= 100; i++)
wert++
print(wert)
Python arbeitet hier brav die unsinnige Schleife ab. Ein Compiler würde hier optimieren und die Schleife entfernen und die Variable auch. Es würde nur noch ein print("99") übrig bleiben, da es keine anderen Ergebnisse geben kann...
Zitat von Christian_Hofmann im Beitrag #103
Nicht unbedingt. Wenn du Berechnungen oder Bibliotheken nutzt, dann kann es durchaus sein, dass der eine Weg mit dem langsameren Interpreten schneller zu Ziel führt als der andere Weg mit dem schnelleren Code :)
So argumentiert nur jemand, der seinen "Favoriten" verteidigen will ;-)
Das kann mich nach mehreren Jahrzehnten Programmier-Erfahrung in unterschiedlichen Unternehmen nicht beeindrucken. Ich hatte mehrere Jahre einen Python-Profi als Kollegen. Daher kann ich das ganz gut einschätzen und kenne die gängigen Argumentationen. Wenn Python ein Modul nutzt, in dem Assembler-Code verwendet wird, dann ist Python an sich dadurch nicht schneller als C, sondern der Assembler-Part in diesem Modul ist schneller, als der vom C-Compiler generierte Assembler-Code :-)
#105
Zitat von Montre im Beitrag #104
So argumentiert nur jemand, der seinen "Favoriten" verteidigen will ;-)
Ich habe keinen Favoriten, da ich beides nutze abhängig vom zu lösenden Problem. Mache dir einfach selbst ein Bild. Löse eine Aufgabe mit beiden Varianten, mache Fehler und suche diese, so dass dein Projekt läuft. Dann wirst du selbst schnell merken welche Lösung für dich in welchem Fall besser ist.
Meine Tendenz für Python in diesem Kontext ist eigentlich ganz klar: Fehleranalyse ist damit sehr viel leichter. Aber mache ruhig deine eigenen Erfahrungen :) Zum Debuggen eines laufenden Arduino Programms brauchst du zusätzliche Hardware, da kannst du nicht einfach mal den Ablauf unterbrechen oder Variablen prüfen.
- Hauptwerk
- Hauptwerk-Konfiguration, Diskussion
- Hauptwerk-Samplesets
- GrandOrgue
- GrandOrgue-Konfiguration, Diskussion
- GrandOrgue-Samplesets
- Sweelinq
- Sweelinq-Konfiguration, Diskussion
- Sweelinq-Samplesets
- Sonstige Orgelsoftware
- Organteq
- Sonstige Sampler
- Hardware
- Spieltische und Selbstbau
- Zubehör (PCs, Monitore, Interfaces etc.)
- Klangabstrahlung
- Musikalisches
- Noten, Einspielungen, Konzerte
- Sonstige Musikthemen
Jetzt anmelden!
Jetzt registrieren!
