TK.

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.

?? IO???????? ????????? ;) Gruss, Thorsten.

And if it doesn't work, solder a 220 Ohm resistor in parallel 33 || 220 -> ca. 28.5 Ohm Best Regards, Thorsten.

Yes, the EEPROM allows you to assign a different vendor/product ID (VID/PID) + vendor/product names to the device, but unfortunately there is a bug which prevents you from declaring more than 3 IO ports once EEPROM is selected to fetch the descriptors (J1/J2/J3 open) Details are described in the mbhp_usb_gm5_eeprom application, which can be used to program the EEPROM via MBHP_CORE module. In addition, the GM5 driver allows you to define different IO port names. If different port names should be assigned to different interfaces, you have to use EEPROMs to assign different VID/PIDs, so that Windows is able to differ between the devices I already requested this to Ploytec Currently IO port names are not stored in EEPROM, but this could be possible in future. Instead, port names have to be defined in a .ini file, which can be edited with a common text editor. I used the port routing window of MIDI-Ox to demonstrate the possibilities (and the advantage when using IO port names). Probably no other commercial MIDI interface allows you to do change the port names yet - although it is so desirable :) Best Regards, Thorsten.

Gruss, Thorsten.

Teaser for the upcoming GM5 Windows driver (note that the 5 IO ports can be named)

I added some infos about a Windows workaround for affected MIDI interfaces: http://www.ucapps.de/midibox_sid_manual_ed.html (press the reload button of your browser if you don't find the new text) Basically it is recommented to use Miditrix instead of MIDI-Ox to forward events, because this tool defragments the MIDI stream before it will be sent to the physical port. This is doing the trick. Miditrix also allows you to forward multiple MIDI streams, e.g. the one of your MIDI keyboard or sequencer, to the MIDI Out port. Vedge: this solution is more performant than forwarding inside Java! Best Regards, Thorsten.

Yes, it's correct for PIC18F452 and PIC18F4620, but not for PIC18F4685, where 0x60..0x7f and 0xd00..0xf7f are reserved for the ECAN peripheral. Under http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fetc%2Flkr%2F you will find linker scripts which contain a complete list of available memory locations These scripts are automatically selected by the Makefile mechaisms when compiling C programs. Best Regards, Thorsten.

Yes, it could be used. Alternatively, just use MIOS_SRIO_NumberSet(0) to disable SRIO accesses, and set it back to the original value to allow SRIO accesses again Best Regards, Thorsten.

Fine :) Btw: today I sent the remaining paid orders (meanwhile I'm able to prepare ca. 20 mailers per hour ;)) 10 Orders haven't been paid yet, the guys got a reminder; deadline is next monday. Some of you may have noticed, that the postage was lower than expected. The reason is simply, that the weight of some envelopes was lower than 100g. And sometimes the post office lady was so tired of checking the weight, that I got an unexpected discount ;) And another note: at one day it wasn't possible to get the requested injurance, since I sent the mailers from a smaller post office close to where I'm living. What I've also learned: PayPal fee is sometimes higher than expected - and I had to pay it. It's different for national/international payments. However, the saved postage compensated the loss. Here some hints based on my experiences I made in the last days. They could be useful if somebody is planning similar bulk orders in future. By asking the people to send emails with a special syntax in the subject, you can use your email program to trackback orders, money requests, payments and special requests. Also the communication channel is ensured (testing the email filters) Avoid Paypal if possible (e.g. on national money transfers), it saves money. Note that you have to pay the transfer fee! if Paypal is prefered: request the email address registered at Paypal don't provide different tracking/injurance options, this can drive a post office agent crazy... and the people who are waiting in the queue behind you ;) track the orders in a spreadsheet. Use different colours for "order confirmed", "money received", "mailer sent out". By creating cell-references in a second spreadsheet, you can print out the mailer addresses without much effort: However, all these measures saved a lot of time, but they don't completely guarantee that I put the correct quantity of chips and PCBs into the mailer. So, please inform me immediately if you expected more or less parts (my spreadsheet tells me, that the outgoing quantities are still correct) Best Regards, Thorsten.

Yes, so long this is a one-time auction, and nothing is prebuilt, it should be ok. Although I fear that this could quickly escalate once somebody offers prestuffed modules, or a halfbuilt MIDIbox - and at the end complete MIDIboxes :-/ To everbody: please ask me for permission when selling parts of the MBHP, I'm the copyright holder for most of the hardware and software. Selling via forum is prefered, don't send the wrong sign to people who quickly feel animated to make profit by selling even more modules via ebay. And please note, that we can request ebay to remove auctions thanks to the VeRO program Best Regards, Thorsten.