Jump to content

Black Knight

Profi
  • Content Count

    552
  • Joined

  • Last visited

About Black Knight

  • Rank
    Gold Mitglied

Previous Fields

  • Ligalogo
    Liga-Rhein-Wupper

Contact Methods

  • Website URL
    http://

Profile Information

  • Gender
    Not Telling
  • Location
    Solingen

Recent Profile Visitors

324 profile views
  1. Habe gerade SW Version 0.12 released. Soweit ich weiß gibt es damit keine offenen Punkte mehr, was MPF betrifft. Weitere Infos gibt's im Changelog.
  2. Freut mich zu hören. Da mit MPF mittlerweile alles funktioniert, ist Lisy - PinMame meines Wissens nach auch unsere letzte große Baustelle.
  3. So, jetzt scheint alles zu laufen. Ich habe für den Sound noch ein paar Änderungen in der SW gemacht, damit alles kompatibel zu den MPF Kommandos ist. Hoffentlich komme ich dazu, das dieses WE zu releasen. @bontango Da hat sich jemand im Pinside Forum gemeldet, der Lisy gerne mit dem 'MPF command interface' benutzen würde. Ich bin mir nicht ganz sicher was er meint, vielleicht möchtest du da ja was zu sagen.
  4. Da schließe ich mich an. Alles Gute Frank
  5. @jabdoa Ich habe die Soundänderung eingebaut, kann das aber bisher nur mit dem Terminalprogramm testen. Was muss ich denn in meiner MPF-Config machen, um ein Soundfile abzuspielen? Ähnliche Frage zu den Displays. Snux hat zwar gezeigt, dass es mit MPF geht aber ich würde das auch gerne mal selbst probieren.
  6. OK, dann baue ich das noch ein. Was wir mit dem Sound-Ende-Event machen können wir ja noch entscheiden. Für PinMame ist das sowieso uninteressant, aber für MPF Nutzer wäre das vermutlich wichtig.
  7. Ich sehe in der Doku jetzt immer noch ein Optionsbyte mit einem Loop- und einem NoCache-Bit. Dieses Byte gibt es bei mir bisher noch nicht. Wir sollten uns kurz abstimmen, ob ihr das braucht oder ob das weg kann. Das Cache-Bit muss ich sowieso ignorieren, das der Arduino zu wenig Speicher für einen Sound-Cache hat. Die Loop-Funktion könnten wir mit einem Sound-Ende Event realisieren, was mehr Flexibilität böte, aber eventuell Probleme mit den Latenzen machen könnte, falls man wirklich einen Loop aus Soundfragmenten haben will. Meine Präferenz wäre also, dieses Byte weg zu lassen und stattdessen das Sound-Ende-Event einzuführen. Wie sieht's bei euch aus? @bontango @jabdoa Hättet ihr gerne ein Loop- bzw. NoCache-Bit? Dann baue ich das Byte noch ein und würde das Loop-Bit verwenden.
  8. Genau, das war die Idee. Ich habe das bei mir so gemacht und nutze das häufig - z.B. um nacheinander mehrere Musikstücke abspielen zu können. Je nachdem was die Leute machen könnte das natürlich passieren. Aber da würde ich deinen Ansatz verfolgen und erst mal abwarten, ob sich wirklich jemand beschwert. OK, probiere ich aus - falls meine MPF Kenntnisse dazu reichen. Vermutlich muss ich doch mal einen Noob-Thread im MPF Forum aufmachen; ich tu mich da teilweise schon etwas schwer.
  9. Ich als MPF-Noob stelle mir halt ein Sound-Ende-Event vor, das der User dann zum Starten eines Modes, eines neuen Sound oder was auch immer verwenden kann.
  10. Irgendwas werden wir wohl brauchen und das wäre eine sehr flexible Variante, mit der wir diese Loop-Geschichte gleich mit erschlagen könnten. Damit würde man es dem User überlassen, ob er einen Loop oder was anderes haben will. Ich habe sowas bei mir intern nämlich auch schon und könnte das einfach verwenden. Ich baue euch aber auch ein Loop-Bit ein, wenn ihr das gerne hättet.
  11. Verstehe. Eine Frage hätte ich aber noch zur 0.09er API. Du hattest ursprünglich mal ein Loop Bit für den Befehl 'Play Sound File' spezifiziert. Wir hatten das dann irgendwann gestrichen, aber ein Hinweis wenn die Musikdatei zu Ende ist wäre vermutlich ganz nützlich. Ich hatte daher vorgeschlagen, einfach ein Switch Event dafür einzubauen, d.h. die HW meldet einfach Schalter 126 betätigt, wenn die Datei für Tonspur 1 zu Ende geht und Schalter 126 losgelassen für Tonspur 2. PinMame könnte diese Funktion nutzen, um einen Musikloop zu realisieren und MPF könnte ein Event draus machen, das der User dann abfragen kann. Jan hat sich bis jetzt noch nicht wirklich dazu geäußert, aber ich denke wir werden irgendwas in der Art brauchen.
  12. Das ist total simpel; die DMDs haben einfach nur zwei Schieberegister drauf, eins für die Zeilen und eins für die Spalten. Ein Schuss mit dem Logicanalyzer und man sieht, was Sache ist. Ich habe dieses Testbild jetzt einfach mal mit einem Arduino UNO implementiert, aber der ist wirklich nur für ein Testbild zu gebrauchen und nicht schnell genug, um simultan die Daten von der CPU anzunehmen. Da werde ich wohl einen Teensy oder sowas nehmen müssen. Ich werde wohl auch eine Standalone-Version bauen, die man dann direkt über USB steuert, damit spart man sich den Umweg über den APC, wenn man MPF oder Lisy_Mini verwendet. Tja, jetzt musst du wohl die ganzen Änderungen nachziehen, die wir in die Lisy API eingebaut haben. 👍
  13. Hallo Jungs, es ist so ruhig bei euch, seid ihr alle im Sommerloch? @bontango Gibt's irgendwas neues vom Comet? @jabdoa Kann ich den Sound ausprobieren? Sollen wir noch ein 'Sound Ende' Signal einführen oder lassen wir es so? @Volley Was macht dein SMD-Fieber, kommst du klar oder brauchst du Hilfe? @Snux Deine 2 Wochen sind ja noch nicht ganz rum, daher lasse ich dich noch in Ruhe 😁 Wenn nichts passiert komme ich noch auf dumme Ideen und baue tatsächlich einen WPC-APC. Das mit den DMDs habe ich nämlich inzwischen raus und den Rest kann ich weitgehend vom APC übernehmen.
  14. Ja, das war mal in der API drin, wobei ich persönlich einen Loop zu unflexibel finde. Andererseits braucht man irgendein Signal wenn die Musik am Ende ist, daher die Idee mit dem Phantomschalter. Der würde dann ganz normal mit 'Get Changed Switches' (0x29) abgefragt. Dann würde also z.B. Schalter 125 gemeldet, wenn das Soundfile für Kanal 1 am Ende ist und Schalter 126 für Kanal 2. Das wäre eine Lösung, die meiner Meinung nach leicht zu implementieren und trotzdem sehr flexibel wäre.
×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines