Jump to content

VFD Türkis 2x40 / Netzteilfragen SID


seppoman
 Share

Recommended Posts

Hi Thorsten,

hab gerade den Test gemacht:

Die Zahl pendelt ca. zwischen 11700 und 12000. Wenn ich mal mit 11900 rechne, komme ich auf 9,52 ms. Ist natürlich nicht der Knüller, aber auf jeden Fall noch lang nicht so schlimm wie das t69... in horizontal mode...

Würdest Du sagen, das ist für die SID-Applikation akzeptabel? Bedeutet dieser Wert, daß ein Note/CC/Encoder-Event wegen dem Display im schlimmsten Fall gut 10 ms Verspätung hat? Wenn das der Fall wäre, könnte ich damit denke ich leben - bei VST-Intrumenten ist man ja begeistert, wenn man 5-6 ms erreichen kann, und im Vergleich zu Roland-Modulen von Anfang der 90er ist das noch super. Ich hatte mal einen U-110, der, wenn er mal über 10 Samples gleichzeitig starten sollte, sicher 200 ms getrödelt hat :) Das war allerdings auch der Hauptgrund, warum ich ihn wieder verkauft habe...

Oder kann man die Zahl nicht in reales Timing "übersetzen"?

Viele Grüße,

Seppoman

Link to comment
Share on other sites

Hallo,

die Zahl 12000 bedeutet dass Dein Display ca. 4 mal langsamer als ein HD44780 kompatibles Display ist. Und daraus laesst sich wiederum schliessen, dass mit einem VFD der Display Update 3.2 mS statt 800 uS dauert (bei 2x20 Zeichen), und 6.4 mS bei 2x40 Zeichen

Diese Zeit halbiert sich, sobald der getrennte Update Request fuer die obere und untere Zeile eingebaut ist.

Damit kannst Du dann wahrscheinlich leben... ;-)

Gruss,

       Thorsten (der in seinen U110 eine XG Wavetable Karte eingebaut hat ;-)

Link to comment
Share on other sites

Hi Thorsten,

Diese Zeit halbiert sich, sobald der getrennte Update Request fuer die obere und untere Zeile eingebaut ist.

Damit kannst Du dann wahrscheinlich leben... ;-)

Das hört sich gut an :)

Wobei natürlich beim Drehen eines zu einem anderen Menü gehörigen Encoders trotzdem das ganze Display geschrieben werden muß. Mir kam dazu noch eine Idee: Was hältst Du davon, wenn man die gesamte Display-Ausgabe bei Encoder-Bewegungen an den Edit-Mode koppeln würde? Daß also bei ausgeschaltetem Edit-Mode einfach egal was man drückt oder dreht die aktuelle Menüseite, also wohl oft die Hauptseite, stehen bleibt (abgesehen natürlich von den Menü-Tasten). Ich meine, wenn man während des Spielens an einem Encoder dreht, dann ist es einem doch normalerweise komplett schnurz, ob jetzt z.B. der Filter auf 21 oder 28 steht, man dreht eben, bis das akustische Ergebnis stimmt, und würde auch von den Menüwechseln am Display nicht beim Hören abgelenkt. Ich vermute allerdings, daß ich dafür wohl quer durchs CS alle möglichen IFs einbauen müßte... Würde aber fast jegliche displaybedingten Timingschwankungen (auch bei etwas schnelleren Displays) verhindern.

Noch eine Anregung für die nächste SID-Version - hat ausnahmsweise mal nichts mit meinen Problemen zu tun ;) : Nachdem der Menu-Knopf ja eigentlich ein Exit-Knopf ist und es sowieso keine Möglichkeit gibt, im Menü das blinkende Untermenü oder den zugehörigen Wert zu "betreten", ohne einen Softkey zu benutzen: Wäre es nicht sinnvoll, auf einen durchwandernden "Cursor" in der ersten Zeile zu verzichten und bei Haupt-Encoder-Bewegung direkt das Menü seitlich zu verschieben (nicht erst, wenn der Cursor am Rand anschlägt)? Am Anfang war ich jedesmal auf der Suche nach dem Knopf, mit dem ich das blinkende Menü auch aktivieren kann und mußte mich kurz erinnern, den SoftKey zu benutzen. Das ist nach kurzer Eingewöhnung eigentlich nicht störend, allerdings fände ich die andere Variante gerade für Newcomer etwas intuitiver.

Ansonsten hab ich mir heute mal die Sache mit dem zusätzlichen Layer für die Osc-Encoder angesehen. Was muß ich denn beachten, wenn ich weitere Einträge in die CS_MENU_ENC_TABLE einfügen will? Muß ich dann z.B. auch die Offsets der nachfolgenden Menüeinträge in CS_MENU_ENC_HANDLER ändern?

Gruss,

       Thorsten (der in seinen U110 eine XG Wavetable Karte eingebaut hat ;-)

Wie, zusätzlich oder statt der Original-Elektronik?  8)

Viele Grüße,

Seppoman

Link to comment
Share on other sites

Hallo,

die erste Idee ist eigentlich schon obsolet, wenn Du Dir mal die v1.6alpha1 anschaust. Hier wird das Display nicht aufeinmal, sondern schrittweise mit jedem USER_Tick aufgebaut. So ist es nun voellig egal, aus wievielen Items ein Menue besteht, Du wirst das Delay von ca. 300 uS pro Parameter (bei Deinem Display ca. 1.2 mS) nicht merken!

