-
Posts
15,247 -
Joined
Content Type
Profiles
Forums
Blogs
Gallery
Everything posted by TK.
-
> It's in the files lc_meter_icons_h.inc and lc_meter_icons_v.inc no, these are the icons for the graphical display. Just one question before: are the meters displayed correctly when you switch to display page 1 (or 2, don't remember which page...). You can switch to this page with the appr. Special Function button, or you can set it as default page in main.asm (INITIAL_DISPLAY_PAGE) Best Regards, Thorsten.
-
C O M P E T I T I O N The guy who finds a string of MIDI bytes which reproduces the merger error deterministically will get one 8580RC5 for free! :) Best Regards, Thorsten.
-
Of course, especially the MIDIbox SID gets intensively use of the Merger. Steve: therefore an external merger won't really help here. So far as I remember, the PIC16F related problem was due to a buffer overrun (limited RAM)... but this isn't the case anymore with the PIC18F. I assume a really nasty bug somewhere in MIOS_MPROC or MIOS_MIDI. Although the handlers take special care for realtime events >= 0xf8 (they don't affect the running status), there could be a problem somewhere which does happen in very rare cases. I wrote a small test application for two core modules which stresses the MIDI lines extensively with random Note On/Off and MIDI clocks. Incoming events will be checked against the sent events. This application failed last night with 10 transmission errors within 12 hours... It could also be an error in MIDI-Ox, or Windows, or my MIDI interfaces (I used MIDIsport 2x2 and Hammerfall DSP and not MBHP_USB just to exclude another source of errors). So, this issue is really an adventure ;-) Best Regards, Thorsten. P.S.: PayC: do you really chain the MIDImon with the MIDIbox SID? This is not necessary, you can also connect the monitor in parallel to the Rx line, this reduces the latency by ca. 300-500 uS. Or did you mean, that you want to chain the monitor for testing?
-
Hi Stephan, this function isn't beta, it works fine with Logic Audio. Could it be that you've enabled the common LED Meters function of Cubase which doesn't match with the LC Protocol? If there is no alternative option, possibly a new LC_METERS pattern has to be programmed especially for Cubase Best Regards, Thorsten.
-
This time I will report a bug to avoid that you stumble accross the same problem... following discrepancy cannot be explained yet: if MIDI Merger is enabled and the core receives common MIDI events (like Notes, CC, ...) as well as a MIDI clock, the common events forwarded to the MIDI Out are sometimes corrupted. Sometimes means: with a propability of ca. 1% - therefore hard to reproduce. I won't have the time to fix this in the next days. So, if you notice such a problem, don't use MIDI clock and MIDI Merger at the same time! Best Regards, Thorsten.
-
Still mysterious, but fine that it works ;-) I will fix the software in the final release, so that the documentation matches with the implementation. This means, that you have to swap the pins again later. Best Regards, Thorsten.
-
Super, freut mich, dass es nun doch noch geklappt hat. :) Ja, es ist normal, dass die aelteren SIDs heiss werden. Ist halt NMOS Technologie... spaeter hat Commodore auf CMOS umgestellt, diese Chips werden dann nicht mehr so heiss. Gruss, Thorsten.
-
It should be clear that this is a copy&paste error in the comments, no? Because it explains the pin mapping of the input pins, and not of the output pins... I will fix the comment (sooner or later...) Best Regards, Thorsten.
-
Hi Christoffer, you are right. I've already fixed this imperfection, but haven't made a new release due to the effort... So, here the required changes: open cs_menu_ms.inc, search for the CS_MENU_MS_Send_SysExDump function and the "bsf CS_STAT, CS_STAT_DISPLAY_INIT_REQ" instruction. Remove this line thereafter open "cs_menu.inc", search for the CS_MENU_PatchUpdate function and insert "bsf CS_STAT, CS_STAT_DISPLAY_INIT_REQ" at the end of this function (before the return instruction) This will also fix the problem with the channel selection in the CFG menu Best Regards, Thorsten.
-
Hallo, danke fuer die ausfuehrliche Antwort! Mit diesen Details kann man sich schon viel eher vorstellen, wo evtl. die Ursache fuer das Problem liegt. Von der Softwareseite her machst Du alles richtig. Ich wuerde nun auf ein elektrisches Problem tippen. Evtl. ist die Spannung an J1 zu niedrig, so dass Vdd waehrend des Programmiervorgangs einbricht. Erhoehe mal die Eingangsspannung auf ca. 9V-10V. Falls das mit Deinem Netzteil nicht geht, deaktiviere probehalber das LCD Backlight (das verbraucht den meisten Strom). Gruss, Thorsten.
-
Perfect! :) Best Regards, Thorsten.
-
Hallo Jan, meine Beweggruende stehen auf der MBHP_CORE Seite: 8051: die meisten Derivate wie 80c535 benoetigen externe Memories, die schnelleren Varianten sind schwer aufzutreiben. Zilog und Motorola: zu langsam und schlechte Produktpflege Gruss, Thorsten.
-
The AOUT works perfect and has been successfully tested with this equipment: http://www.midibox.org/midibox_gallery/francois1.jpg The reason why the MBHP_AOUT hasn't been officially released yet is just that I'm planning to create a 64 multiplexed channel extension with S&H chips which will require an extension port. Once the MIDIbox SEQ has been finished, I will continue with this design. Best Regards, Thorsten.
-
Hi Dan, this would require some small changes.... in a lot of different files. Sorry, too much effort for me, I cannot help you to realize this. Best Regards, Thorsten.
-
Hi, a jitter > 3 is definitely too high. Seems to be a problem with the power wiring to your faders. Maybe it helps when you make the connections to Vs/Vd of J5 shorter. Best Regards, Thorsten.
-
> Its sending lots of midi messages actually over all 16 channels and pretty fast too. This means that you haven't tied the open (unused) analog inputs to ground... > On the wiring is VD (CORE) the same as VCC (LCD)? yes Best Regards, Thorsten.
-
Siehe http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1068921201 Wilba ist gerade mit seiner Familie umgezogen, deshalb kann es mit der Release noch ein wenig dauern. Aber das, was er bereits programmiert hat, funktioniert schon ziemlich gut :) Gruss, Thorsten.
-
Hallo, also wenn die Daten nur so "runterrauschen", wuerde ich vermuten, dass bei Dir das Delay zwischen den F7 Events noch auf 0 eingestellt ist --- muss aber auf 750 mS stehen: Aber an der Device ID koennte es ebenfalls liegen. Wie sieht der Upload Request genau aus? Gruss, Thorsten.
-
Hi, KS0066 works w/o problems. I'm also using some LCD modules with this controller. If you are sure that the PIC is running (does it send some MIDI messages?) then it must be a wiring problem. Last time a friend had a simmilar problem, and the reason was that one of the 16 cables was broken inside the 2-row connector - this problem was very hard to find.. :-/ If we had soldered all cables again, we possibly were able to fix this faster... so my tip: desolder the ribbon cable from the LCD and the core module, maybe check all 16 wires with a multimeter, and solder it again. Best Regards, Thorsten.
-
Just finished SID step A, PIC progging prob.
TK. replied to NorthernLightX's topic in Testing/Troubleshooting
Hi Twin-x, Still the same problem? Then open a new topic Best Regards, Thorsten. -
No, much more than 36 ppr cannot be natively handled by MIOS due to the minimum capturing cycle of 1 mS (the driver is optimized for up to 64 common rotary encoders). But it's possible to program a dedicated driver for higher resolutions - Tip: use MIOS_Timer with a capturing period of about 100-200 uS Best Regards, Thorsten.
-
Do you mean that the joystick just should send two different MIDI events for X and Y axis? This already works - just connect the pots to two different AINs Best Regards, Thorsten.
-
Alright ;-) Best Regards, Thorsten. P.S.: Hint - no, it doesn't work due to the limitations of the LC protocol
-
See http://www.ucapps.de/howto_debug_midi.html Best Regards, Thorsten. SUPER FAQMARKER
-
Just finished SID step A, PIC progging prob.
TK. replied to NorthernLightX's topic in Testing/Troubleshooting
Hi Alex, could it be that your MIDI interface has an automatic MIDI Thru (feedback) which is active so long as no MIDI port has been opened by the software? This would explain everything, because in this situation the upload request will be looped to the MIDI In of your core module, and the BSL will remain in "listen" mode. If this is the reason, I will add this issue to the MIDI Troubleshooting Guide Best Regards, Thorsten.