TK.

I'm wondering why you are asking such questions before experimenting with MIOS in order to realize that this is no issue... ;-) It depends on the used synthesizer if you will hear every single step or not, it's related to the type of parameter, the resolution, the sound engine implementation, the interpolation algorithm, etc... I don't remember the exact behaviour of the DB50XG, but I guess that most parameters can be smoothly changed without clicks. At least the CC controllable parameters, but also some SysEx parameters (I never controlled all of them) Of course, you have to save the current value of a parameter in RAM. The USER_ENC_NotifyChange function will be triggered on every encoder event (increments, decrements) and gives you an incrementer which has to be added to the value (7, 8, 16, ... bit doesn't matter). Mostly the incrementer is +1 or -1, but the value can also be greater when: you are using a different speed mode one of your function allocates the CPU for some time, so that the encoder handler received some increments which haven't been notified via USER_ENC_NotifyChange yet Even if the incrementer is > 1, let's say 4 or 6, and you are sweeping from the min to the max value very fast, you won't hear a clicking sound, unless the synth engine implementation is too poor (like Quasimidi stuff for example). Regarding the execution times: with MIOS absoltely no issue since this is an interrupt & event driven system, optimized especially for such applications. When you send a SysEx stream of (lets say...) 10 bytes by using the MIOS_MIDI_TxBufferPut function, your program will continue immediately and the string will be sent in background. Every MIDI byte takes 320 uS, 10 bytes are taking 3.2mS - enough time to do a lot of other things in parallel - printing out a 16-character message and a value on LCD takes maybe 200-300 uS, reading the characters from a bankstick will increase the time, but it will be still less than the transmission of a MIDI event, so that you can ignore it! MIDIbox SID is a nice demonstrator how smoothly parameters can be changed via SysEx - the control surface sends SysEx messages to the slaves and they are processing the incoming data in realtime. Best Regards, Thorsten.

