kpete

Hi all, Today I tried to checkout the Mios32 directory tree to my PC but got an error indicating that I couldn't connect. I was wondering if things are locked out for a while for a release or is it my system? The error I got in the window shows: Command: Checkout from svn://svnmios.midibox.org/mios32, revision HEAD, Fully recursive, Externals included Error: Unable to connect to a repository at URL 'svn://svnmios.midibox.org/mios32' Error: Can't connect to host 'svnmios.midibox.org': A connection attempt failed Error: because the connected party did not properly respond after a period of time, Error: or established connection failed because connected host has failed to respond. Completed!: I am doing this with a Windows 8 operating system.

Like TK said, your Midi File player is available in the Midio128 software. You being an electronics technician means you can build this yourself. Build an LPC Core, add an SD-Card plus a 2 line LCD with 6 buttons and encoder (SCS) and you have your player. As far as software, you have to load a boot loader into the LPC1769 module before connecting to your core hardware. Once this is done you download a pre-compiled HEX file called Midio128 into your hardware using the USB port. If everything was wired properly, you have your Midifile player. I should say that the player supports Midi Ch 1-16 which can be transmitted to all of the Midi ports if so configured. The data sent is the same for all ports. This means that the data for all your 2 drums, 2 instruments, and 2 for your space sounds have to be contained in channels 1 thru 16. Individual tracks being sent to separate ports is not supported.

The diode across the transistor shouldn't be needed.

You are absolutely right. 50ms is more than enough to change the SAM state. The 500ms time comes in because I asked for the SAM reed switch logic to be disconnected so they won't send the changes of the SAM's to jOrgan anymore. John indicated that there was a 500ms safe guard in jOrgan that would turn off a SAM magnet that might have been left ON. Wanted to use this to make sure the Dout chain was stable before worrying about the Matrix Din chain. And still haven't heard anything about if he might be using - common SAM's on the + common Dout boards. If this is the case, he could be having issues with magnetic cross talk between the SAM's. Pete

Forward code would be as simple as: MUTEX_SDCARD_TAKE; SEQ_PlayFileReq(1, 1); MUTEX_SDCARD_GIVE; Reverse code is similar but with a -1 in first parameter: MUTEX_SDCARD_TAKE; SEQ_PlayFileReq(-1, 1); // Move to previous file MUTEX_SDCARD_GIVE; I think this will work for the Play function. if( FILE_SDCardAvailable() ) { if(!SEQ_BPM_IsRunning() ) // If in STOP mode. SEQ_PlayStopButton(); } To do the PAUSE function just remove the ! (not) from the check. I don't remember what functions may have been declared as STATIC in the .c files but I changed them to suit my needs. At lease this shows you what functions I called to do these things. Hope this helps. Pete

Remove the Matrix board from the entire system and debug the Dout system first. Pete

I tried the 019 pre2.zip file and I as able to record a file on the Midio128 unit then move the SD card to the PC and play it thru the Windows 8.0 player. It reads the file with no problems. Something else that I noticed, before I even started any testing, my unit did have problems connecting via the USB interface. I had all 4 USB ports enabled and it had a release from about 2 months ago in the unit.. Now with the new 019 pre release 1 and 2, I haven't seen any problem with connecting MiosStudio with the MidiBox. I even tried copying a large directory from and to the SD card using the MSD function and it worked flawlessly. I don't know if its the MidiBox software or the Windows 8.0 that made thing work so well. Anyway, the changes look great and I would say its ready for a release. One happy camper here TK :smile: Thanks for the prompt response. Pete Knobloch (Tempe AZ)

Hi John, I haven't done anything with jOrgan at all. There are only so many ways these combination actions work and your responses is what I am keying off of for my responses. You indicated that nothing changed when you removed the Matrix board that senses the reed switches for the SAM's. I have to assume that the SAM's are still fluttering On and Off. Is this true? If it is true, do you still see On and Off messages from the LPC core for the non-existent Matrix board? It sounds like the combination action will work the SAM's even though the reed data is not being sent to jOrgan. This is good. This way you can make sure the magnets aren't interfering with the serial data going to the Dout shift registers. You might also look for conditions where the 2 coils of a SAM are being energized at the same time. This can also happen if noise is getting into the Dout SR chain. And I sure hope that after the second cycle of the 1/2 second period that all of the magnets are turned OFF. The magnets can get real hot if they are left on for a long period of time. Pete

