kpete

You are seeing the complexities of the build process for the MidiBox software. When you start digging deeper into the other projects, you will find out that much of the code found in the trunk/modules directories is also shared between all of the projects in the trunk/apps and the trunk/sequencers directories. The makefile system used here allows for this sharing because of how Thorsten has put #include files into the make system rules. You don't need to know how it works, just be aware that if you reference a "#include "file.h"" in your app.c file, that it is reading the file in the trunk/modules/file directory. Thorsten has also used a standard for naming functions based on the file names where the code can be found. As you found out if the function name starts with FILE_ then there is a pritty good chance you will find the function code in the trunk/modules/file/file.c file. If the function name starts with SEQ_CHORD then look in trunk/apps/sequencers/midibox_seq_v4/core/seq_chord.c file. You are having some problems understanding some of the basic "C" programming language being a beginner. We programmers have all gone thru this at some point in our lives. Your problem with getting the "declaration error" has to do with the compiler not knowing what variables are being passed and returned for the specific function that you called. There are 2 ways you can keep the error from happening. 1)have the function code placed in the file before the call to the code is made or 2)declare the function at the top of your file by having it shown outside of a function and terminated with a ";" character. When you include the file.h file in any .c file, these function declarations get defined for you because they are found in the .h file. Respectfully, Pete

Could the problem be that you are using the same port number of 8000 for your source and destination port?

It could be your problem. The specification indicates that putting a resistor to pin 7 decreases delay time and gain. This essentially makes the part faster. Change it.

In your first post Michał you indicated that the notes would be too loud or soft or would double or not play at all. To me it sounds like your keyboard is having problems with the contacts. I don't know if going with new hardware will help. It still might be a good exercise to do this since you have this site to help you understand now this dumb things works. It will be a great learning experience. Respectfully yours, Pete

With the Pianocorder the only interface that came with the piano is a cassette tape player. Did you make an interface which gives you your measured 1/2 second response time? It will be very difficult to remove all of the delay when playing a real piano from a Midi keyboard. The first issue is that most Midi keyboards send the Midi message when the key is 1/2 pushed down but the piano hammer hasn't even started to move until it receives the 3 byte midi message. The piano hammer has to move its mass about 1-1/2 inch before striking the string which takes time. To play the note loud you put more energy into the action to accelerate the hammer quickly to hit the string. This time is fairly fast when playing loudly. But when you want the note to play softly, you put very little energy into the action and the hammer moves much slower to the string which plays softly. When playing music on these newer player pianos with prerecorded files, the player logic delays the playing of the notes so that it can compensate for this mechanical problem between playing the notes loud or soft. To play 2 notes at different velocities and have them sound at the same time, the softer note solenoid can be activated 100ms earlier than the louder note. This time varies depending on how softly you want the piano to play. Even if you can get the delay down to 80ms it still may sound like the piano is echoing with the Midi voices. And most people can't detect a delay of 40ms from the time the key is pressed and the note sounds. Pete

I understand about your problems with the SVN. I just don't have enough experience in using it. The most I have done is do diff's between the original version that is stored on my PC. I'm too afraid to try to do an update in my sandbox for fear that I will have problems with merging changes in the same files that others have changed. From my previous knowledge with version control systems I know it can be done but I just don't need it for what I am doing. It is nice that TK has used a naming convention that helps pin point where the variable or function is located. Pete

Jef - I don't know whats going on with this but I find the define located in "seq_ui.c" file with a reference in "seq_ui.h". The revision header for seq_ui.c is: // $Id: seq_ui.c 2102 2014-12-15 17:40:04Z tk $ I got this information directly from the SVN.MIOS32 repositories on line. Are you using version 2102 for that file which was changed on 15-Dec? Pete

Going from 1k to 10k ohms doesn't make sense to me. I would have suggested going to 100 ohm if your problem was coupling between wires. I wonder if your problem was a missing ground wire going to your resistors.

You might try getting the 10 bit value then shifting it down by 2 bits. Depending on your variable types will determine how you save them. This code assumes they are 8 bit unsigned values. unsigned int Temp; Temp = MIOS_AIN_PinGet(0); // Get the 10 bit value. RANDOM = (u8) (Temp >> 2); // Convert it to an 8 bit value. Temp = MIOS_AIN_PinGet(1); VelOff = (u8) (Temp >> 2); Temp = MIOS_AIN_PinGet(7); NOISE = (u8) (Temp >> 2);

I have no idea what you are trying to do and why. The __wparam value is outside any defined parameter values for the function and its not part of the function which would mean it has to be beween the {}. Pete

