kpete

My reason for creating this Midi Player/Recorder (MidiFiler) project was to replace a Yamaha MDF-3 Midi Filer unit that is used on a huge Theatre Pipe organ at "Organ Stop Pizza" in Mesa AZ. http://www.organstoppizza.com/ The organist plays along with specific drum tracks that are loaded into a BOSS drum machine. The drum machine controls real drums and trap instruments around the large dinning room while the organist plays the large 4/78 rank Wurlitzer Pipe organ. This provides entertainment for the patrons while enjoying their pizza, beer and ice cream. They can seat over 600 people at one time in the dinning area and during the winter months its hard to find a table for 6 people. Some of the design criteria for the Organ Midi player are: a) Save data on the newer SD cards. Not the old floppy disks. b) One button to start playing a selected Midi file that doesn't toggle between PLAY/STOP. c) Only play back the selected file once and stop. d) Buttons or dial to select the song or track to be played/loaded. e) Be able to play and record songs in a selected directory that exists on the SD-Card. This allows 2 or more organists to store their specific tracks in special areas on a single SD-Card. f) Include a button to change to the next directory found in the root directory. Tree directory selection is not needed. g) Use a display that is easy to read. With the unit being inside a special drawer and only visible when wanting to load different patterns, allow the display to be turned off to help extend the life of the display. h) Record and play large blocks of SYSEX data packets. I also wanted to use this Midi Player/Recorder for my other organ projects so I included the following: i) Be able to select the looping parameters for playing the files. j) Be able to change the tempo of the song being played. Needed Hardware: LPC17 Core. SD card slot for storing the files. 20 x 2 line display. Standard Control Surface (SCS). Software The software base used for this project was Midio128 V3.019 with a different user interface. You can't go into the MENU page and most of the Shift functions are missing except for the record and loop functions. In fact most of the Midio128 software is still operational since that code was not changed and is included in the .HEX file. So you should be able to configure alternate values by editing the DEFAULT.MIO file which gets created when the SD card is first inserted in the SD-Card reader, but using the project like this was not intended. Functions of the buttons and encoder dial. Soft 1 - PLAY starts playing of the selected file Soft 2 - PAUSE/STOP the playing of the file. If in middle of file, PAUSE mode will be shown. Soft 3 - DIR change directory. Cycles between the root directory and any other directories in the root. Soft 4 - REC is a shift function and allows changing the LOOP parameters or recording a new Midi file. Soft 5&Exit - Next and Previous file select. Encoder - Changes the Tempo (BPM) as the file is playing or recording. Display OFF Function For the function of turning off the display, Analog 4 pin on J5B has been changed to a digital input with an internal pull-up. To turn the display off you just short J5B pin 4 to pin 1 which is ground. This is connected to a switch that shorts the line when the drawer is closed. The path of the files changed are found in the trunk/apps/controllers/midio128_v3/src directory. The files that were changed are: mid_file.c mid_file.h midio_file.c mios32_config.h scs_config.c seq.c The project.hex file can be found in the midio128_v3 directory in the zip file. midifiler128_v3.zip

I just when through the software that I had modified and found that I was using calls to functions in the trunk/modules/scs/scs_lcd.c file. This software uses a storage array called lcd_buffer[][] which was what I remembered. This is where the SCS_LCD_MAX_LINES variable is used. It so happens that the routines you are using are NOT using these and shouldn't be a problem as long as your software is not running the normal SCS screen functions. Pete

I don't know about the RTP or the STM32F4 board but I did use a 4x20 line display on one of my projects on the LPC hardware. The only difference as far as the display is concerned are the start addresses of the lines. But there are buffers in the LCD task that have to be allocated for the text being written. I haven't investigated where this happens for a long time but what worked for me was to add: "# define SCS_LCD_MAX_LINES 4" to the mios32_config.h file found in your apps directory. Pete