Die Kopplung an den Edit-Button waere nicht ideal gewesen, sie wuerde die Bedienung nur noch komplizierter machen. Egal, wo ich auch etwas dokumentiere, meistens landen Dinge, die man nicht auf Anhieb versteht, doch im Forum. Und die Frage "warum zeigt das dumme Control Surface keine Parameter an, wenn ich an einem Knopf drehe" haette sich sehr schnell zu einem Dauerrenner entwickelt...

Zum Vorschlag fuer das Menue-Handling: Anfangs war die Menuesteuerung sogar ohne den laufenden Cursor programmiert, genauso wie Du es vorgeschlagen hast, aber aus irgendeinem Grund habe ich es dann doch anders gemacht - leider kann ich mich an den Grund gerade nicht erinnern, aber vielleicht faellt es mir irgendwann mal wieder ein... ;-)

Ja, CS_MENU_ENC_CS_Handler muss in diesem Fall angepasst werden - hier habe ich bisher auf Code Size optimiert, deshalb laesst er sich nicht so bequem erweitern.

U110: habe die XG Karte einfach zusaetzlich eingebaut, und dabei an den MIDI Thru sowie an die Audio-Ausgaenge 5 und 6 angeschlossen. Habe das Teil aber auch schon seit Monaten nicht mehr angeruehrt... ;-)

Gruss,

       Thorsten.

Link to comment
Share on other sites

Habe mich daran erinnert, warum das Menue nur mit dem Cursor scrollt(e): weil die Tastaturbelegung anfangs noch anders definiert war. Habe mich dann nach den Aenderungen so an das Handling gewoehnt, dass ich es eigentlich gar nicht ausbauen wollte.

Habe es nun trotzdem geaendert (wer es nicht mag, darf den CS_MENU_OLD_STYLE switch einschalten)

Gruss,

       Thorsten.

P.S.: wegen des neuen Display Update Handlings: da ich viele kleine Aenderungen an Code-Stellen vorgenommen habe, die teilweise ein Jahr alt waren, besteht nun erhoehte Buggefahr! (Das hast Du nun davon! ;-)) --- deshalb bitte gruendlichst testen!

Link to comment
Share on other sites

Hallo Thorsten,

erstmal vielen Dank für das geänderte Menu-Handling, gefällt mir deutlich besser :)

Die vierte Ebene für den OSC-Control hab ich jetzt sogar ausnahmsweise selbst hinbekommen ;) Dann können die letzten Löcher jetzt gebohrt werden.

Wegen WT-Timing: ist prima geworden, Parameter-Änderungen stören jetzt überhaupt nicht mehr. Nur ist mir aufgefallen, daß der bisherige Haupt-Problem-Sound "ARPSEQ Three" immer noch etwas wacklig ist. Ich habe noch nicht rausgefunden, was an dem anders als an anderen Sequencer-Sounds ist. Er holpert auch auf der Hauptseite ohne irgendwelche Aktionen etwas (hauptsächlich die schnellen daddat´s). Ich hab das gerade auch mit Standard Display und auch mit der 1.5 probiert, war anscheinend schon immer so. Kannst Du das reproduzieren, stößt hier der PIC einfach an seine Performancegrenzen oder was könnte der Grund sein?

Ein kleines Display-Problemchen habe ich auch noch gefunden - ich kann nicht 100%ig ausschließen, ob das doch irgendwas mit meinem Treiber zu tun hat, deshalb hier und nicht im 1.6a-Thread:

Wenn man bei den Menüs mit mehr als 10 Einträgen ganz nach rechts scrollt, fehlt der dritte Buchstabe der Bezeichnung des letzten Menüpunkts (beim neuen Menu Handling flackert er vereinzelt noch auf, wenn der Name erstmalig geschrieben wird, verschwindet aber sofort, beim OldStyle fehlt er, wenn der Cursor auf 10 steht, wenn man auf die 9te Position zurückgeht, erscheint er wieder). Hab ich gerade auch mit der 1.5 getestet und ist dort auch so. Ist das Dein Bug oder mein Bug  ::) ?

Viele Grüße,

Seppoman

Link to comment
Share on other sites

Hallo,

fein - somit sehe ich die Performance Probleme als geloest :)

Zur "ARPSEQ Three": nein, das ist kein Performance, sondern ein SID Problem. Der Huellkurvengenerator verhaelt sich manchmal etwas seltsam. Du kannst das ueberpruefen, indem Du die Release Time bei allen drei Oszillatoren mal auf 0 zurueckdrehst.

Hoerst Du den Unterschied?

Den zweiten Punkt kann ich gerade nicht so ohne weiteres reproduzieren - meinst Du, dass bspw. im OSC Menue das S von "OPS" fehlen wuerde?

Gruss,

       Thorsten.

Link to comment
Share on other sites

fein - somit sehe ich die Performance Probleme als geloest :)

auf jeden Fall, ist echt prima jetzt :)

Zur "ARPSEQ Three": nein, das ist kein Performance, sondern ein SID Problem. Der Huellkurvengenerator verhaelt sich manchmal etwas seltsam. Du kannst das ueberpruefen, indem Du die Release Time bei allen drei Oszillatoren mal auf 0 zurueckdrehst.

Hoerst Du den Unterschied?

besser wirds damit schon, aber nicht ganz perfekt. Aber vielleicht habe ich mich jetzt daran auch schon so "festgehört", daß das auch nicht mehr objektiv nachzuvollziehen ist... :)

Den zweiten Punkt kann ich gerade nicht so ohne weiteres reproduzieren - meinst Du, dass bspw. im OSC Menue das S von "OPS" fehlen wuerde?

ja, genau.

Bis dann,

Seppoman

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...