TK.

Hi Joente, the application has to send a note-off event for the previous note, before the new note is sent. So long the last pot value is stored (this is the case for MB64 for example), the realization of such a feature isn't a big problem. Which application are you using (selfwritten or official MBxx release?) Best Regards, Thorsten.

Thank you for checking this! I still haven't an idea, why the segment pins are reversed, but I will doublecheck this with my own LED digit module soon Best Regards, Thorsten.

thank you! You just have financed the LCD for my next MIDIbox :) Best Regards, Thorsten.

Just one month ago I tried some fresh 18F4620 and 18F4520 samples - they still have the EUSART bug. In the meantime it turned out, that not only the transmitter is affected, but also the receiver (sometimes it gets a frame error). Especially the fails on the 18F4520 prove that this is no configuration problem, since this device is 1:1 hard-and software compatible to the 18F452, where the Bootloader and MIOS are running pretty stable. I gave it up to inform the Microchip support about this issue. I tried it three times, each time I was handled like a newbie, or they confirmed the bug and gave me suggestions which are just totally useless. E.g. one suggestion was, that the transmitting routine has to turn off and on the serial transceiver after each transfer - with the result, that continuous back-to-back transfers are not possible anymore, and that incoming data will be corrupted (no full-duplex anymore). So - don't buy any PIC which includes the EUSART, it won't work with MIDI. Once Microchip releases new chip revisions, I will try it again. Best Regards, Thorsten.

Everything which is possible concerning encoder sampling is already part of MIOS, I really don't know what else could be optimized... How does he achieve 72 pulses with this encoder? What does he understand under doubling? (I want to see the waveforms...) Best Regards, Thorsten.

Could you please ask him, how he did this? (Can he also turn water into wine? ;-) I've no idea how it is possible to create 4 ticks from 3 (or less) transients this would just only left out some ticks (see the .gif file) If KDJ tells you how he realized this? If he has just only used an acceleration detection, then you can do the same by configuring MIOS_ENC_SpeedSet in fast mode Best Regards, Thorsten.

I'm very sure that the algorithm I've developed works correctly, but it depends on the hardware (encoder) if it's possible to quadruple the resolution or not. So, before we continue the discussion, it would be useful to know, if your encoder always sends a single MIDI event on a "tick" (use the MIDIO128 application to determine this), or if it can happen that two MIDI events are sent at the same time. If this is the case, then the quadrature encoded waveforms of your encoder are not like in the mios_encoder_modes.gif, and this means that there is no way for the software to make 4 steps of 1 Best Regards, Thorsten.

Hi, either you've selected a certain speed mode which slows down the encoder (which application are you using?), or after the changes in mios_tables.inc you forgot to re-build the application? Do you notice any change with different encoder types? Btw.: you could use the debug window of MIOS-Studio in order to change the Speed mode on-the-fly (but not the encoder type...) - the appr. function is called http://www.ucapps.de/mios_fun.html#MIOS_ENC_SpeedSet Best Regards, Thorsten.

You could upload the MIDIO128 application and count the number of MIDI events per revolution. Each Note On/Off has to be counted as one pulse Best Regards, Thorsten.

Hi Jeroen, it depends on the encoder type you've selected in mios_tables.inc, see also http://www.ucapps.de/mios/mios_encoder_modes.gif So, only with a non-detented encoder a quadrupled resolution can be achieved Best Regards, Thorsten.

Hi Nico, Donations to j.laan10(at)quicknet.nl are going to TwinX (who pays the MIDIbox server), Donations which are done at https://sourceforge.net/project/project_donations.php?group_id=95206 are going to me Best Regards, Thorsten.

Hi, thats really strange, because based on the source code the schematic and the LC_LEDDIGITS_TABLE are matching. Could you please write down the exact pin mapping that you are using now, maybe this help me to find the inconsistency. Following format is sufficient (just edit it): J3:D7 -> Blue dot J3:D6 -> Blue a J3:D5 -> Blue b J3:D4 -> Blue c J3:D3 -> Blue d J3:D2 -> Blue e J3:D1 -> Blue f J3:D0 -> Blue g J4:D7 -> 3rd digit J4:D6 -> 4th digit J4:D5 -> 5th digit J4:D4 -> 6th digit J4:D3 -> 7th digit J4:D2 -> 8th digit J4:D1 -> 9th digit J4:D0 -> 10th digit J5:D7 -> Green dot J5:D6 -> Green a J5:D5 -> Green b J5:D4 -> Green c J5:D3 -> Green d J5:D2 -> Green e J5:D1 -> Green f J5:D0 -> Green g J6:D7 -> left status digit J6:D6 -> right status digit J6:D1 -> 1st digit J6:D0 -> 2nd digit Best Regards, Thorsten.

Duggle sent me a beta version some months ago, it works fine! Best Regards, Thorsten.

Is this question related to this topic? http://www.midibox.org/forum/index.php?topic=5800.0 As mentioned in this posting, there was a small error in the schematic (normaly very obvious, therefore propably nobody ever noticed this before ;-) --- did you take this into account? Best Regards, Thorsten.

