TK.

Ja - wenn man das Board mit einem 24LC04 EEPROM bestueckt, kann man dem Interface einen eigenen Namen geben. Das EEPROM laesst sich mit dieser Applikation programmieren: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmbhp%2Fmbhp_usb_gm5_eeprom%2F Gegenueber Ploytec habe ich bereits auch schon angeregt, dass der eigene Treiber (ja, er kommt ebenfalls von Ploytec, und er ist leider immer noch nicht fertig) die Moeglichkeit eroeffnen koennte, jedem einzelnen MIDI Input und Output einen eigenen Namen zu geben. Wenn diese Information im EEPROM gespeichert wird, wuerden sie auch noch dann erscheinen, wenn man das Interface an einen anderen Compter anstoepselt. Ob sich das dann auch implementieren laesst, weiss ich nicht. Gruss, Thorsten.

No, I'm thinking about a special requirement for the program you are using to send the dump. EEPROM writes are blocking operations, it has to be ensured that at the time the EEPROM is programmed no additional MIDI data is received. MIOS Studio (and other tools which are interacting with MIDIbox applications, like the MBSID V2 Editor) are waiting for an acknowledge string sent by the core after the EEPROM has been programmed before sending a new SysEx command. You probably already noticed this ("Smart Mode") Alternatively the tool has to wait for a specific time before sending anything else to prevent the MIDI in buffer overrun (e.g. see hints about SysEx transfers with MIDI-Ox at various ucapps pages) You are refering to a state machine handler for SysEx transfers. It is required as well to parse the SysEx stream... However, since I was planning to write a SysEx handler example anyhow, I started with it Code is located here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F The code is a bit more complex than somebody could program a simple handler... the reason is, that I take many error cases into account to improve the robustness. I also consider different use cases (e.g. SysEx handling when MIDI merger is enabled - a different topic, but covered by the example) Normaly you should never receive an error acknowledge, but if somebody owns a bad, unstable MIDI interface, some diagnose messages are always very helpful. It also provides an optional checksum protection (disadvantage: checksum has to be re-calculated when patch is modified manually), and optional BankStick support in patch.c (therefore the abstraction layer) What is missing yet in this example, and what I'm planning to add later: a README.txt which explains the programming model and the different options and a new option which allows to send the EEPROM content nibble-wise, so that all 8 instead only the last 7 bits are transfered. If this code looks too complicated, then just consider again the usage of the generic MIOS download feature ;) (Still don't know, why exactly you are not using it, I especially don't know, what your application is doing exactly) Best Regards, Thorsten.

You could use NTDiskViewer to display the sector contents: http://www.download3000.com/download_48627.html Don't want to say that this tool is good, but it was the first one I found and sufficient for my needs Best Regards, Thorsten.

It was blocked by the firewall of the new server - I fixed this Best Regards, Thorsten.

Really great news, that at least SD card reads are working at your side :) Yes, thats correct. Creating new files would require a more complex FAT16 handling, which would consume much more flash memory. I quickly checked this by turning the sysex_sender into a sysex_overwriter function: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsdcard%2Fsysex_overwriter%2F it works as expected. Possible error at Windows side: you don't eject the device (right-click on device, "Auswerfen"), so that your PC reads the old content from cache Possible error at application side: it is not allowed to increment sdcard_file_sector, instead it has to be determined by the SDCARD_FILE_Seek(offset) function for the case that your FAT is fragmented. Hopefully yes! Good to know, that 4GB cards can be used this way. ;-) Best Regards, Thorsten.

You wouldn't notice such issues if you would setup your project properly. It's also hard to help you if you are starting to modify modules by hand, or if you are using expired packages from different releases. Therefore I recomment you: 1) use the most current mios_base package or use SVN, both contain the latest releases - especially of j5_io and hw_flags.inc 2) Don't copy files you find in application release packages, they could be expired or buggy (bugs which may not be relevant for the released application, but for yours) 3) try to use global defines or packages whenever possible. E.g., it was a good decition to use j5_io, because it allows other users to compile the project for PIC18F452 without modifying your source code Best Regards, Thorsten.

of course, this is important. It must be ensured, that the selected hardware flags are matching with your processor type (specified in the Makefile as PROCESSOR variable), because as you can see in j5_io.inc, the ADC is disabled depending on PIC_DERIVATIVE_NEW_ADC (defined in hw_flags.h) You can doublecheck the right selection by searching in the .lst file (in your project it's probably named project.lst) for the J5_IO_Init function. You should see, that opcodes have been generated for "movlw 0x0f", but not for "movlw 0x07" If this doesn't help: what is the content of address 0xf92 (TRISA), 0xf96 (TRISE) and 0xfc1 (ADCON1) - they can be read out with the debugging window of MIOS Studio. Best Regards, Thorsten.

SVN: I will check this soon, seems to be an incompatibility with the new server (common access via ssh is working, but it isn't public) As you can see here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fj5_io%2F the last change was 2008-08-05, and this version is also available in the current mios_base package Best Regards, Thorsten.

Without reading the complete posting: which version of j5_io.asm are you using? Recently I found a bug, and updated the mios_base package The change is also available in the repository (for the case that you are using SVN to receive updates automatically) Best Regards, Thorsten.

Hi, check out sm_c_example2 :) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsm_c_example2%2F No, it's only possible to add assembly code to C routines (but it's very tricky and not straightforward) Mostly it's easier to place assembly functions in a separate module, and to call the assembly code from C - this is demonstrated in sm_c_example2 Best Regards, Thorsten.

