TK.

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]

Sounds like an issue with the Vdd (+5V) line to the pots. If a bad soldering leads to a temporal voltage break (e.g. while a pot is turned), the voltage of all pots (or the pots which are supplied by the faulty Vdd branch) will drop to 0V Best Regards, Thorsten.

Now I know at least 5 guys who are located in Melbourne! ;) First of all, it would be interesting if any DIN pin is working - here a Troubleshooting Guide If (with the MIDIO128 application) each button sends an individual MIDI Event, and each encoder sends two individual events, then it could be a configuration issue. The default pin and shift Register assignments can be found in main.asm (and mios_tables.inc), and for prepared variants in the appr. setup_*.asm file Best Regards, Thorsten.

Some USB lines are so noisy, that this can disturb the uC execution (or the MIDI data transfer). Therefore it makes sense to use Optocouplers at both MIDI In sides, and to crossconnect the MIDI IOs (instead of using the MBLink port) For MBFM this is recommented anyhow, as the USB noise could influence the Audio Outputs as well. Encoder: from the datasheet it looks like DETENTED2, doublechecking the connections is important. As already mentioned: there are only 3 combinations - sometimes it's faster just to try all of them before trying to solve the issue on a theoretically way based on the wrong assumptions... Another point (the reason why I proposed to try DETENTED1) - are you 100% sure, that this is the right datasheet for your encoder? If DETENTED1 would work better, I could immediately say: ok, you downloaded the wrong one... ;) Best Regards, Thorsten.

Are you using Atmel or Microchip EEPROMs? Best Regards, Thorsten.

Dieses Verhalten koennte mit der automatischen Jitter-Unterdrueckung zusammenhaengen. Mit MIOS_AIN_DeadbandSet(7) wird das Deadband so gelegt, dass nur bei Werteaenderungen im 7bit Bereich die AIN_NotifyChange() Funktion aufgerufen wird. Wenn der Schieberegler jedoch schlecht entstoert ist (klemm mal das Metallgehaeuse auf Masse), oder von schlechter Qualitaet ist, kann es passieren, dass die gemessene Position mal zwischen zwei 7bit Werten (also bspw. zwischen 0x00 und 0x01) schwankt. Und hier vermeidet MIOS, dass dadurch staendig neue MIDI Events generiert werden. Neben der Entstoerung probiere mal folgendes aus: setze das Deadband auf den Wert 5, spaeter auf 3, 1, und schliesslich auf 0. AIN_NotifyChange() sollte nun wesentlich haeufiger aufgerufen werden. Wenn bereits bei 5 und 3 sporadisch Werte gesendet werden, obwohl Du den Schieberegler nicht beruehrst (dann kann auch von der Position der anderen Schieberegler abhaengen!), dann ist es eindeutig ein Jitterproblem. Das Deadband kannst Du entweder in der Applikation aendern (und anschliessend die Applikation neu aufladen), oder waehrend der Laufzeit im Debug Fenster von MIOS Studio Gruss, Thorsten.

Ok, MIDIsport 2x2 should work perfectly Btw: Sending block 00000000-000000FF [/code] which file are you trying to upload? Because this address range should neither be used by MIOS, nor by any MIOS application The bootloader is located at 0x0000-0x03ff, it cannot be overwritten via MIDI... You have to upload pic18f452/midi/mios_v1_9f_pic18f452.hex of the mios_update_v1_9f.zip package This is the only .hex file you need to upload of this package (thereafter you can start to upload an application) However, this isn't the problem here... The result of TEST_IN6 indicates, that this is neither a PIC, nor a MIDI interface, but a general (electrical) issue. It seems to be a bad soldering joint between MIDI In port, the Rx pin or the circuitry around the optocoupler. Without a scope, only visual checks will help here (I guess, that you've already checked the supply voltages...) Best Regards, Thorsten.

Hi, yes, the device ID of your core is 00. Which MIDI interface are you using? Are the In/Out ports routed correctly in MIOS Studio? And is TEST INOUT1 (see troubleshooting guide) really passing? Best Regards, Thorsten.

Wenn Du Dir mal den Schaltplan anschaust, wirst Du sehen, dass sowohl der Optokoppler, als auch J11:MI zum Rx Pin gefuehrt werden - wie soll die Software die beiden MIDI Streams unterscheiden? Nein, nur ein Signaltreiber darf an den Rx Pin angeschlossen werden, ansonsten gibt es einen Kurzschluss. Ausserdem muessen zwei MIDI Streams von der Software getrennt behandelt (und evtl. gemerged) werden. Hier hilft nur eine Verkettung der Cores (siehe MIDIbox SID V1), oder ein externer MIDI Merger (siehe entspr. Projekt), oder ein MBHP_IIC_MIDI Modul, das Dir einen zweiten MIDI In Port bietet. Gruss, Thorsten.

This topic has been moved to Trash Can. [iurl]http://www.midibox.org/forum/index.php?topic=10983.0[/iurl]

This topic has been moved to Trash Can. [iurl]http://www.midibox.org/forum/index.php?topic=10981.0[/iurl]

Perhaps type #1? Best Regards, Thorsten.

Running Cubase as a slave is a bad idea anyhow, because the software has a variable latency which cannot be compensated. MTC won't help you here... In conjunction with Cubase (or any other PC based DAW) I suggest you to use the DAW as MIDI clock master, and MBSEQ has MIDI clock slave. The sequencer will start/stop/pause in synch with the DAW. You don't need to push a MBSEQ button, it's remotely controlled. In addition, it's possible to set the pattern position directly from the DAW. Synching really works perfectly! I don't know, if you are asking these questions, because you haven't built MBSEQ yet and you are not aware of these already existing features, or if you tried this and it doesn't work (in this case: check the MIDI clock mode in BPM menu) Best Regards, Thorsten.

You are not really lost, because you can easily find out the pin assignment in the setup_*.asm file ;) Shortcut was the old name for CFG - I uploaded a new diagram to make this clear Encoder: looks like a wiring error (maybe ground terminal mixed with A or B line) My proposal: try out all three possible combinations if the datasheet doesn't make the connections clear enough Best Regards, Thorsten.

Please note, that I'm using duo-colour LEDs for group indicators as well, but only one LED colour is used by the MBSEQ firmware yet. The currently relevant DOUT pins are D7, D5, D3, D1 for group 1/2/3/4 (D6, D4, D2, D0 are connected to the second colour LED, and is reserved for future extensions) Although LED assignments can be easily changed in the setup_*.asm file, it makes sense to consider such details Best Regards, Thorsten.

You have to enable MIDI feedback for the LEDs: http://www.midibox.org/forum/index.php/topic,9504.0.html Best Regards, Thorsten.