TK.

Hallo Pico, wie genau hast Du diese Zeit gemessen? Es liegt hier sehr wahrscheinlich ein Messfehler vor. Zum einen kann der Jitter nicht 96 uS betragen; dies wuerde bedeuten, dass 3 Bytes in weniger als 920 uS uebertragen werden. Die Framelaenge betraegt jedoch 960 uS, und selbst wenn man annimmt, dass der letzte Receive Interrupt in der Mitte des Stop-Bits getriggert wird, kommt das rein rechnerisch nicht hin. Desweiteren fehlt in Deiner Messung der USB Overhead. Verwendest Du einen selbstprogrammierten MIDI Treiber? Arbeitet er im isochronen Modus? Wie aendern sich die Timings, wenn mehrere USB Geraete am Host angeschlossen sind? Gruss, Thorsten.

Yes, this would be ok Best Regards, Thorsten.

The power LED identicates, that the PIC is up&running The voltage at the RCX pin is 5V when nothing is received It's not required to power the board via J2, the IIC port connection is enough The auto baud rate configuration is very fast and ends with a "Ready" like if you would use the SpeakJet in normal mode. Maybe you should try to send some simple speach elements (0x80-0xff), this is less error prone. E.g., just use my example which forwards incoming MIDI notes to the SpeakJet, each MIDI key should trigger another sound. You could also connect the MAX232 directly to the Receive Input of the SpeakJet, Reset, M0 and M1 must be tied like shown in the datasheet in this case ("minimum connection for serial control"), baudrate must be 9600 This allows you to troubleshoot your terminal programs without using the PIC (always try to reduce the number of possible error sources) Best Regards, Thorsten.

Another input: at the M-Audio webpage it is stated, that there are problems (...can lead to interferences) with motherboards stuffed with VIA chipset. It's recommented to install the latest windows version, and the most recent VIA 4-in-1 driver. Did you already take this into account? Best Regards, Thorsten.

You are using the right .hex file, never select another one (some of the .hex files could destroy the bootloader). I think you should try to find out, why the PIC sends garbled SysEx responses. A message begins with F0, and ends with F7. So far I can see in your snapshots, there are multiple F0 within one message. Currently I only know two reasons for such failures: - the PIC is reset during a MIDI transaction. This can happen on a bad PSU, bad or open solderings, short circuits - the PIC receives bad data frames. This can for example happen, if the MIDI interface cannot handle SysEx properly (ensure that you are using the MIDIsport Uno v4.2.0 driver), or if another MIDI hard/software sends MIDI data at the same time which is not merged properly at the software side It would be interesting for me to see the whole MIDI In log during a code upload (you can copy&paste the messages) Best Regards, Thorsten.

No, this cannot be done with MB64E The problem is, that this is an overfeatured generic application Overfeatured mostly means: no place for even more variants Generic means: a lot of possibilities, but hard to integrate special adaptions However, the things you've described here can be easily programmed with the C wrapper. By doing so, you won't get all the MB64E feature (e.g. configuration via .ini file, online editing of MIDI events on LCD, morphing, etc...) but you propably will never use them anyhow So: go for C, here you can realize all you need. Best Regards, Thorsten-

I'm not sure if my finalized project will get a 2x40 LCD, a rotary encoder, 6 buttons and a lot of Rx/Tx LEDs, or just only 8 buttons, 8 LEDs and 5 Rx, 5 Tx LEDs Most important feature for myself is, that I can quickly switch between different routings, and that I can change parameters of the routing (e.g. MIDI channel of a splitted keyboard zone or transpose value). One thing on which this depends is the 1U case I already have, but for which I haven't found a solution yet to mount a LCD properly (mechanical problem). Another point is, that I haven't found the time yet to continue with the USB routing, this will propably change the concept at all (e.g. more Rx/Tx LEDs, or just virtual nodes?) Best Regards, Thorsten.,

No, it doesn't work with buttons. This is something that somebody has to build into the application - I would like to see that variations of MB64E will be made available for public. Grouping 18 encoders: thats more difficult than grouping 1, 2, 4, 8, 16, 32, 64, 128, but it's not impossible. It would already work if you don't rely on the LCD output Best Regards, Thorsten.

