TK.

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.

Btw.: MIOS Studio versucht, den Reboot ueber einen SysEx Request herbeizufuehren. Wenn die Applikation jedoch abgestuerzt ist (gab es waehrend des Uploads Fehlermeldungen?), dann klappt das natuerlich nicht mehr. Abhilfe: den Core manuell resetten - entweder Pin 1 kurzzeitig auf Masse legen, oder die MIDIbox einfach aus/einschalten. Danach startet der 1st level bootloader und der Upload beginnt automatisch. Es war also eigentlich gar nicht notwendig, den Bootloader nochmal neu zu flashen Gruss, Thorsten.

yes, SET_BSR is a macro which simplifies the usage of movlb, see also: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Finclude%2Fasm%2Fmacros.h Best Regards, Thorsten.

ok, so somebody else has to help you to find a proper solution (I assume that it will require some programming effort) Best Regards, Thorsten.

Yes, in this particular case it makes sense to store tables in internal flash. Your questions don't make clear if you want to replace the data tables dynamically (uploading a new table without touching the code). I guess, that this isn't required for your application. So, let the linker locate the data tables - don't take care for the absolute addresses by yourself, this isn't really required. Best Regards, Thorsten.

The skeleton links in the forum are obsolete, it's now part of the mios_base package This is the latest state: http://www.midibox.org/forum/index.php/topic,11882.0.html However, I think that something is wrong with your MacOS installation. Which gputils package did you install? The command "gpasm --version" should return "gpasm-0.13.5 beta" (or later) Best Regards, Thorsten.

Stryd: I don't understand, why MBSID would need a "local off" - MBSID only sends CS changes when CC mode is turned on. It's turned off by default, and it can be switched on/off from the CS Dj3nk: no, it isn't possible to add a second MIDI IN. Why not trying the proposed switch - or wait a bit and use the easier to realize GM5 solution? It doesn't require any software change, is more flexible and less expensive. Best Regards, Thorsten.

Yes, thats wrong. All operating systems support USB MIDI by default. The windows version (provided by Microsoft) has flaws, but there are mostly dedicated drivers available to fix the limitations. Under Linux and MacOS X no alternative drivers are required, as the performance is excellent! Eby: I would propose you to join the GM5 bulk order, for this money you won't get a better MIDI interface. For best performance, just connect each core to a separate MIDI IO pair, so that MIDI events can be transfered in parallel. A single GM5 supports 5 IOs, more than enough for your use case. I'm using GM5 since two months on my Macbook, and it works like a charm (and I really stressed it a lot ;)) Best Regards, Thorsten.

MBSID won't forward incoming events by default to avoid a feedback loop between synth and DAW. You can enable the merger function by executing the MIOS_MIDI_MergerSet function from external (e.g. your MB64) via MIDI. You can try this out in the debug window of MIOS Studio and once it works, just create a MB64 Meta Event which sends the same SysEx string like MIOS Studio. If this sounds too complicated, you could simply add a double pole switch to your MIDIbox for switching the MIDI IO routing of the MB64 and MBSID core. Or you could use a GM5 MIDI interface (ordered and paid during the second bulk run), and establish the MIDI routing with your PC (e.g. with MIDI-Ox or MIDItrix) Best Regards, Thorsten.

Thank you! Great to see how quickly you are navigating through the menu pages :) Blogged Best Regards, Thorsten. P.S.: now also part of the user's manual

While optimizing the app for code size, I touched the error by myself. Thats a nasty one! It only appears when the CS_M_HLP_PrnTrk_Tab table in cs_m_hlp.inc is (was) located between two 256 byte pages - since my own setup is a bit different (e.g. AOUT driver enabled), I never noticed this by myself ;) A new release will be available soon. :) Best Regards, Thorsten.