Go ahead and debug your matrix wiring but I suspect your matrix hardware and wires are picking up the currents when the magnets are turned On or Off. If the matrix performs fine without activating the SAM magnets, then I would consider changing the input resistor values from 10k ohm down to something like 470 ohm. This will reduce the likelihood that the spicks will not be coupled into any of the open reeds. My direction would be to investigate the SAM output first by disconnecting the Matrix switches and proving that this side is working without problems. You may have problems in both Matrix sensing and the Dout shift register chain to the SAM magnets. Go ahead and add the 100nf (they are not uf.) but these are for small spikes. Your spikes are 1A per SAM and without measuring, I believe the current could decay in over 1-2us or more. And something that I am also wondering is do you know if ALL of the SAM's are the same type. Meaning were they bought as "Common -" or "Common +" SAM's.

Its been a short 2 weeks :smile: I tested the v3 019 pre1.zip and it does record and play back the SysEx data. I haven't tried it on the real hardware because the BOSS box is installed in the organ at work. Will do this but suspect it won't be any problem. Something that no one else has reported is that the files created on the Midio128 unit doesn't play on the Windows PC player. I also had problems opening the file on one of my CakeWalk utilities but this was some time ago when I tried. Should I open up a new thread or would you want to continue this here? Here are the files. REC1.MID won't read REC1mod.MID will work. This was run thru a utility that removes long blank pauses in the file. Funny thing is that it also allows Windows the understand the file and play it. These files were made some time ago on a keyboard with extremely dirty contacts as you can hear. Pete GoodAndBad.zip

Hi John, From an earlier PM message, you indicated that when you press the GC (General Cancel) button, that all the SAM's are being told to turn off, even if they are currently off. If this is the case, we might be able to use this for some of your debugging. Something that worries me (from previous PM) is that with all of the SAM's being told to turn OFF, you should only see OFF Midi messages coming from your SAM reed switches, but you are seeing some ON messages. I think this is part of the problem but not sure. Since the General Cancel button energizes the OFF magnets even if they are OFF, you might just remove your Matrix board from the mix by disconnecting it so the reed switches can't send the spurious ON messages which are muddying the waters. When I say remove, I mean totally remove the matrix board which is connected to the LPC core. Doing this you should not see any Midi traffic due to the matrix board. Now pressing the General Cancel button should still energize the OFF magnets. If all of the SAM's turn OFF and don't flutter, then you know that the problem noise is not getting into your DOUT chain. If they still flutter, check that there are no Midi messages from the non-existant matrix board. There may still be a problem because the DIN serial chain wire is still running thru the DOUT cables. With the LPC board running at 3.3 volts, that input will be much more sensitive to noise from the magnets. Something that you might also look into is the Matrix board input resistors. I don't remember if there are pull-up or pull-down but you might check if they are 10k ohm. If they are, you might want to reduce them so the induced current spikes will not be as bad. And I hope that these matrix reed switch wires are not bundled with your magnet wires. Pete PS - I don't think this information should be part of the MIDIO128 V3 thread. It should have a separate topic all its own.

I found some Midi Dump files for the BOSS drum machine and the block size including the F0 & F7 is 251 bytes in size. The header information for each block shows F0 41 09 52 12 . . . Much smaller than the 4k that MIGHT be available from your guesstimate. There must have been about 20 of these blocks. Pete.

I was afraid you were going to ask me this question. I wasn't sure if the entire SYSEX message needed to be formatted in one block or not. I will look into this when I go to work on Monday.

