TK.

I understand, why a delay is useful, and as mentioned above, a n x 1 mS delay can be added easily. But I still don't understand, why MB808 should provide a negative delay, if there are better methods for an exact and jitter-free compensation (master clock sent with negative delay by DAW, MB808 adds configurable, positive delays) - it doesn't matter how the delays are controlled. Stored in the patch: no problem. Changed via CC: no problem as well... You are speaking as if you would know a perfect solution to generate a stable, negative delay at the MIDI clock slave side. Please share your wisdom! What is the exact concept? Best Regards, Thorsten.

Maybe there is no contact between the RD# pin of YMF262 and +5V? The voice issue is probably related to a defective YAC512, or to bad solderings around this chip. Best Regards, Thorsten.

Yes, old link... but this solution isn't multi client capable. However, since so many people asked for a FT232 based solution in the past, and refered to documentation which exactly explains how it works, but nobody ever did the step to try it for MBHP, I will do the work for you... in ca. 1..2 weeks Best Regards, Thorsten.

No, I haven't tested it yet, because I paid for Mandolane, and don't know, how to ensure that it is uninstalled before testing an alternative driver. Napierzaza: how is it running on your Mac? Best Regards, Thorsten.

Yes, you can leave out the optocoupler part of the core module and the 220 Ohm resistors of the merger MIDI Out in this special case without danger so long both PICs are supplied by the same voltage source. The Tx output of the PIC used for the merger has to be connected to the Rx input of the second PIC An more clever method: you could easily re-use the optocoupler circuit of the core module for the merger circuit. Just break the track which is routed to the Rx pin. One side (the Rx pin of the core module) has to be directly connected to the Tx pin of the Merger circuit, and the other side (optocoupler part of the core module) can be directly connected to the Rx pin of the Merger circuit. It's like if you would "insert" the merger Tx/Rx pins between optocoupler and Rx pin of the core module. Best Regards, Thorsten.

Beside of Beethoven's approach, this project could be interesting for you as well (it's a dedicated application): http://www.midibox.org/forum/index.php/topic,11070.0.html Best Regards, Thorsten.

Crypto71 developed a special application to midify the buttons and drawbars of an old Dr. Böhm CnT/L organ. He wrote: Full View

Alkex built a MIDI controller into a Speak&Spell case! :) He wrote:

For completeness, here are the pictures of Sebo's MIDIboxes, which he has already introduced some time ago. Once the scripts are running again, they will be in the gallery as well (together with other missing pictures) MIDIbox SID (Sebo called it Mini64): http://www.midibox.org/forum/index.php/topic,7269.msg48375.html#msg48375 MIDIbox 64: http://www.midibox.org/forum/index.php/topic,9490.msg67973.html#msg67973 and finally a MIDIbox SID Sebo built for a friend (Bruno): http://www.midibox.org/forum/index.php/topic,10934.0.html

Napierzaza informed me, that an alternative software is available here: http://www.humatic.de/htools/mmj.htm In distance to Plumstone/Mandolane it's free! (I added this info to the Meeshka's initial article, so that people are immediately informed about this possibility) Best Regards, Thorsten.

ok, if this application sends Note events, the pull-up resistor is not correctly connected. Check it again Best Regards, Thorsten.

No, in such a case you don't need to reconfigure the software. But you should doublecheck, that R9 of the core module (10k pull-up resistor) is connected correctly to avoid randomly triggered button events (or functions). Do you notice the same with the ain64_din128_dout128_v2_0 application? Best Regards, Thorsten.

You selected the right .hex file, thats a good starting point! :) The issue looks similar like this one, but this time the LED lits. However, I think the reason is the same: visually check the circuitry around the optocoupler. TEST IN7 allows you to doublecheck, that the optocoupler itself isn't failing (e.g. because of a defect) Best Regards, Thorsten.

Are the events from B0 1D..B0 3F sent as well? Then it looks like the snapshot function. Could it be, that you accidently triggered it? (check the button) Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=11064.0[/iurl]

I think, that using the MIDI merger is the best choice in such a case - I know many keyboards (not master keyboards) w/o integrated merger as well. Note that I'm planning to release a PIC16F88 variant of the merger project soon. It's just for completeness, because this PIC is smaller than PIC18F452 or PIC16F87x and powerful enough (it comes with an integrated USART). But it will require a PIC burner to flash the firmware - if you don't own a PIC burner, then PIC18F452 with MIOS bootloader is the better choice. Best Regards, Thorsten.

Ich denke, dass es an den Schiebereglern liegt - wie lang ist eigentlich der Faderweg? Ich habe das gerade mal mit den 60 mm Fadern von meinem Korg Microkontrol ausprobiert. Es ist ziemlich schwierig, die Fader so genau zu bewegen, dass die gesendeten CC Werte ohne Unterbrechung steigen (oder fallen). Hingegen klappt das mit den 100 mm Alps (Motor-)fadern meiner MBLC voellig problemlos :) Es stellt sich natuerlich auch die Frage, inwiefern das exakte Einstellen eines Wertes fuer Deine Anwendung relevant ist. Hierfuer verwende ich normalerweise gerasterte Encoder (oder Inc/Dec Taster) Gruss, Thorsten.