As previously mentioned, there was a mistake in the schematic, did you take this into account? Best Regards, Thorsten.

Thank you guys! :) Nico: I just have shifted the priority of this feature to the top of the ToDo list, so that it won't be forgotten - yes, it's possible without much changes (some functions have already been prepared) Best Regards, Thorsten.

Hi *, I just have released a new version of MIDIbox SEQ, it features an external 24ppqn pin and "Multi-Arp" events. Download: http://www.ucapps.de/mios_download.html ChangeLog: http://www.ucapps.de/midibox_seq_changelog.html There is also a new tutorial session which describes the Arp enhancements: http://www.ucapps.de/midibox_seq_tutorial4.html Have fun! :) Best Regards, Thorsten.

Check the MIDI channel and the selected patch... Best Regards, Thorsten.

Hallo Stefan, passt! Ich habe Deinen Code gerade in meine aktuelle Version eingefuegt, so geht er nicht verloren :) Einen kleinen Schoenheitsfehler gibt es noch: falls jemand den entspr. Kommentar in main.asm nicht liest, koennte es passieren, dass DEFAULT_ENCODER_GROUP_WIDTH einen Wert erhaelt, der bei Dir nicht abgefangen wird. In diesem Fall wuerde WREG einen undefinierten Wert enthalten. Ich habe es nun so geaendert (leider versteht MPASM kein "#elif") MB64E_LED_Update_Init_Group ; 0x09: returns selected group 1-8 SET_BSR MB64E_BASE #if DEFAULT_ENCODER_GROUP_WIDTH < 2 incf MB64E_GROUP_OFFSET, W, BANKED #else #if DEFAULT_ENCODER_GROUP_WIDTH < 4 rrf MB64E_GROUP_OFFSET, W, BANKED andlw 0x3f #else #if DEFAULT_ENCODER_GROUP_WIDTH < 8 rrf MB64E_GROUP_OFFSET, W, BANKED rrf WREG, W andlw 0x1f #else #if DEFAULT_ENCODER_GROUP_WIDTH < 16 rrf MB64E_GROUP_OFFSET, W, BANKED rrf WREG, W rrf WREG, W andlw 0x0f #else #if DEFAULT_ENCODER_GROUP_WIDTH < 32 swapf MB64E_GROUP_OFFSET, W, BANKED andlw 0x07 #else #if DEFAULT_ENCODER_GROUP_WIDTH < 64 swapf MB64E_GROUP_OFFSET, W, BANKED rrf WREG, W andlw 0x03 #else swapf MB64E_GROUP_OFFSET, W, BANKED rrf WREG, W andlw 0x01 #endif #endif #endif #endif #endif #endif call MIOS_HLP_GetBitORMask rgoto MB64E_LED_Update_InitLoop_Cont [/code] Gruss, Thorsten.

Could it be that there is an error in the schematic? It seems that all blue lines are shifted (e.g., segment g should be connected to D0, not to D1) - the dot is normaly connected to D7 Can you confirm that the LED digits at the right side only show garbage? Best Regards, Thorsten.

Thats the normal behaviour - the Link button is also some kind of "panic button" for the case that there is a hanging MIDI note - this can happen if you play a note, don't release the keyboard and disable the Link... very annoying, therefore this feature :) Best Regards, Thorsten.

Hi Dale, the input which you've marked with STROBE# (pin #6) is not a strobe, but an inhibit signal, which switches off all transmission gates. This signal should be 0 so long an ADC conversion is running, and it's save to let it 0 the whole time (in my own circuit I tied it to ground). But propably the main problem is that you didn't take the required setup time of the ADC into account: once you've switched to a new input, you have to wait for a certain time before the next conversion can be started, otherwise the voltage at the S&H unit of the ADC is not stable. In MIOS I've realized a two-step timer driven conversion. An ISR is called each 100 uS, at the first step a new 4051 input is selected, 100 uS later the conversion is started. The value of this conversion is available with the next call of the ISR. The timer delay can be reduced of course, but this would load the CPU much more than really required (no timeslots for other tasks) Before MIOS I used a method w/o ISR - after the selection of the 4051 input, a dummy conversion was started, just to get some delay. Thereafter a second conversion was started to get a stable value. However, this loads the CPU much more than required, but it's easier to realize Best Regards, Thorsten.

Just try different values between 470 pF and 22 nF - note that caps can be combined in order to increase/decrease the value based on the equations: C_total = C1 + C2 (two caps in parallel) and C_total = 1/(1/C1 + 1/C2) (caps in serial) Best Regards, Thorsten. P.S.: I and some other guys of the forum tried different cap values long time ago - the filter behaviour gets worse with higher/lower values, but nobody focused to eliminate the stepiness...

Hi Kokoon, I don't have the feeling that this would improve the results, but you can do some experiments with different caps of course. Best Regards, Thorsten.

Hi Seppoman, Somewhere below "SID_BANK_SetBankStickAddress" is a routine which checks if a BankStick is connected or not - this routine also needs to be adapted (currently I don't have the sources right here...) Best Regards, Thorsten.