TK.

Scrambling is not required, you can also use these routines, which are easier to handle: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F Details are described in the README.txt file Best Regards, Thorsten.

The microchip errata docs are partly incomplete. The bug is fixed on PIC18F2450 B5 and later Best Regards, Thorsten.

Strange, I don't see a reason why this doesn't work. MBLink is natively supported by MIOS, and you configured it correctly. Could you do some more debugging to find out, why a note is played after 7 seconds? Best Regards, Thorsten.

Hi Dario, thanks for asking! Since this is a one-time sale (especially not via EBay), it's ok for me. Best Regards, Thorsten.

I don't think, that the additional processing in the C program really affects the performance of your application, therefore it doesn't make much sense for me to evaluate a function I programmed ca. 5 years ago. You could try the hack by yourself, if it works fine - ok - if you find an error, then go the proposed way (I'm not planning to enhance the integrated merger of MIOS) Best Regards, Thorsten.

I'm using 1:1 prescaler in this example, so that the period time is easier to calculate. 1 mS == 10000 Maximum value for 1:1 prescaler is 65535 = 6.5535 mS got the point? At application level, there are no real advantages/disadvantages when using higher prescaler values. Just select a prescaler which fits your needs Best Regards, Thorsten.

This function allows you to disable the merger for the current and upcoming bytes until a new event begins. It's mainly intended for SysEx messages, and untested for other MIDI events. Many MIDIbox applications are using this inside the SysEx parser to allow to chain MIDIboxes with the same SysEx Header. However, as mentioned before: the programming example is the best solution for your usecase, otherwise the example wouldn't exist! Best Regards, Thorsten. P.S.: corrected wording - it could work, although I haven't intended this (and it's untested)

No, the merger is available since MIOS V1.0 The merger hack proposed by Durisian won't work perfectly, as merger data is forwarded before the hooks are called (corrected: it's forwarded after the MPROC_NotifyReceivedByte() hook has been called, so it could work, but I propably never tested this usecase during implementation phase...). For your usecase (modifying the incoming stream before forwarding it to MIDI Out), just use the example that you already found. Best Regards, Thorsten.

Klar, es spricht nichts dagegen. GM5 ersetzt Dir 5 separate MIDI Interfaces Mache ich aehnlich, siehe MBHP_LTC Modul. Jedoch verwende ich zwei Gatter, und verschalte sie zu einem Monoflop, so dass die LED nicht nur flackert, sondern laenger aufleuchtet (Delay ueber R/C konfigurierbar). Das ist kein Fehler, sondern technisch bedingt. Ploytec hatte urspruenglich gar nicht vorgesehen, den UART ueberhaupt einzusetzen. Nun ist er verfuegbar, und wir bekommen somit einen fuenften Port geschenkt - also nicht meckern, sondern freuen. ;) Gruss, Thorsten.

Ist bei mir genauso, und haengt wahrscheinlich damit zusammen, dass der 5. Port nicht emuliert, sondern von einem HW Peripheral bedient wird. Gruss, Thorsten.

It's a bug in your programmer. MPLAB is (or was?) affected by a similar issue, don't know why the vendors don't test the complete functionality of their programming algorithms. See also TEST_SW2 (-> http://www.ucapps.de/howto_debug_midi.html), where you will find an alternative workaround. Best Regards, Thorsten.

Yes, these are standard defines of the assembler (or sometimes defined in the PIC specific header file, somewhere in a gputils directory) Have a look into the project.map file - is the pca9635_StepCounter variable located at an address >= 0x80? In such a case, you have to set the bank ("SET_BSR pca9635_StepCounter"), and (to be sure, sometimes done automatically) the ", BANKED" attribute for correct addressing. Another potential issue: "rlncf" shifts the carry flag into the LSB, but you haven't cleared it before starting the 4 shift operations. Accordingly, either "1" or "0" is shifted into the variable. Best Regards, Thorsten.

No - you are calling the external function twice: call _mod_skel_extfunc call _mod_skel_extfunc After the first call, it isn't guaranteed that WREG still contains the previous WREG content Best Regards, Thorsten.

Thanks for the input! :) Best Regards, Thorsten.

I will inform Ploytec about this issue It sounds familar to me - MBHP_USB had a similar problem with Win2k, and I solved this by changing the Descriptors. Which reminds me, that you could do following test: You could program a new configuration into a 24C04 EEPROM with this application: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmbhp%2Fmbhp_usb_gm5_eeprom%2F In eeprom_content.c, change USE_AC_INTERFACE to 0, thereafter recompile the application, and upload it to a core module where the EEPROM is connected like a common BankStick On your GM5 board, open the J1/J2/J3 junctions by scratching them away with a screwdriver. Now your GM5 should read the EEPROM configuration once USB is connected. Best Regards, Thorsten.

Sounds like the encoder type isn't configured correctly. It has to be adapted in mios_tables.inc Best Regards, Thorsten.

This topic has been moved to Testing/Troubleshooting. [iurl]http://www.midibox.org/forum/index.php?topic=12128.0[/iurl]

So, it behaves like Legato mode? This re-trigger in mono mode is quite short (ca. 1 mS), it could be that your analog synth doesn't get it. There is currently no possibility to increase the delay of the re-trigger event Best Regards, Thorsten.

http://www.ucapps.de/midibox_sid_manual_up.html Best Regards, Thorsten.

Yes, it seems that your gputils package is expired. The current source code can be found here: http://sourceforge.net/project/showfiles.php?group_id=41924 Best Regards, Thorsten.

Have a look into the max72xx driver for a proper implementation example: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fmax72xx%2F the .asm wrapper only contains _<function> labels (these are the labels called by C) when more than a single byte is passed to the function. If only WREG (or no parameter at all) is passed, the _<function> and <function> is part of the .inc file Advantage: pure assembly applications without relocatable code only need to include the .inc file They don't "see" the stuff in .asm and .h If you consider this, it should be clear which labels should be put into a .inc file, and which additional labels/code/definitions have to be put into an .asm file Btw.: modules can also be programmed in C only instead of using .asm or .inc If you find mixed language programming too difficult/confusing, don't hesitate to write a .c module. Your application has very relaxed timing requirements anyhow! Best Regards, Thorsten.

Why do you think, that the C function doesn't return to assembler? Could it be, that you interpreted the MIDI output incorrectly? I'm missing a defined value in WREG when mod_skel_extfunc() is called, accordingly anything (maybe invalid MIDI bytes?) will be sent out by the core. It is btw. a bad programming style if lower level functions (part of your module) are calling upper level functions (part of your application). Was this only done for testing purposes? Best Regards, Thorsten.

How is this question related to Wilba's Control Surface PCB? GM5 is a closed source project. It doesn't allow to access the MIDI Tx/Rx ports via IIC. Best Regards, Thorsten.

See the original function (MB64_POT_ScaleValue), how to handle the inversion. Best Regards, Thorsten.

On my frontpanel, I will call this button "Utility" anyhow, regardless if it is mapped to F1 or not - why using a cryptic name when the purpose of this button is already clear? The MENU+GP 10 combination is mainly intended for people who forgot to add F1..F4 on their earlier panel (because they thought it has no useful function)... or if they use F1..F4 for other purposes. If you don't like this duplicate, it would probably be better to map the MENU function to another page (e.g. the upcoming event live triggering options?) Best Regards, Thorsten.