Hi, this sounds interesting, since automating analog consoles is frequently requested, but nobody has ever developed a special application for this. Therefore I will propably accept this, but before I make my final decision, I would like to see the documentation (I just want to ensure, that you don't forget this important requirement for my permission) Best Regards, Thorsten.

You can already switch between the groups with "special function buttons" -> http://www.ucapps.de/midibox64e/midibox64e_sfb_table.txt With 15 encoders, a group should consist of 16 parameters (this is the default setting). 128 parameters are available Makes: 8 groups Best Regards, Thorsten.

Did you try this with the midibox64e application? Best Regards, Thorsten.

By default, the core MIDI interface is running at the standard MIDI baudrate (31250), for the to-COM option you need another baudrate (38200) which has to be selected in the ID header of the PIC during programming the bootloader. Mike used the standard ID (000000000000), so MIDI baudrate is selected Without a PIC programmer the only solution to change the baudrate is the use of a standard MIDI interface (if you don't have one, you could maybe use the gameport, see MIDI trouble shooting guide for schematic). Then upload MIOS, and use the change_id application in order to enable the COM flag Best Regards, Thorsten.

You need to adapt the pin assignments for rotary encoders to your hardware -> mios_tables.inc Best Regards, Thorsten.

Could you please try the latest release of MIOS Studio? -> http://www.midibox.org/forum/index.php?topic=6810.0 Best Regards, Thorsten.

Yes, and it works fine since more than 8 weeks under "real world conditions" :) -> http://www.ucapps.de/midi_router.html Best Regards, Thorsten.

Nice idea, but expensive... Best Regards, Thorsten.

A "running LED feature" is already available, the step position will just be XORed with the LED information which is currently displayed (e.g. gates, mutes, selected pattern, etc...). The code can be found in seq_led.inc, SEQ_LED_UpdateIRQ It looks complicated because of the possible variations (e.g. 4 LED lines instead of 1), but when you are searching for "if sequencer is running XOR position to GP pattern" you will find the code which is doing this job. For multicolour LEDs, you just need to replace this XOR operation by code which outputs the position on two alternative DOUT shift registers instead. Best Regards, Thorsten.

The arpeggiator runs slower when you synchronize it to an external MIDI clock. Just enable this synchronisation (via CFG menu, JSynthLib or CC), and try out following arpeggiator rates: If the arpeggiator is synched to MIDI clock, use following rate settings: - 64th note: 124 - 32th note: 118 - 16th note: 106 - 8th note: 82 - 4th note: 34 [/code] MBSID V2 will provide an alternative internal BPM generator, but if you synchronize your gear from a host sequencer anyhow, you will be happy with external clock synch (which is already available) Best Regards, Thorsten. P.S.: nice demos, Jess :)

You can implement different button values with meta events (-> mb64_meta.inc, mb64e_meta.inc) Best Regards, Thorsten.

Hallo, leider gibt es keine komfortablere Loesung, da musst Du jetzt durch! ;-) Im Grunde musst Du Dich nur nach dieser Anleitung richten http://www.ucapps.de/howto_tools_mpasm.html Falls mpasmwin sich mittlerweile nicht mehr im MCHIP_Tools Verzeichnis befindet, so klicke im File Explorer auf den "Suchen" Button, und tippe das Schluesselwort "mpasm" ein Die Suchen-Funktion kann man auch mit Windowstaste-F direkt aufrufen Und den Hund kann man wegklicken! ;-) Gruss, Thorsten. P.S.: bin diese Woche nicht zuhause, kann erst ab Samstag weiterhelfen

To 1) yes, to 2) you don't need to stuff them for the "DINX1 functionality" (compare with the mbhp_dinx1 schematic) Best Regards, Thorsten.

I don't want to misuse the V2 thread for introducing new V1 release candidates anymore, therefore this new topic. Razmo requested two changes in the arpeggiator handling to improve the usability. I found both very useful, and have build this into the application as default option (the old handling has been replaced by the new one!). Here the description in Jess' words (he can explain this better than me :): The same from the ChangeLog: Link to application: http://www.ucapps.de/mios/midibox_sid_v1_7303b_rc6.zip Best Regards, Thorsten.

John mentioned a latency of 1..1,5 seconds, this is not caused by the MIDI interface - the midisport 2x2 has a latency and jitter of about 5..10 mS +/- 1.5 mS (see also http://www.midibox.org/forum/index.php?topic=2342.0) So, it's more likely that the software causes the high latency - another MIDI interface won't help in this case! Best Regards, Thorsten.

Hi, the pull-up resistors are also required for rotary encoders. For the last DINX4 module, you don't need to stuff the unused 74HC165, so long R33 is connected Best Regards, Thorsten.

The search function works in the board context you are currently in. E.g., if you view the "Part Questions" board, the search function will only search there, and nowhere else. So - either change to the global context (e.g. click the home button), or use "advanced search" Best Regards, Thorsten.