TK.

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.

to make it clear: all external functions of the MIDIbox SID can be controlled in the menu too, just only for the SID, Link, CC and Edit button I decided to do it not, since the handling would be so circuitous, that it wouldn't make fun anyhow. This was my decition during the design phase, and it's some effort to overwork parts of the CS handler in order to allow alternative controling methods of these functions. In MBFM I did this (there is a special page which pops up when the CFG button is pressed - it allows you to control 8 special options), but I don't really want to do this again for the SID for various reasons. In other words: for you it's just for temporal comfort, for me it means: overworking and testing code, releasing it, support it in the future (before each release I have to try, if this feature still works), and answering additional questions about such "bad documented features" in the forum over the next years. Just to give you an impression, why I always try to reduce complexity. Believe me, it costs less time if you would just drill the holes! in the debug window of MIOS Studio, you are able to write directly into the memory of the core with the "SRAM Write" command. The "CS_MENU_SELECTED_SID_FLAGS" variable is located to 0x46 (please doublecheck this address in app_defines.h) write 1 to this address: SID 1 is selected write 2 to this address: SID 2 is selected write 3 to this address: SID 1 and 2 are selected Not sure which are the optimum settings for this encoder, you could try a different encoder type (see mios_tables.inc) or you could try different settings for CS_MENU_USE_DETENTED_ENCODER and CS_MENU_ENC_SPEED_VALUE (see main.asm) Best Regards, Thorsten.

No, link just means that the master will forward incoming MIDI events to the slaves. All of these options makes sense in daily work with the SIDs, but it's not a good idea to hide them deep in the menues. Therefore I wrote an explicit hint about this requirement at the StepB page. Once you have the buttons available, you know what I mean :) I strongly suggest to add these buttons - you still have some DIN pins free, which means, that there is no "resource problem" which prevents you from doing this. Best Regards, Thorsten.