TK.

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.

I'm sure that this has been fixed Could you please press the EXIT button and check the version number? It should be v3.3c There is no routine which could display "G1Tx", and with my installation the track number is correctly displayed. Did you receive error messages during the upload? Best Regards, Thorsten.

Could you please try the "bad" optocoupler with a lower pull-up value for R6? Proposal: solder a 1k resistor in *parallel* to the 1.2k resistor (leads to ca. 550 Ohm, and you don't need to desolder the 1.2k resistor) It would be interesting, if the MIDI In is working thereafter? Best Regards, Thorsten.

No, the application uses its own ADC scanning routine which isn't extendible for analog multiplexers. Also the inputs of the slave cores cannot be scanned by the master core (event propagation from slave to master would lead to a performance loss) Best Regards, Thorsten.

Ok, after a lot of changes it seems to work stable again :) MIDIbox SEQ V3.3c Mainly bugfixes: - fixed disco lights in pattern page - layer button functions now also accessible in mute/pattern page. When pressed, it gives you a quick view of the selected track/layer - this screen now disappears immediately when layer button released (it seems, that the delay was too confusing) - bank/pattern switch in song mode working properly again - polyphonic chords can now also be entered in step recording mode w/o stopping the sequencer - new MIDI remote keyboard functions, especially useful for live/step recording: C-7 + A-4: Decrement step C-7 + B-4: Increment step C-7 + A#4: Toggle gate of selected step Best Regards, Thorsten.

I connected dual colour LEDs to the DOUT register, but only use the green LEDs. Best Regards, Thorsten.

Nils: you could add an USB socket as well, and maybe align the connectors, so that the MBHP_USB_GM5 board can be plugged onto this "doughterboard" upside down. The 5th optocoupler can be ommited for such a solution. Best Regards, Thorsten.

MIOS decodes incoming MIDI events, so that the user application doesn't need to take care about the running status - USER_MPROC_NotifyReceivedEvent will always get the complete event. This not only simplifies the programming of a MIDI processor, but also the merging of an incoming and an internally generated MIDI stream (the user application isn't able to send a new event so long an incoming event has been forwarded completely) Note On with velocity 0 -> Note off conversion has to be done at application side (see also this example). With enabled MIDI merger, the discarded status byte of an incoming MIDI event which gets use of running status feature will be added to by MIOS before the event will be forwarded. This isn't an optimal solution, but some years ago I didn't see a need for this, meanwhile I would like to add such a feature to MIOS (once I find the time...). It will require a timer function which resets the running status after some time (e.g. after one second) to ensure, that a MIDI receiver sooner or later receives the running status if the MIDI cable has been disconnected/connected during runtime. Best Regards, Thorsten.

Das einzige noch offene Problem ist der fehlende Kopierschutz (momentan kann man noch x-beliebige USB MIDI Interfaces damit betreiben). Ploytec arbeitet dran. Aus diesem Grund ist auch keine Vorabveroeffentlichung moeglich. Der Treiber wird dann auf meiner Webseite verfuegbar sein. Gruss, Thorsten.

Thanks for reporting, I'm working on the bugfixes. Meanwhile I also found the root cause for display artifacts and started to overwork the message handling, but it needs much more time to solve this properly than expected. Btw.: the application is running out of memory, here I need to find a solution as well... (optimizing some redundant parts) Best Regards, Thorsten.

Unfortunately it isn't possible to solve this arpeggiator switching properly due to conceptional reasons. The special handling of an arpeggiator in multi mode was already an unplanned add-on which required a lot of branches to get it working properly. You are saying that "Multi engine can't work with the builtin arpeggiator". This is wrong - instead, it should work perfectly with the multi engine! The voice handling is similar like for mono instruments to ensure, that an arp is always played by the same voice and arp sequencer, so that up to 6 different arpeggio instruments can be played in parallel over different MIDI channels or keyboard zones with dedicated sounds. I spent a lot of time to get this working, but it was clear to me that the current implementation isn't a proper solution... Covering the "turn off arp" case properly would require an indicator in the voice queue which stores, how the voice is/was used. It would consume additional CPU cycles when searching for a free voice etc... I think that it isn't really worth the effort to fix this. Instead I think, that the listed workarounds are fine ;) Best Regards, Thorsten. P.S.: I will think about a better 2x16 LCD support sooner or later, but for me this is a minor issue, there are currently much more criticial bugs, e.g. sometimes the engine is so overloaded, that this results into hanging notes. I already consider to remove or disable features in order to overcome this

Sold Out! The second bulk order will probably be started end of this year (if there are enough requests) I cleared the GM5 request list, please enter your name again if you are still interested. If you don't remember the ordered quantity, just have a look into the history (-> "Old Revisions" button) Best Regards, Thorsten.

Hi Alexander, did you really search for examples? Here you will find a lot of examples for accessing assembler code from C with a wrapper: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2F This example is a bit more simple, only one file which references (and contains) the assembly code: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsm_c_example1%2F The mclock.c file of this application demonstrates, how to use inline assembly code: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fclockbox%2Fenhanced%2F Best Regards, Thorsten.

There are currently exactly 30 spare GM5 chips + PCBs Since so many additional people added their name to the request list in the last weeks, I'm planning to sell the remaining chips and PCBs only bundled in a Duopack (2 GM5, 2 PCB). I think that this is a fair "finish" for the first bulk :) This also simplifies the calculation of costs: 2 GM5 2 PCBs, VAT, no PayPal, shipping within Germany: 16,78 EUR 2 GM5 2 PCBs, VAT, PayPal Fee, shipping within Europe: 18,78 EUR 2 GM5 2 PCBs, VAT, PayPal Fee, shipping outside Europe: 20,78 EUR Everybody who is in the request list will get a PM this evening 20:00 in the UTC+1 zone. The first 15 guys will get a confirmation Your response should contain: - your name - your postal address - (outside germany) email address of your paypal account To answer your question: add your name to the request list Best Regards, Thorsten.

I can only agree: it seems that Novation forgot to implement a fallback mechanism which allows to re-program the firmware if the previous transfer has been aborted. The AN2131SC is probably only used as USB->MIDI bridge; the EEPROM stores the firmware for this micro. It won't help to reprogram this EEPROM, in distance: it could make it worse. I guess that the firmware update targets the Winbond microcontroller, which contains an embedded flash memory, so that updates are not possible by replacing or reprogramming external components. Best Regards, Thorsten.

I guess that Futureman already linked Metasonix to a helpful programmer who will develop the application w/o MIOS, so that I can close this request. Best Regards, Thorsten.