Well I don't remember why it took so many changes to get it to work a year ago but with some basic changes I did get it to work. Only issue is that it doesn't display the file names like the current release. It displays the file paths along with the file name on line 1 rather than just the file name. And I have an issue where after the recording is stopped that the line 1 is cleared rather than showing the new file that was created. There are a few other issues but I can work around these. I did add a new function called MID_FILE_StripPath() which simplified the processing issues considerably. Pete

About 1 year ago I tryed to modify the Midio128 software to be able to change where the Midi files would be found and saved. It started with simple changes but just like pealing and onion, it got more complicated as I found the next problem. I got the "read" and "find" functions working but ran out of time and never finished the "record" area of the software. Plus it also included changes in the file.c file in the modules directory which I want to avoid. I want to try it again with a new project but wanted some direction. Right now I want to get the software to work by just changing the path varialbe #define MID_FILES_PATH "" in the mid_file.c file. There is a comment just below indicating if you change the path to use a / at the end of the string such as: #define MID_FILES_PATH "MyMidi/". But this extra / causes other problems. And I don't want any changes to affect the software in the mios32\trunk\modules\file\file.c area. As of right now I am thinking about not using the extra / and just add it when needed. So the define would look like: #define MID_FILES_PATH "MyMidi". Does this look like a good direction to continue with or can I ask Thorsten to put changes into the midio128_v3 that would make this work properly? Pete Knobloch PS-Eventually I will just change this define to be a string variable that will have the current directory path in it and re-initialize the file system when I change this string. My final goal is to provide a button that when pushed, will change to the next directory in the root file system.

Hi all. I wanted to tell people about my first experienced with the OLED displays and some of the wiring issues. I also didn't know if they would even be compatible with the Midibox software. I built a project using the Midibox 8 bit core that allows me to play synthesized voices along with my 7 rank pipe organ. It uses a 4x20 LCD and buttons and allows me to change and save the voices for each of the selectable 12 stops. The problem being that it is almost imposible to read the display at an angle from the bench. In another thread there was some talk about connecting an Organic Light Emitting Diode display (OLED) to one of the Midibox projects. This link is They talked about how easy it is to see from almost any angle so I bought a few to test and see for myself. The display what they used in the Midibox SEQ project was manufactured by Raystar and was a direct replacement for the 40x2 LCD display without needing any changes at all. I found some displays from Mouser that work but they require 3 of the wires be left open to function properly. I ordered the 4x20 for $32.82USD and the 2x20 for $29.02USD manufactured by Newhaven. They run on 3 to 5 volts. The chip that drives the display is a RS0010 which seems fairly standard. It seems like the Midibox uses the 6800 pin configuration which is the default value for these OLED units. All you have to do is make sure you leave pins 3, 15, and 16 open when connecting them up. I just didn't solder any of these pins to the display which works fine but you have to be carefull not to put the connector on wrong. I tested the 2x20 display on my LPC17 bread board and it came up like a champ. No problems at all. The spec indicates it is readable at 80 degrees from the front and I now know this to be true. Now I just have to replace the display in my 8 bit core project which might be a probem because the thickness of the display from the mounting holes on the PCB is so much thinner. Pete Knobloch