I have a project that needs to be able to record and playback SYSEX messages and I was thinking of using the MIDIO128 project software. What I want to do is connect the MidiBox to a BOSS drum machine and be able to do a SYSEX dump and record the programmed pattern to the SD card and later, play it back to reload the drum machine with the old pattern at a later time. While testing things on the MIDIO128 software, it seems like the SYSEX messages don't get recorded from the Midi ports. In looking at the code, it seems like this function hasn't been implemented. I suspect that its not included in the playback either. Would it be possible to have this added to the code as a future feature? I don't plan to have these SYSEX messages address the MidiBox parameters, just want the data passed to the selected Midi ports. Pete Knobloch

My guess what TK proposed is not going to be the final fix. It was just to see if it solved the problem. The three 220 ohm resistors in the transmit and receive sides are put in circuit so that plugging the wrong equipment into any of the Midi ports wouldn't destroy equipment at either end. The Midi spec indicates a 5ma current loop. This current is achieved by the 3-220 ohm resistors in the loop and the +5v supply voltage with an assumed voltage drop of 1.7v across the receiving opto-isolator. With a 5 volt source you get 5v-1.7v/3-220 ohms = 5ma. With only a 3.3v source from the LPC unit, this current is reduced to 3.3v-1.7v/3-220 ohms = 2.42ma which is less than half that it should work with. I believe that the 2 resistors on the Midi Out port should not be bypassed, but changed to a value of 47 ohms. This would give 3.3-1.7/(47+47+220) = 5.09ma. My opinion is that these 47 ohm resistors are a little lower than what I would want for protection but they still provide some protection and still gives enough current to meet the spec. We will wait and see what TK's final approach will be. Pete

I was just about to suggest this to. Running the Midi OUT with only 3.3v you would suspect that these 220 ohm resistors would need to be changed. I've questioned this for a year or more but nobody was reporting any issues. Edit: TK - on your calculations you forgot to subtract the forward voltage of the receiving diode which is 1.7v max at only 1.6ma. So the voltage is really 1.6 volts, not 3.3v.

I see what you mean Duggle. There is even one for 99 cents. From the picture it doesn't seem to use an inductor which worries me a bit. I see other units which have inductors at 10 units for $12.08 which looks great. Should work fine by adding 3 wires from the LM7805 mounting holes to the new step down regulator module.

The low dropout part is great but I don't have 6v to work with. The organ has a great 12v supply and I can also see where I might want to use it in other projects with even higher voltages, that if I change the 22000uf 15v capacitor to a higher voltage value. I'm not to worried about spending $4 more for a part that solves the heat issue using 12v or higher. I guess my question was also thinking about reliability. Maybe I will just buy 3-5 of these units and see how they work. I read that some people have problems when using them around RF transceiver (wireless) applications which I don't have around the equipment. Guess I will find out when I do further testing. Too bad I don't have a spectrum analyzer and antenna for testing.

Hi all, I built a LPC MidiBox core and wanted to power it from a +12v source. Problem being that the LM7805 dissipates so much power, it gets very hot, even with a heat sink. I was wondering if anyone has tried using a 811-2196-5-ND switching regulator as a substitute. At 90% efficiency it should run fairly cool, even at its 1.5amp output current limit. Here is a Link to the PDF. It costs $4.30 USD for 1 from DigiKey. I was also wondering if it might have problems with the switching noise getting into some of the analog circuits and create audible noise. I don't have this problem since my project is just digital in nature. But it might be a problem for others. Pete

The reason I indicated to use the OR gate was because I thought that the LED's turned ON when the shift register output went to 0 volts (active low). My mistake here. Pete

This could be done with some external IC's gates rather than software changes. From the Dout board, connect 4 of these outputs to the input of 4 "OR" gates. Then take the single BPM output (LED5) and connect it to each of the gate inputs. Now take the output of the 4 gates and connect them to the LED's with resistors. If you wanted to send Midi messages, just connect the gate outputs to 4 inputs of a Din board. Its not an elegant solution but should work as you described. Pete

Just looking at that PDF spec, I found a few mistakes. Wonder who is checking what they are publishing?