If you are using the MIOS_AIN_PinGet() function, it returns a 10 bit value. If you put this into an 8 bit variable it will wrap around 4 times. Same thing will happen if you use the MIOS_AIN_PinLSBGet(). If this is going to be sent out as a Midi parameter, you need to use MIOS_AIN_Pin7bitGet() and it will return a value of only 0-127. MSB must be zero so it isn't recognized as a Midi command. As far as Dead Band, with short lines the analog converters in the PIC may still wander around a bit or more. Experiment with your Dead Band value if you need a stable value outputted.

How thick is your wood panel? Most of these readers have the SD card stick out about 1/4" when inserted. Why not just glue a wood block next to the slot to screw the board to. This way it only shows the slot and no screws in front. Or glue a right angle bracket to the back side of the board and screw it from behind your panel. Pete

John, you are a little vague with your question but what I have used for the SD card slot is a small breakout board made by Sparkfun.com https://www.sparkfun.com/products/12941 This unit has a spring loaded socket that ejects the card when you push on the inserted SD card. I solder a 10 pin connector on the unit then make a cable that connects the card reader to the LPC17 board. The back of the breakout board is completely flat except for the soldering of the connector that I add. I just cut a small area in the wood where the connector is soldered and take some screws that hold down the edge of the board onto a flat area of the wood. The head of the screws overlap on top of PC board so drilling in not necessary on the breakout PCB. You do need something at the bottom of the board so it doesn't get pushed down when inserting the cards. I use a .080" thick Acrylic sheet for the face of my panels with a slot that the SD card can be inserted into the breakout board slot. I drill holes for the switches and mask off an area for the display in the plastic then spray paint the back of it with black paint. After 2 or 3 days of drying, I then glue the panel onto the recessed wood opening with bathroom caulk. The only drawback is that the panel is shinny and can scratch plus show finger prints. Pete

Thanks for the kind words John. I know about fighting problems can drag you down. But look at what you have done so far. Its a great learning experience. I hope TK will help with including recording from the matrix keyboards. It may not be as simple as adding one statement in the matrix code since the change may spill into the SCS code. I don't know if this is the case since I haven't looked at that code functionality. I would think that a simple implementation would be just fine and just include all matrix I/O into the same option value that is defined for the DI/O option. Pete

John, I think I found your problem. It seems that in the midio_matrix.c file is missing a statement to record any IO from the Midio128 matrix functions. It needs "MID_FILE_Receive(DEFAULT, p);" at the end of the MIDIO_MATRIX_NotifyToggle() function. You will probably find that data from the Midi ports 1 & 2 are being recorded but not Matrix scanning info. You might ask TK to add this in the next release. Pete

John, Lets see whats in your recorded file. Why don't you connect your MidiBox up using the USB port to your PC. Make sure the MidiBox has the ".MID" ports set to play and record for your USB1 port. Start your MIOS_Studio.exe software and make sure its communicating by pressing the "Query" button. Select the file you recorded and start it playing. You should see the data in the file scrolling past in the MIDI IN: area in the upper left hand window. Is the file blank? Also know that you will see ALL NOTES OFF and RESET CC commands sent by the player when it is stopped. This could be your problem with stops being cleared. Something else that you will notice is that when you are in record mode, line 2 will show a STOP message along with a message showing which port and the data being recorded is coming from. Do you see this line 2 changing as your pushing keys while recording? And you will have to start recording then set your stops. How else are the stops going to be recorded in the Midi file. Pete

When you talk about the router, you are talking about the LPC core which has many Midi ports. All the data passes through the software in the LPC whether its routed data or data going to/from the recorder/player.

How are things going John. You talked about the Router but the options in the ".MID" area have nothing to do with the router functions at the LPC17. The ports that you are selecting with the "[x]" for the REC & PLAY fields relate directly to the port value being changed. If you select the DI/O port to REC, then the keys from your keyboards will be recorded. If you select MIDI1 to REC then you will record your swell shoe and Pistons. To play the data to your Sound Engine then you select MIDI2 to PLAY. These all can be changed and saved without affecting your router settings. There might be an issue if you are expecting the Router to modify your Midi channel values since the Midi recorder/player can't reference the values set at the router. Hope this helps. Pete

I think you are saying you can't find the play port of the Midi player. Here are the steps. Press MENU. Use the encoder dial and then select ".MID". Select "Ports" from this menu. Now select "PORT" from this new menu and the DI/O will start to flash. Now use the encoder dial to select your MIDI2 port. There is a REC & PLAY button that when pressed you can select the operation of the player/recorder. Hope this is what you are looking for. Edit-What version of Midi128 do you have. Maybe yours doesn't have this newer feature. Pete Knobloch