Hi Jim, I have been playing with Midibox for over 5 years now. All of my projects have used the basic MIOS with modifications to the Midio128 version 2 and version 3 software packages. It so happens that what you are planing to do can be done with the Midio128 v3 software. You shouldn't have to change any of the basic software, just configure it for your use. The advantage here is that all of the inputs you are asking for can be supported by just one core. My opinion would be to wire your keyboards and pistons in an 8 by 8 matrix configuration. Midio128 will support up to 8 of these 8x8 matricies and you will need to use all 8 of these for the number of key inputs and Midi channels you want to send to your PC. I beleive that the matrix system is hard coded to send Note ON/OFF messages only. There is a "MODE value of "NORMAL or MAP but I don't know what it does. You might find this in the documentation. You configure which shift regisers (16 pins) will be used, the starting note, and the Midi Channel to send the messages out. One thing that I don't know is being able to configure your pistons to send Program Change messages. If you are using Hauptwerk then the PC can be configured to use Note ON messages for your pistons if thats the only thing that can be sent. You can buy most of this stuff from SmashTV http://mbhp.avishowtech.com/buy.html You would need 4 of the DIO_MATRIX boards. I don't think SmashTV has a kit available for these boards but you might ask. They do have the raw boards for only $7ea. Each matrix board will supply 2 of your 8x8 keyboards with 64 switches max per matrix. You will have to wire the switches in a specific sequence so the right notes will be sent for each key. For the core you can use the LPC17 unit. There is an even newer unit that is the MBHP_CORE_STM32F4 that is another option but as of right now it is fairly new. You will also need an SD card interface so that your configuration can be loaded when the unit powers up. An LCD and control cerface (SCS) is nice but not completely necessary since your configuration can be changed on the SD card using a simple editor like NOTEPAD++ using your PC. The LPC17 can send the midi data over the USB and/or the 2 Midi out ports supplied on the board. Your Swell and Crescendo data can be sent using linear pots connected to any one of the 6 Analog inputs. One thing that a few others have found out is that the DIO_MATRIX boards have to be very close to the CORE processor. The signals from the LPC17 board are only 3.3v signals and are more prown to pick up noise and not work over long ribbon cable runs. There are others on the forum that know a lot more than me and will be able to answer some of the more difficult questions. Hope this helps. Pete Knobloch Edit-Changed 8 pin to 16 pin for matrix shift register. It needs 8 outputs and 8 inputs to read the 64 switches.

Do you have your connectors wired right? The pin sequence for the Midi Din connector is 1, 4, 2, 5, 3 where the connector shown in in the Arduino shows the sequence as 1, 2, 3, 4, 5. There is a picture at the bottom of the Arduino link you posted earlier.

Very engenious to just select a very slow speed and send the NULL value. Just as long as you can make sure the 2 stop bits are sent before changing the speed back to 250k baud again. We had a DMX lighting demo done at work and they had problems with a group of fixtures flashing ON and OFF. It was fixed by properly terminating the end fixture. And the cables were only about 30 meters long. That post I sent about 2 previous back really doesn't pertain to anything in this thread. I was just curious as to how they detect the end of the break in the light fixtures.. I can see where a framing error would be seen if they were using the ASYNC receiver, but maybe they just switch the receiver OFF and read the IO pin directly and look for the end of the break using a bit bang process. When the IO pin goes high at the end of the break, then switch the pin back to ASYNC receive mode within this 8us time and start receiving the universe data. That is only 2 bit times which is extremely fast.

I don't understand why this "Mark After Break" time minumum value of 8us is so short. I would think that it should be the time to receive 1 character. This would make the value: 1 start bit + 8 data bits + 2 stop bits. I would add 1 just to be sure. This would make the time 12 * 4us = 48us.

Thanks for your replay about you trying to connect it directly to the LPC17. I do think it can be connected to the LPC17 directly but it wouldn't be able to support 32 devices and you won't be able to go over a very long cable. The 200mv value is the value that the Receiver hardware is to be able to receive the data and is not the spec for the transmitter. When you connect to the cable, it looks like an inductor with capacitance to ground and a specific resistance that changes as the cable gets longer and the speed of the transmission increases. At 250Kbaud this can be fairly lossy. Also with you connecting the cable directly to the LPC17 any static or power disturbances between the LPC and the light fixture is focused into the LPC pin which can blow up the part. To get it working without the buffer you can connect 2 resistors in series and connect them between ground and your 3.3v supply. Then connect the - side of the cable to the center of the resistors. You might even want to put a capacitor between this 1.65 volt reference to help stablize this reference. This might get you started but I wouldn't work with this as a final solution. Here is a link to the official DMX specification. http://tsp.plasa.org/tsp/documents/docs/E1-11_2008R2013.pdf Here is another link to a design that works with the PIC processor. http://ww1.microchip.com/downloads/en/AppNotes/01076A.pdf The PIC design will show you other timing parameters that have to be adheared to if it is to work with all light fixtures. One of these is the "Mark After Break" time. This should be at least 8us or 12us depending on which spec is shown. I don't know where this timing is implemented in your LPC17 code or hardware. BREAK signals are usually fairly long and the receiver of the break might be in the middle of receiving a frame when the break condition ends. If the first character is sent immediatly after the break condition, the first character can be lost. Thats why this is specified. Just a guess here but this might be why your light bar is flashing because it is missing the first NULL character or the slots are being missalligned from one message to the next.