Another project you can start with might be the Midio128_V3 project at http://www.ucapps.de/midio128.html It is a complete project where as the one you found is a very basic player. You can find this software at this LINK. It has Midi router functions and can also record Midi Files. Not sure about the SYSEX support. I am using a modified version of the software for selecting voices on a synth that's connected to a Rogers 3 manual organ. Added feature is support of a Midi Player/Recorder.

I just went to my sandbox and did a make and this was what it did: C:\Users\Pete\Documents\MidiDesignProjects\Midio128V3\trunk\apps\examples\fastsc an_button_matrix_16x16>make rm -f project.hex Creating object file for app.c Creating object file for main.c Creating object file for strtol.c Creating object file for tasks.c Creating object file for list.c Creating object file for queue.c Creating object file for timers.c Creating object file for port.c Creating object file for umm_malloc.c Creating object file for startup_LPC17xx.c Creating object file for mios32_srio.c Creating object file for mios32_din.c Creating object file for mios32_dout.c Creating object file for mios32_enc.c Creating object file for mios32_lcd.c Creating object file for mios32_midi.c Creating object file for mios32_osc.c Creating object file for mios32_com.c Creating object file for mios32_uart_midi.c Creating object file for mios32_iic_midi.c Creating object file for mios32_iic_bs.c Creating object file for mios32_mf.c Creating object file for mios32_sdcard.c Creating object file for mios32_enc28j60.c Creating object file for mios32_bsl.c Creating object file for mios32_sys.c Creating object file for mios32_irq.c Creating object file for mios32_spi.c Creating object file for mios32_i2s.c Creating object file for mios32_board.c Creating object file for mios32_timer.c Creating object file for mios32_stopwatch.c Creating object file for mios32_delay.c Creating object file for mios32_ain.c Creating object file for mios32_usb.c Creating object file for mios32_usb_midi.c Creating object file for mios32_usb_com.c Creating object file for mios32_uart.c Creating object file for mios32_iic.c Creating object file for printf-stdarg.c Creating object file for core_cm3.c Creating object file for usbhw_lpc.c Creating object file for usbcontrol.c Creating object file for usbstdreq.c Creating object file for usbinit.c Creating object file for app_lcd.c Creating object file for glcd_font_big.c Creating object file for glcd_font_small.c Creating object file for glcd_font_normal.c Creating object file for glcd_font_knob_icons.c Creating object file for glcd_font_meter_icons_h.c Creating object file for glcd_font_meter_icons_v.c Creating object file for mini_cpp.cpp Creating object file for freertos_heap.cpp ------------------------------------------------------------------------------- Application successfully built for: Processor: LPC1769 Family: LPC17xx Board: MBHP_CORE_LPC17 LCD: universal ------------------------------------------------------------------------------- arm-none-eabi-size project_build/project.elf text data bss dec hex filename 41190 32 13752 54974 d6be project_build/project.elf 10000000 B __ram_start 10000db8 ? __ram_end 2007c000 D __ram_start_ahb 2007e920 B __ram_end_ahb C:\Users\Pete\Documents\MidiDesignProjects\Midio128V3\trunk\apps\examples\fastsc an_button_matrix_16x16> ____________________________________________________________________________ My sandbox was made from a version about 2 months ago (I think). What I think your problem is that you have a very old sandbox with old software that's not compatible with how things are done today. It may also be because of other tools you have loaded which conflict with the MidiBox tools. What I suggest is for you to create a new TRUNK that is at the current level of revision of the repository. When validate your toolchain and environment is properly setup. This is the link I used for WINDOWS http://www.midibox.org/dokuwiki/doku.php?id=windows_mios32_toolchain_core Only merge your changes into the directory after you verified you can compile the current version in your sandbox. I don't know what else to tell you. Maybe someone else should get involved here. Pete

Do you have all the environment variables set on your system right before you do the make? There should be one that reads "MIOS_32_LCD=universal". It looks like you have it set to "clcd" which is a directory that I can't find in the repository. Pete