Hi Jay, Mios Studio is software that makes down loading software to your MidiBox core very easy. It also has some TOOLS that allow you to read and write the Din/Dout tables for the Midio128 V2 core. You will be changing the Din tables for your specific needs. When you get your Core hardware built your PIC processor from Smash/TV only has a bootloader in it, nothing else. You will use this utility to down load the Midio128 V2 software to your core. Go to http://www.ucapps.de/ and at the left side is a box labeled "MIOS". Below is a link to "Mios Studio", click on it and at the bottom of the "MIOS Studio 2" page you will fine the .zip file for loading to your PC. This software does a lot of things for may different projects but you will be just loading the software and changing Din tables with it. Don't worry about some stop switches being normally open or normally closed. You will define the output for when the stop is closed and opened on each Din wire. You will connect up your USB to Midi cable then run the Mios_Studio.exe file. There are instructions on how the application works.

It sounds like you have almost everything you need except the time which is being used for higher priority projects. I have that issue to. I would focus on building the V2 core and at least 1 DIN board and connect them up to your PC and use the MIOS Studio application to see how it works. Getting this done might excite you to complete the wiring to the keys. Building the boards won't take that much time, maybe 1 day, with a few days to understand the software configuration if you are new to these projects. Most of your time will be wiring the keys to the DIN boards. Don't be afraid of the unknown, just dig in and ask questions if you get stuck.

Hi Jim. To check on prices of boards at Smash TV go to http://mbhp.avishowtech.com/buy.html Information about Midio128 V3 can be found at http://ucapps.de/ You will have to buy the LPCXPRESSO board from Mouser. You will also need an SD-Card to store your configuration information on. It would be nice if it could be stored in memory like the old V2 hardware but that has not been implemented on the Verstion 3 hardware. Pete (Tempe AZ) Edit-Just noticed that Smash TV isn't supplying the parts kit for the LPC17 any more, just the raw boards. Was much nicer before this change. Seems like other kits have also been removed.

Hi Jay, I noticed nobody responded so I thought I would try. I am currently gutting a Conn 830 organ and installing Midi boards in it. In looking at your previous posts you indicated that the stop contacts were normally closed. I was wondering if you were really talking about the keyboard contacts here. My keyboards are almost identical to yours except that the rods are fixed in place and don't move. All of the contacts are normally OPEN and when the key is pressed they close. With the key in the rest position, the 6 contact wires rest on an insulated portion of the bus bar above. When you press the key, the wire whiskers push down and make connect to the conduction portion of the lower bus and close the circuit. Rotating your buss bars by 180 degrees would cause the key contacts to be normally closed like you said. I don't think you need new keyboards. In fact on my project I am wiring all 6 contact whiskers together for each key and grounding all of the buss bars so I will have less issues with dirty contacts. My organ was playing with the old analog electronics and the keys made scratching noises indicating they needed cleaning. Cleaning the contacts fixed this issue but I thought the problem would come back in time with the Midi conversion I am going to keep this from happening. Did you ever get your Smash TV boards assembled and try to test them out on the bench to see if you could get Midi messages to be sent when you grounded the inputs to your DIN board using the Midio128 V2 software?

I haven't changed out the hardware at Organ Stop Pizza yet since all of the .SEQ files need to be translated to .MID files. The plan is to just play the files on the MDF hardware and record it on the MidiBox. I also want to make sure that the file name sequence found of the SD card is the same that the organists are familiar with on the old hardware. You are right about Lew and Charlie being the very best at playing for OSP. And they are great to be working with. And thanks TK for your support and endless hours to provide such quality open source software. Its sometime hard to figure things out at first but as I understand more it becomes apparent why these things are done this way. Having so many modules being common between so many projects can be hard to juggle sometimes. I know my source code will become obsolete as new changes go in the system. It's good you are using a robust library control system for the source code (which I don't have a complete understanding of yet). Being able to retrieve a specific version of code is very important for projects like this. Something I should also add about this project: I removed some of the clearing functions that are sent over Midi when the playing file is stopped. It doesn't send any any ALL NOTES OFF for channels 8, 9, or 10 when going into PAUSE mode. The CC 123 0 sequence was clearing stops on the Devtronics organ hardware which was being used on a friends and my organ hardware. Of course this can be added back in by anyone who has issues with this by retrieving the old rev V3.019 of Midio128 and recompiling the changes in the seq.c file.