This quote was from your first post. I was wondering what your physical layer looks like going to the light bar you talked about. Are you trying to connect it directly to the LPC17 ???? The DMX specification states that it needs a dual-differential signal EIA-485 compatible. This would mean the voltages should be +5volt signals. It also specifies a termination on the line with a 120 ohm resistor. With short lines I don't think the terminator is that important, but the +5v diferential signal would be very important to work reliably.

Well today I just updated my Windows 8.0 to the newer 8.1 version. And I now can communicate with SVN repository. Did the CHECKOUT function with no problems. So if anyone is having problems with this and are are using 8.0 version, go ahead and to an update to 8.1 which should fix it. Something else I thought I would mention is that when I did a compatability check before doing the 8.1 update, it indicated that MIOS_ Studio was not compatible. Well I have executed it with my LPC17 connected using the USB port and it recognized the core with no problems. The only things I did was do the QUERY and execute the MIOS File Browser to see what was on the SD card. Also created a directory and added a new file without any problems. Pete

You are very right. This is a digital way to do the same thing. You connect the switches in a matrix. In fact if you connect it up in a specific way you don't even need diodes. In the matrix you could even go to 16 position switches and have 16 separate switches with just one DIO_MATRIX board. To make it work you would take the 16 output chain wires (two 74HC595) and connect each one to the 16 positions of the switches. If you have more switches, just parallel all the 16 wires from one switch to the next and to the next. Now the wiper on each switch will connect to one of the inputs of the input chain (two 74HC165) of the matrix board. The diodes are not needed because each switch will have only one of the 16 positions making contact to the wiper at any one time.

You are right about the volttage values will change depending on the load of the analog input impedence but this would be very small. The resistors were just to know which position the switches were in, not to give an exact voltage as to the CC value. Software in the core would need to be changed to look for a range of the input voltage for each switch position and output a specific value to the synth from a table lookup or hard coded in the software.

For some reason I remember having this very problem when I tried to load the MIOS into my LPC17 but it was about 9-12 months ago. Why don't you try to select the LPC175x-6x -> "C Project" or the "LPCOpen - C Project" and see if you can load the file this way. The Laptop that I did this with had display problems and was replaced so I don't have anything to verify what version I did this with.

I just noticed that the schematic I was referencing in my last post was from "mono" and not you "matcom3". There was talk about analog inputs not being terminated when switching values. I was wonding if the capacitance of the inputs might be enough to hold the value for the time that it takes to go from 1 position to the next. Pete

You just added another complication that we didn't know about. You want 8 switches. With this I can agree with your direction with using analoge inputs for determining the position of the 8 switches. For some reason I thought that you had pots on each of the swtich positons and you were going to adjust each pot to output a specific value. Don't ask where I got this idea because I don't know. Your schematic diagram shown will work if each of the switch units have separate resistors (13 ea) for each switch. Thats 104 resistors. What I would do is take 13 - 470 ohm resistors and put them all in series and connect one side to VCC and the opposite side to ground. This gives you a reference voltage for each of the switch positions. Connect each resistor node to your switches. Now the wiper side of each switch can connect to separate analog inputs of your core processor. Pete