Modern DAW software allows you to apply a negative delay on the outgoing MIDI clock, this works quite well to compensate timings if really required, and it's a good idea to do it at the source (MIDI clock master), and not at the destination (MIDI clock slave), because the MIDI event timings could jitter (e.g. because a USB interface with bad timings is used), and this would influence the "quality" of derived (predicted) clocks at the slave side (result -> worse timings). Now we could add an individual positive delay of n x 1 mS on each drum trigger, this would be a simple firmware enhancement - but I'm not sure if this is, for what you are asking for. How is this handled by other analog and MIDI sequencers? Or in other words: how should this work together with your other equipment, and which equipment exactly? (I would like to get a clear picture about the requirements, not only an abstract request) Best Regards, Thorsten.

Hallo Braintu, ich bin mir nach wie vor nicht sicher, ob es sich bei den Messergebnissen fuer die AC Terminierung gegen Masse bzw. +5V um einen Messfehler handelt. Deshalb benoetige ich hier mehr Feedback von den betroffenen Usern, um mir ein genaueres Bild darueber zu machen, was wirklich weiterhilft. Theoretisch ist es egal, denn Vs und Vd sind wechselstrommaessig kurzgeschlossen. Aber wer weiss, welche Wellenform da wirklich in mein 20 MHz Oszi reingegangen ist, und inwiefern die Kapazitaet des Messkopfs, und die Masse des Oszis noch eine Rolle spielt... Wie dem auch sei. In diesen Schaltplaenen siehst Du, wie RC am besten anzuschliessen sind: http://www.ucapps.de/midibox_seq/mbseq_v3_din.pdf http://www.ucapps.de/midibox_seq/mbseq_v3_dout.pdf (gleiches gilt auch fuer V2 Firmware) Ich habe nun RC erstmal gegen Masse eingezeichnet - schaunmer mal. Falls Du keinen 100 pF Kondensator parat hast, probiere es mal ohne Kondensator, und stattdessen mit einem 220 Ohm Widerstand. Evtl. ist die Terminierung am Ende der DOUT Kette bereits ausreichend, vielleicht muss aber auch die DIN Kette terminiert werden. Ueber einen Erfahrungsbericht waere ich sehr dankbar. :) Gruss, Thorsten. /Edit: habe noch die Terminierung fuer J2:RC hinzugefuegt, weil das bei Tobsen's MBSEQ die Loesung war

Ok, das war natuerlich ein wichtiger Input. Vielleicht dauert die LCD Ausgabe zu lang, so dass ein neuer Wert bereits ansteht, waehrend die Display-Ausgabe noch nicht fertig ist. Es macht ja eigentlich wenig Sinn, jeden Wert sofort auszugeben, das LCD ist wahrscheinlich so traege, dass die Zahlen erst nach ca. 50 mS (oder mehr) sichtbar werden. Hier kann man also noch ein wenig Performance herausholen. In meinen Applikationen mache ich das meistens so, dass ich in einem Flag "vermerke", dass sich der Poti-Wert geaendert hat, diesen dann erst in DISPLAY_Tick() ausgebe, und dort das Flag wieder loesche (so dass der Wert nicht erneut ausgegeben wird). Diese Funktion wird seltener als AIN_NotifyChange() aufgerufen, aber immer noch oft genug, um Werteaenderungen "scheinbar" sofort sichtbar zu machen. Ein C Anwendungsbeispiel findest Du in ain64_din128_dout128_v2_0.zip (suche nach app_flags.DISPLAY_UPDATE_REQ --- das Flag ist in main.h definiert) Gruss, Thorsten.

Calculating the frequency from the given OSC register value is either very time or memory consuming. It isn't a function you want to have in the MBSID firmware. Maybe in a seperate application? But I guess that somebody would only try it once, and then prefer to use the real firmware ;) Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=11021.0[/iurl]

This won't happen, when you enable the Mono option in the ENS->SID menu Especially for Jam sessions the V2 firmware is much better, e.g. bassline and drum sequences can be easily prepared and interactively selected. However, the PIC18F4685 variant of MBSID V1 is located here In the PIC18F452 variant of V1 firmware, matrix registers are crossing the ECAN memory range - random things can happen. Sounds like an issue with R2 of the core (or could it be, that this resistor is not soldered?) Really weird; hopefully not a digital defect inside the SID - are you able to test it with another SID chip? Oscillator Phase Synchronisation (phase is reset together with ENV trigger for more percussive sounds) Best Regards, Thorsten.

So far, some possibilities and ideas for sharing the same user interface are discussed here: http://www.eight-oh-eight.org/phpbb2/viewtopic.php?t=169 http://www.midibox.org/forum/index.php/topic,10731.msg82698.html#msg82698 Most important answer: The SRIO chain is "hot-pluggable", so that you can easily switch back and forth between the cores during runtime - especially the thread in the eight-oh-eight forum contains some useful informations about this approach. Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=10931.0[/iurl]