Hi Tub, you definitely want to go for MIOS: the old PIC16F firmware will vanish from my website sooner or later (to avoid unnecassary confusion) and the MIOS based version will provide some new, useful features like a remote control via MIDI, up to 128 banks, on-screen MIDI event & labels editing, jumpless pot group morphing... in addition to the known functions of course... :) Btw.: if there are any beta testers who already own a MIDIbox64 and want to test the MIOS based version (which has grown up in the last months but isn't 100% compatible yet and comes with 0% documentation) just contact me. Best Regards, Thorsten.

Du hast folgendes geschrieben: deshalb nahm ich an, dass dieser Effekt mittlerweile auch beim Brennen via JDM zu beobachten ist. Er tritt also nur waehrend des Programmierens von Intern auf... die MIDI-Daten sollten die Spannung nicht zum einbrechen bringen, am MIDI-In fliesst quasi kein Strom, und der MIDI-Out wird erst nach dem Programmieren eines Blockes aktiv. Der Loader speichert zunaechst bis zu 1024 Bytes in einem Buffer, bevor er das Flash programmiert. Koenntest Du vielleicht mal das PCB-Layout irgendwo ins Netz stellen? Welche Chip-Revision verwendest Du (einfach die komplette Typennummer + Produktionsdatum aufschreiben) Gruss, Thorsten.

Hi, alright, but you should try to find the hardware related problem with the reset pin sooner or later to avoid random reset pulses which can crash or hangup your windows (as the M$ driver is extreme unstable) Could you please check if the EZ driver from the http://www.ucapps.de/mbhp/mbhp_usb_v1_0.zip works better? I don't mean the driver in the mbhp_usb\ subdirectory (here you should use v1.1), but the wintendo driver for EZ-USB under ez-usb\driver\ Best Regards, Thorsten.

Hallo Thomas, die Aussage bezgl. des Pull-Ups an RB5 ist falsch. Bei einem fabrikneuen PIC ist der LVP-Modus aktiviert, durch den Pull-Up wird er deaktiviert. Waehrend des allerersten Brennvorgangs solltest Du also sicherstellen, dass LVP hardwaremaessig disabled ist (der Pin also nicht floatet und auf einem definierten Pegel liegt), ansonsten wird IC-Prog mit einer gewissen Wahrscheinlichkeit einen Verify Error melden. Da der Brennvorgang beim ersten mal zufaellig geklappt hat, und das LVP-Flag nun geloescht ist, musst Du diesen Fall jedoch nicht weiter beachten (hoechstens bei den naechsten PICs, die Du programmierst). JDM: viele Leute hatten das Problem, dass der JDM zwar mit dem PIC16F problemlos funktionierte, mit dem PIC18F jedoch Probleme machte. Auf der MBHP_JDM Seite findest Du eine Troubleshooting Guide mit Loesungsvorschlaege. Seit es diese Guide gibt, sind keine neuen Probleme mehr gemeldet worden... Vermutlich musst Du die Programmierspannung mit Hilfe einer externen Spannung stabilisieren. Gruss, Thorsten.

It doesn't, because the first shift register begins with index 0, not with 1 Best Regards, Thorsten.

MIOS uses PORTB as bidirectional port. By default it's configured as output (for writing to a LCD), but sometimes it will be switched to input for polling the busy bit at RB7. I wasn't sure if the timeout mechanism works correctly in the meantime (an older MIOS version had problems when the busy bit was permanently 0), but I just tried it with my own MIDIbox and it works correctly, regardless of the voltage level at RB7. Another easy test: read out the flash memory with the JDM to check if any - and especially the complete - MIOS code has been uploaded. You can compare it with the .hex file of the mios_v1_3 release. The bootstrap loader is located at a seperate address range from 0x7c00-0x7fff - it should also match with the original release. Best Regards, Thorsten.

There is no active SR, MIOS loads the whole SR chain (16 DIN shift registers and 16 DOUT shift register) on every update cycle. You can use the MIOS_DOUT_SRSet function whenever you want (within or outside an interrrupt service routine) to set the 8-bit value of a single shift register directly. You can also use this function to get a pointer to this register to access it several times without loosing instruction cycles due to the "call" overhead. The functions for setting a single pin are called MIOS_DOUT_PinSet0 and MIOS_DOUT_PinSet1 why different functions? Because MIOS_DOUT_SRSet works much faster (since you are able to set 8 pins at once and you are able to work with the return pointer), but MIOS_DOUT_PinSet[01] looks more understandable for beginners who are reading the source code. Best Regards, Thorsten.

Hi Freddy, so far as I know there isn't a special schematic available for this PCB variant, I guess that Martin routed the additional parts directly without creating a connection diagram (-> due to the big effort) However, the old circuit of MIDIbox Plus 16 can be found here: http://www.ucapps.de/midibox/midibox_plus_16_old.pdf, but it won't give you much more informations. The documentation of Martins PCB is already perfect. Best Regards, Thorsten.

Nothing - the LCD prints "READY." and thats all. No upload request anymore. But since your core permanently requests for new code, MIOS possibly has not been uploaded correctly and/or crashes. Why? No idea - hope that the LCD data bus pins at port B of the PIC are not tied to ground... the level at pin RB7 must be +5V (the internal pull-up is activated to ensure this), otherwise the core won"t regognize that no LCD is connected. Otherwise: use the search function of this forum, search in the troubleshooting section for possible errors and how they have been fixed. Best Regards, Thorsten.

After MIOS has been uploaded correctly, you should only see a single Upload Request after reset, sent by the first level bootstrap loader. Is this the case in your setup? Did you also try some ofter, more simple applications? Why not connecting a LCD for debugging? Best Regards, Thorsten.

http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=mios;action=display;num=1063836255

You've tried to upload a .syx file which contains SysEx strings for device ID 0x00, but the device ID of your core is 0x01 There is a .hex file in the MIOS release which allows you to generate a new .syx with another device id (use the -device_id option of hex2syx.pl) Best Regards, Thorsten. P.S.: this presumption is based on your description in the german board - you wrote that you were not able to upload MIOS, which is required to upload any application...

Mittlerweile habe ich mich dazu entschlossen, MIDIbox NG voellig unabhaengig von der MIDIbox LC zu entwickeln - mehr zu diesem etwas vielschichtigeren Thema dann in den naechsten Tagen (momentan komme ich zeitlich nicht dazu, die Notizzettel, die sich in den letzten Monaten angehaeuft haben, zu sortieren --- habe Besuch, wie immer um die Oktoberfestzeit) - es wird eine "MIDIbox Roadmap" geben, aus der dann ersichtlich wird, wie es mit den Projekten weitergehen wird. Also: stay tuned. Was die Integration in Logic ohne LC-Emulation angeht: sehr aufwaendig, aber das liegt nicht an der MIDIbox, sondern an Logic selbst. Du musst halt Dein eigenes Environment zurechtbasteln - wie das funktioniert, steht bspw. unter http://www.memi.com sehr verstaendlich beschrieben Hier ein Beispiel: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1034804877;start=2#2 Gruss, Thorsten.

Jep. Und Schalter waeren uebrigens auch nicht perfekt geeignet, weil sie sich schlecht automatisieren lassen. Sprich: wenn Du den Patch wechselst oder den Wert direkt im Menu aenderst, behalten sie ihre Stellung. Bei einem Button + LEDs hat man dieses Problem nicht... Gruss, Thorsten.

...I'm sorry to inform you that I had to refuse the nomination of your ECOBox32 for the "MIDIbox of the week", since it looks too commercial-like ;-) But the presentation... just great! - can't stop giggling about the cheesy face on the magazine cover ;-) Best Regards, Thorsten.