One of the problems with using the pots and the analoge input is that it will be difficult to make each switch position output a specific value. You didn't say how the CC values were going to be used but there may be cases where your system will output different CC values due to noise or temprature changes of the conponents. Using the DIN connected to the switch you don't have this problem. If you buy a DIN card from SmachTV the resistors are on the board. Just wire the ribbon cable to the switch and its done. Pete

Working and working reliably are 2 different things and can cause problems in the future. I wasn't familiar with this part so I pulled up the specification. I also thought that the LPC17 was using 3.3v rather than the 5v for the receivers but looking at the schematic showed I was wrong. The 10k for the pull up might work but it will increase the turn-off characteristics of the part. On page 6 of the specification on figure 10 it shows the part using 3 resistor values, the highest being 4k ohm. It shows a propagation delay of ~100ns with the 4k load and only ~50ns with a 1k load. I don't know if this would cause problems with long Midi cables or not but I would go back to the 1k resistor value anyway. In fact you could just add (parallel) a 1k ohm resistor to your 10k that you changed. Pete

In looking at the Fairchild 6N137 specification, it indicates that the ENABLE line should be left open or pulled up above 2 volts. The LPC17 schematic shows a resistor on this pin that is connected to ground. Might be best to cut and remove the resistors connected to pin 7 of the 6N137's. The output pin 6 is also specified to output a low voltage value of 0.6v at 5ma so the 1k ohm resistor between pin 6 and the +5v should be OK. I used the specification at this link: https://www.fairchildsemi.com/ds/6N/6N137.pdf

The MIOS and Bootloader software you found is good to load but it is not the Midio128 software. It is only the support software for the application. I found a version of Midio128 but it is an earlier version from what was loaded in your unit. To find it: Go to the http://ucapps.de/ web site and on the left side under the MIOS area, click on "MIOS8 Download". There is a zip file called midio128_v2_2c.zip that has the .hex file for version 2.2c. This software should work fine for what you need. Pete

Hi Jazza, So I have to assume that you loaded the "device_id_00.hex" file to your MidiBox. If that is correct then when you loaded it, this file erased the original Midio128 software and that is why its not responding to your scanner anymore. If your hardware had an LCD display connected to it things might be clearer as to what is going on. Since it looks like you were able to load the .hex file, you somehow stumbled onto a way to change the software. Now the next step that I think you have to do is load the Midio128 software into your MidiBox. In your first post it said: " the label on the PIC reads 'Bootloader v1.2b MIOS v1.9f MIDIO128 v2.2f 36-67' " To me it looks like he programmed your unit with MIDIO128 v2.2f. The 36-67 values might be the mapping defines for what's sent as the inputs are changed on the Din card. I have one of the MidiBox V2 boards that shows MIOS v1.9E and the chip is a PIC18F432. With the versions being so close, you must have one of the PIC18F chips which is good. Your next step would be to load the latest v2 Midio128 software. I think there should be a copy of this software somewhere, just that I can't find it so I can not reference the .hex file for you to download. Does anyone think that I may be on the right track here or am I propagating bad information? If I am correct, where can we get a copy of the Midio128 v2 software that might work on this hardware? Pete

Thanks. This means the problem is on my side.

Hi TK, Thanks for the response but your comment doesn't help. I tried to execute the "svn" command in the DOS window and it can't find it. In fact I did a search on the entire C: drive and the svn file name is not on the disk. The way I have done the checkout before is just go to the directory that I want the repository copied to and right click then select the "SVN Checkout..." line which then asks for the url of the repository. The last time we had this problem there was a TCP/IP socket that was being blocked that kept anyone from checking things out. I am going to reinstall the TortoiseSVN software and see if this fixes my problem. It might be another day or 2 before I have time to do this. Another thing. I don't think there was a change to the name of the repository but my IE browser shows "mios32A" in your last post (no space) rather than "mios32 A". When I did a copy and paste of the link it showed a space before the "A" which is probably right. Pete