Cannot be realized with the existing concepts, but it's a nice application for a seperate core which somebody else could program (e.g. in C) Best Regards, Thorsten.

Not planned from my side; a tool which converts MIDI files into MBSEQ compatible patterns would have to be programmed by somebody else Best Regards, Thorsten.

Yes, this has been changed, but it is a feature :) This will show the edit screen so long you press&hold the layer button, and the message will disappear 2 seconds after the button has been depressed. Very nice for quickly checking, which events are played by a track without changing into the edit screen. You don't need to remember, how to enter the current menu page again. It's especially nice in conjunction with the step recording function, because it allows you to check the recorded values without leaving recording mode. yes, because it's only a layer display, and not layer edit mode Really? Why not pressing the edit button if you want to edit a layer? Without too much effort I could add following functions to the existing code: - replaying the current step of selected tracks so long a special button is pressed - after releasing the button function, either continue with the next step, or continue with the step which would be played if you wouldn't activate the function (in other words: if you activate the function for 4 16th note steps, the track would continue with the 5th step) I think that both possibilities are useful. The first matches with your descriptions, the second has the advantage that the track is in-synch again with other tracks once you release the button - optional 2x, 3x or 4x multi-triggers per step So, you want to speed up the step progression and clock dividers in addition. Thats possible, but it wouldn't allow to synchronize back to the other tracks before the next measure is reached. Is this acceptable? Maybe a special menu page would be helpful, where you can tweak multiple speed/repeat/step behaviour parameters which control this special function, so that everybody can decide by himself, which settings are working best with his style. haha - no ;) But I find these experimental features attractive. :) Best Regards, Thorsten.

I'm sure that I understood your question, I'm not sure how I can explain the methods better. You are asking: My answer was: You can modify the .hex file with a common text editor. You could also write a text processing script (if you know how to do this) to extract the data section and to write it into a new .hex file before loading the new file into MIOS Studio. It isn't difficult to do, there are many programming examples for SysEx handling and EEPROM store/load operations in the repository, but it seems that you haven't looked into the files... this makes it really difficult to help you. As mentioned before, most of the MIDIbox applications are supporting exactly these SysEx functions, and they are mostly programmed on different ways to cover special application requirements. They are not using MIOS Studio to exchange data. However, so long the incoming data is buffered (or directly written into existing data structures for the informations you want to exchange), you can read and write back with a selfwritten SysEx handler. Your SysEx handler has to store the received (and temporary stored) informations into the EEPROM after the transfer has been finished. But as mentioned before, you have to take care that during the EEPROM write operation no additional MIDI data will be received to prevent data loss. Best Regards, Thorsten.

Yes, the new server is incredible! Don't forget to push the "Paypal Webhosting" button at the right upper corner of this webpage if you aggree :) Best Regards, Thorsten.

Everybody who attend the first bulk order got a money request mail via Paypal or PM. Details are listed in the mail (number of ordered GM5/PCBs/Shipping Costs/Paypal fee/Total) - please doublecheck. Some words to the shipping costs: I had some additional expenses (e.g. shipping costs from Ploytec to me, shipping costs for 100 padded envelopes, etc...) so that I increased it by +0.50 EUR for everybody excluding the guys who get their order via Wilba. Tracking/Insurance: Insurance is only possible in conjunction with tracking. And tracking already includes an insurance for up to 35 EUR. I changed it the following way: everybody who requested insurance got also the tracking option. If insurance was requested, and the component costs were higher than ca. 50 EUR, I added the insurance option, otherwise I removed it. Best Regards, Thorsten.