...I'm sorry to inform you that I had to refuse the nomination of your ECOBox32 for the "MIDIbox of the week", since it looks too commercial-like ;-) But the presentation... just great! - can't stop giggling about the cheesy face on the magazine cover ;-) Best Regards, Thorsten.

Hi Thomas, 1) the very simple data structure of MIOS_MPROC_EVENT_TABLE is specified in the MT_ENTRY macro which is included in the same file: 256 2-byte entries with the first two bytes of the event. 2) See the documentation of the MIOS_EEPROM_* functions - all 256 bytes are free for users. Best Regards, Thorsten.

Btw.: the answers would also be interesting for me, since I'm not able to reproduce such effects. Best Regards, Thorsten.

You could unsolder the resistor and capacitor and test them as RC circuit (+3.3V -> C -> R -> ground) just to ensure that they are not damaged (but the probability that you have fried them is very low). The voltage between C and R must be 0V after < 1 second (you won't regognize the pulse...) If these parts are ok, the only reason why you see 3.3V would be that you've soldered the USB chip in the wrong direction... Best Regards, Thorsten.

This is a known bug in the current firmware, see also: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1060704667;start=0#0 for the workaround. Best Regards, Thorsten.

This is a known bug in the current firmware, see also: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=troubleshooting;action=display;num=1060704667;start=0#0 for the workaround. Best Regards, Thorsten.

Sure, this is definitely the error. The USB chip is permanently in reset state and therefore doesn't start. Just take a look into the schematic http://www.ucapps.de/mbhp/mbhp_usb.pdf for the supply voltages of the cap and the resistor. Note: If the resistor or the cap isn't tied to Vss/Vdd, possibly also other components are affected. Just follow the Vss/Vdd tracks with your multimeter to find the bad junctions. Best Regards, Thorsten. Addendum: the AN2131SC has a high-active reset, the PIC a low-active reset. This means: if you notice that the PIC doesn't run, check that the reset input MRST# of the PIC is on 5V level, and not 0V like for the AN2131SC

Hallo Bernd, "nur" ist ein wenig uebertrieben - kommerzielle Loesungen arbeiten sehr oft mit einem Microprozessor pro Fader. ;-) Ich bezweifle, dass sich mehr als acht Fader von einem Core adaequat ansteuern lassen, zumal ein Multiplexer die Signalqualitaet, und somit die Aufloesung verschlechtern wuerde. Ausserdem habe ich im MIOS Konzept 8 Motorfader maximal eingeplant (weil sie wesentlich mehr Register zur Zwischenspeicherung der verschiedensten Werte belegen) - da ist wirklich nichts zu drehen. Ansonsten: lies mal die Beitraege von ThomasT zu diesem Thema, er bastelt gerade an einer 4-core MIOS Loesung fuer seine Mega-Faderbox Gruss, Thorsten.

Hallo Bernd, "nur" ist ein wenig uebertrieben - kommerzielle Loesungen arbeiten sehr oft mit einem Microprozessor pro Fader. ;-) Ich bezweifle, dass sich mehr als acht Fader von einem Core adaequat ansteuern lassen, zumal ein Multiplexer die Signalqualitaet, und somit die Aufloesung verschlechtern wuerde. Ausserdem habe ich im MIOS Konzept 8 Motorfader maximal eingeplant (weil sie wesentlich mehr Register zur Zwischenspeicherung der verschiedensten Werte belegen) - da ist wirklich nichts zu drehen. Ansonsten: lies mal die Beitraege von ThomasT zu diesem Thema, er bastelt gerade an einer 4-core MIOS Loesung fuer seine Mega-Faderbox Gruss, Thorsten.