TK.

Hi DriftZ, Just read the comment above the function: ;; -------------------------------------------------------------------------- ;; This function is called by MIOS before the shift register are loaded And shift registers are loaded with the frequency specified by MIOS_SRIO_UpdateFrqSet (you should find this function call in your *_init.inc file - normaly every mS The problem with your code is, that ShowLower is called regardless of LEDDIGITS_PATTERN_CTR, 0 BTFSC LEDDIGITS_PATTERN_CTR , 0 call ShowUpper ;; (upper half of digit) call ShowLower ;; (lower half of digit) incf LEDDIGITS_PATTERN_CTR "btfsc" means: skip next instruction if clear - this means that ShowUpper will be skipped on every second cycle, but ShowLower will be called every time. Improved version: btfsc LEDDIGITS_PATTERN_CTR, 0 call ShowUpper ;; (upper half of digit) btfss LEDDIGITS_PATTERN_CTR, 0 call ShowLower ;; (lower half of digit) incf LEDDIGITS_PATTERN_CTR, F or better readable and understandable: IFSET LEDDIGITS_PATTERN_CTR, 0, call ShowUpper IFCLR LEDDIGITS_PATTERN_CTR, 0, call ShowLower incf LEDDIGITS_PATTERN_CTR, F (IFSET and IFCLR are some macros defined by myself (TK style, see macros.inc), they are using btfsc and btfss) Best Regards, Thorsten.

Hi John, two ports were necessary for the old PIC16F based MIDIbox16E application, which will vanish from my website in some months just to avoid *such* confusion. With MIOS all DINX4 modules have to be connected to J9. in mios_tables.inc, MIOS_ENC_PIN_TABLE you have to assign the rotary encoders to the appr. DIN pins. Best Regards, Thorsten.

Of course! Just assign one or two of the following IDs to the buttons of Layer A or B #define ID_MBLC_SWITCH_LC 0x94 ; switch to Logic/Mackie Control Emulation (like radiobutton) #define ID_MBLC_SWITCH_GPC 0x95 ; switch to General Purpose Controller mode (like radiobutton) #define ID_MBLC_TOGGLE_GPC 0x96 ; like a "caps lock" key #define ID_MBLC_HOLD_GPC 0x97 ; like a common "shift" key Best Regards, Thorsten.

Bankstick switching is already supported by the MIOS based MIDIbox64 (beta) and it will be supported by upcoming derivatives (MB64SEQ/16E/MF/NG), and by the next MIDIbox SID version of course. Just for information... ;-) Best Regards, Thorsten.

Hi Dan, the events which are used in GPC mode can be configured in mios_tables.inc, the strings in lc_gpc_lables.inc Ok, and the new release of MIDIbox LC allows to send a MIDI event when entering/leaving this mode: http://www.ucapps.de/tmp/mios_v1_3b4.syx.zip http://www.ucapps.de/mios/midibox_lc_v1_3b.zip This version provides also LED meters and a software controlled MIDI Tx/Rx LED. LED digits are not supported yet, since I have to add some hardware to my box in order to test this feature (can take a while) Best Regards, Thorsten.

Here some beta stuff: http://www.ucapps.de/tmp/mios_v1_3b4.syx.zip - a beta release of MIOS which works much better with Panasonic faders (thanks again to Steve who sent me 3 faders for testing!). I've reduced the speed dynamic range so that the motors are driven slower, but much more precisely. The modification works also with Alps, therefore it isn't require to set a "Panasonic" flag. Required setup: Panasonic faders: 8V, CaliUp/Down: 0x0c Alps faders: 8V, CaliUp/Down: 0x0e I've also fixed the problem described by Steve in an earlier posting, that the faders sometimes don't reach the zero position. Zero position is now reached when the fader value is less than the AIN deadband value http://www.ucapps.de/mios/midibox_lc_v1_3b.zip provides now three different touch sensor modes: ;; following setting configures the touch sensor behaviour. The touch sensors of the motorfaders ;; have to be assigned to the DIN pins in lc_io_tables.inc - the appr. IDs are: ;; ID_FADER_TOUCH_CHN1, ID_FADER_TOUCH_CHN2, ... ID_FADER_TOUCH_CHN8 (8 sensors) ;; If the master fader option is used, the ID is ID_FADER_TOUCH_MASTER ;; ;; TOUCH_SENSOR_MODE EQU 0: touch sensor events (pressed/depressed) be forwarded to the host program ;; like specified in the Logic/Mackie Control specification ;; TOUCH_SENSOR_MODE EQU 1: like mode 0, but additionaly the sensors will be suspended via MIOS, so ;; that they are not moved so long as the touch sensor is pressed ;; TOUCH_SENSOR_MODE EQU 2: like mode 0+1, additionally no fader move (PitchBender event) will be ;; sent when the touch sensor is not pressed. ;; ;; The mode "1" by default to avoid circular troubleshooting requests in the MIDIbox forum from people ;; who don't read this information before starting the application. ;; Mode "2" should be the prefered setting if your touch sensors are working properly TOUCH_SENSOR_MODE EQU 1 Hope that this solves all problems. Best Regards, Thorsten.

The solution is to alternate the patterns on every call of USER_SR_Service_Prepare, so that on the first cycle the upper half, and on the second cycle the lower half will be displayed. It's the same method which is used to multiplex the digits (thats the purpose of the counter...), your eyes won't regognize the fast changes. You could use a register named LEDDIGITS_PATTERN_CTR, increment this counter on every cycle (don't take care for overruns) - when bit #0 is set, write the first pattern to the SR, when bit #0 is cleared, write the second pattern. Best Regards, Thorsten.

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.