What a surprise - thank you!!! :) I already considered to celebrate this anniversary somehow, but you know... I'm too busy... Even the exact "birthday" is not clear to me. Is it the day of creation, or the day I announced the finished project? I remember that I experimented with the PIC after I won a "PICstart Kit" during a Elektor design contest (10th price for a 80C31 based MIDI mapper). For me it was obvious that the uC has to send some MIDI events first, because I already owned the tools to analyse such messages. It was also the time where a friend showed me Rebirth (for those who don't know it: one of the first 303 and 808 emulations for PC) - it totally amazed me, but the mouse handling was so uggly, that I quickly combined my MIDI and PIC knowledge with the possibilities given by this software synthesizer (MIDI remote capabilities) - after one day the first MIDIbox was finished, and this was probably in June 1998. The controller was only capable of sending predefined CCs, and the pots were jittering due to the poor conversion routines, but we already had a lot of fun. I just noticed: my first song made with a MIDIbox is still available here: http://mp3.de/musik/genre/band/030303/12253/3 (Download "Do It") It seems that I haven't changed my style so much in the last 10 years ;) First announcement in the internet: an email to another friend at 1998-08-16 (sorry, german quote, use babelfish) The interesting point: 16 DM = 8 EUR for a MIDIbox, wasn't this attractive? ;) He encouraged me to announce the controller in a newsgroup - so, this was the first announcement: http://groups.google.com/group/de.rec.music.elektronisch/browse_thread/thread/dc5a7a8ef504ced8/1239b2e00294f6be After this posting another guy suggested to announce the controller at Synth-DIY, a revised version was published in another Elektor magazine, etc... ...and the rest was out of my control ;) I must say that I'm very happy to get in touch with so many people who already have, or who are starting with the same hobby. Some years ago it seemed that do-it-yourself in MIDI Controller and Synth area will die off because prices of ready-made units get cheaper and cheaper. I'm working hard to prove, that there is still more benefit to DIY a device instead of buying a ready-made one :) Best Regards, Thorsten.

Basically I'm using the same circuit like Ulrich Radig, but for the 3.3V supply I'm using the LM317 based VR circuit of MBHP_USB Depending on the weather I will find some time this WE to draw the circuit (hope for a bad weather! ;)) Best Regards, Thorsten.

I got the order today: And stuffed one module - it worked immediately; no PCB errors anymore! :) I will send the invoices via Paypal or PM during this weekend. Best Regards, Thorsten.

A new driver is available for DOG displays A precompiled test application is available in the MIOS Download section, and a schematic here They are looking sexy, no? :) And these are btw. the fastest LCDs I ever tested! (benchmark result: 1.61 mS!) And the power consumption of the backlight is extremely low, so that the 7805 of a core module doesn't get hot. Backlight colour and display variant can be freely combined - just select the colours you like. (I'm using a "EA DOGM163S-A" with black background, combined with the white backlight "EA LED55X31-W" There is enough space under the LCD to stuff some additional components, like a "DINX1": Sideview: Only Drawback I've noticed so far: currently no displays with 20 characters per line are available - it would be the ideal solution for MBSID V2. And two displays could be combined to a 40 column display. For applications which don't rely on special sizes, like MB64, MB64E, MBCV, etc... these displays are recommented from my side to everybody, who wants to give his MIDIbox frontpanel a special touch :) Best Regards, Thorsten.

Status: I haven't received the package yet Please continue to wait silently! ;) yes, thats the easiest way for all of us Best Regards, Thorsten.

Yes, I could provide some more Remote Key functions to control step recording mode. Which functions could be useful: step left/right/clear/repeat last entry?) Oops again! :-/ Was related to the last "quick" changes - also the beat LED was not working properly. It's fixed in v3_3b Should be possible (nice idea to control the tempo with a bassdrum ;)) - I've to think about a good place for the configuration. I guess that you want to define the MIDI channel as well? The metronome configuration page has some free room, maybe I will add it there. Best Regards, Thorsten.

:) I checked this and found an initialisation error in the J5_IO module (IO pins were in high-impedance state). Therefore I released a new MBSEQ version (v3_3a) and a new mios_base package (for programmers). Sidenote: MBSID V2 is probably affected as well, although I haven't noticed a problem with the gates during the last jam session - I've to doublecheck this, it's very strange (maybe PIC18F4685 has a different reset value for TRISA/TRISE) Btw.: I found out, that with a trick it's possible to record polyphonic notes stepwise, and improved this a bit in v3_3a. The normal step recording function doesn't work so well with chords, as each note of the chord will move the position pointer one step forward. But if realtime recording is selected, and the sequencer is stopped, the step pointer won't be moved, and can be directly controlled with GP encoder #6 below the "step" item. Update: polyphonic step recording supported in v3.3c Means in other words: you can select the step where you want to enter a chord without "realtime stress" ;) With v3_3a, the previous chord of a newly selected step will be cleared properly even when the sequencer is stopped. For future releases I'm planning to provide a third recording mode which allows step recording without auto-increment I came to this idea when I had to find a solution to determine the time between the taps accurately enough before starting the sequencer. :) Best Regards, Thorsten.

Algorithmic MIDI sequencing is nothing new, but this guy is a good (and funny) salesman. Btw.: 28:55 - sasha with his "selfmade" MIDI controller ;) Best Regards, Thorsten.

Ploytec has shipped the stuff today. I also got the invoice. No surprise: GM5 3.50 EUR + 19% VAT, PCB 2.50 EUR + 19% VAT Those who get the order via Swiss have to pay less VAT (details from Roger soon) If nothing unexpected happens, I will start to request money & send the first payed orders from end of this week. Deadline for paying: August 25th 20:00 PM CET - at this date, everybody in the list will be asked to buy the remaining parts (first come first serve - a bit EBay feeling ;)) Best Regards, Thorsten.