TK.

thanks for the info! I know this effect from a bad USB connection I had some time ago. I used an USB hub in order to extend the USB wire by 3 meters, but this had lead to an unstable connection. Under heavy load, the MIDI interface was shortly not available, and I had to re-select the interface in the device list to initialize the driver again. But I guess that this is not the problem here. Something seems to be wrong with the MIDI interface, the driver or with Java. I'm not sure, but maybe it's related to the same Java problem which is mentioned at the bottom of this page: http://www.ucapps.de/jsynthlib.html. Although nobody has noticed this issue with MIOS Studio yet, maybe you are the first one? Could you please try the proposed workaround which uses MIDI Yoke and MIDI-Ox? And could you please try it with and without the "waiting for upload request" feature? Best Regards, Thorsten.

no, I guess that you missunderstand my statements. The new engine will be much more powerful than the old one, but I cannot consider the whishes of everybody and I tried to express, why. The MIDIbox projects require always a consideration between features vs. performance vs. development effort vs. support effort. I cannot mention it in every thread, but I've mentioned it several times in the past: the aim of the project is to allow even newbies to build an electronic device. I'm trying my best to keep it so easy than possible, so that not only a elitist circle of people with deep electronic skills and expensive equipment is able to build a MIDIbox. When you read the troubleshooting section, you know what I mean - I'm hard at the limit where the high complexity demands for more support effort than ever planned at the beginning. I just want to highlight: I don't see it as limitation that not all your suggestions can be realized. There are already a lot of new features which will be very nice and useful, and I guess that the majority of people will be happy to use them. If it would be important to get features of professional synths as a "must have", I would skip my plans and do something else This is a future product, from my experience it takes 1-2 years until you can dare to start a project with a high lifetime, in the hope that the chip won't be cancled in the meantime. This controller comes in a 100pin package, I guess that only 5% of the community is able to handle this. Another problem is the availability: you cannot buy the chip at common mailorder companies, you have to contact a distributor, and they expect an order of 1k or more as minimum limit. And even if it would be available in small quantities, the price would be propably so high, that newbies would get really sad if they damage one device during soldering with a non-adequate iron. The success guarantee is much lower. I think the biggest problem is, that embedded programming is splitted into different worlds, therefore it might be hard to understand, why certain things are not possible with different platforms. There is the hobbyist world where people are working with established devices, which are mostly in DIP packages, therefore easy to handle and easy to replace. Programming these SoC is easy to learn, there is a lot of free literature available in the internet which helps for the first steps, and programms can be developed with free toolsuites. Then there is the professional world where the device package doesn't matter, they are able to handle with 4 layer PCBs, they buy thousand of pieces and distributors are their friends. They pay some thousand of dollars for programming tools and analysis equipment, and they don't rely on reproducability - instead, they are very happy that not everybody is able to clone their hardware. Are my statements more clear now? Best Regards, Thorsten.

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.