jmayes

Can someone point me to a good NG example script I can look at that receives midi and outputs to the DIO? Thankx again all, J

Hi, after reviewing the NG documents I am sure it will do what I need but it looks like most of the examples deal with matrix buttons and matrix LED's. Is there a ngc example file I can look at that uses the midi 'receive' command (for input) and the 'srio' (DIO for output). If there is an example like that it will save me alot of trial and error. I have ordered the parts and can't wait to get started. Thankx again, Jmayes

First off thank you Thorsten for the fast reply and the solution to my issue, I will read up and follow that route- 16 levels is more then enough considering the mechanical issues that kpete detailed so well. I have the pianocorder that uses the floppy disk and already has midi input (and output). The 1/2 second delay they add was put there exactly because of the mechanical issues of hammer strike times. While this is fine for canned midi music I need to be able to link the piano to my organ for live performance and I must kill the 1/2 second for that to happen. Most likely I will have to play at full velocity but still want to play around with some dynamics. I expect to have both the old and new host wired together so I can pick the best interface depending on what I am doing (canned midi most likely will be fed via the 1/2 second delay). I looked at getting the newer pianocorder host controller boards but they changed the driver addressing so radically it would not work unless I changed the driver boards too so hot-wiring the midibox to the drivers will be much easier. Will report back once things are wired and let you know how it works. Thankx again all, Jmayes

Has anyone tried to use midibox on a real piano? I know it's a no brainier to wire to solenoids but what about dynamic key response? I recently acquired an older Yahama with built in pianocorder and wish to replace the host controller with midibox. It works good as-is but has a 1/2 second delay which is intolerable, you can not hook a remote keyboard to it and play it live. Newer models allowed this "Feature" to be turned off but mine does not, I have dug deep into the circuits to try to trick it out but it comes down to the firmware in the host controller, the software must be reverse engineered and modified. My main expertise is hardware and wiring midibox to the existing drivers would be much easier for me but i will loose dynamic response which brings me to the question above. The drivers require pwm outputs from the host to set the strike pressure, so the velocity of the midi notes needs to be translated and turned to pwm for each pin output. Has it been done? I tried a quick search without luck so far. This feature would also be neat for driving LEDs as you could get variable brightness from them. Any help would be greatly appreciated, Jmayes

Thank you again for the help TK, I am sending another beer right now! I'm not sure if I need the endpoint though, my setup goes ( Computer-midi-out > core32 > core8 > computer-midi-in ). Will try it out soon! Very close to publishing the whole rig now. Thankx again, Jmayes

Hi, Thank you TK. At least I know I did not miss something, I spent hours looking for it. At this point the Core32 is sharing a midi line with a regular core8 which I have turned on full forwarding. I can access the core32 in that config but not the core8 board. I really need them to be on the same string as the core8 adds the stops and swell pedal to the keynotes the core32 generates, that way both are on the same port which is tidy for my sequencer. I have the core32 selectively forwarding the midi info I need, I just need it to forward the midilink info too. I don't plan on more core32's but there may by additional core8's but I can set the proper modes on them. Thankx again, Jmayes

Basically I am looking for an equivalent to MIOS_MIDI_MergerSet(3) or some example code to do the same. (midibox link forwarder) I keep searching but can't seem to find anything, Thankx for any help someone can provide, Jmayes

I can't seem to find the function to allow the mios to forward midibox link info (when in a chain). I do not want to forward regular midi. Can someone help please :) Thankx agian, Jmayes

Hi ilmenator; I work on large matrix switcher for broadcast use, one type is a 32x32 which I happen to have an extra back plane for, it contains 4 AD8113 16x16 chips in a 2x2 configuration (which makes 32x32). They are serially driven so the SRIO driver would drive them. I will give it to you if you pay shipping. The chips at Digikey are a cool $50 each. It should not be too hard to reverse this board and use it. info and datasheet here; http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=ad8113 Some pix; There are way more pins on the edge of the board then are used because they were designed to be stacked up to a 32x32x4 matrix and all the extra wires flow through the modules under them. if you want it just pm me, Good luck on your project! Jmayes

Hi, I see that many are making LED displays using Midi-box, this chip looks like it could save alot of time! Just FYI http://www.allegromicro.com/en/Products/Part_Numbers/6282/index.asp Good luck on your projects! Jmayes

I have an app that needs to access a buss with 1us response time. To complicate things it must do it at 12v. The UDN2892 works but has a 2us delay from 1>0. Really I need a ULN2803 (NPN) and the UDN2982 (PNP) in the same package (or mosfet equiv). After lots of googling I come up goose eggs :( Any help will be appreciated! Jmayes

Got it installed in the organ with a few (minor)issues, one hardware (more on that later) and one software. TK, is there anyway I could get you to add de-bounce to the din handler? Turns out that at this ultra-fast update cycle I am getting lots of extra traffic on the midi. I think 3-4 din handler scans before triggering would be about right. Attached is my (almost finished app). I have added midi key offset and mux/midi correction so that din's and dout's are on the same mux level and at the right octave. Overall I am very excited, not far to go now!! Here are a few pix of how the project is coming. Thankx again for the help! Jmayes Rodgers-App2.3a.zip

Yes, that is exactly what I am doing, each mux level has it's own midi channel. Thankx again for all your help! Jmayes

Hey TK, While I got this working (with your help), I still don't understand exactly why all the config statements are needed (or how they work). Could you give a statement by statement explanation of how this works? I know it would help me greatly and I am sure other nubies too. Thankx again for all your help! Jmayes

..

Solved!!! Everything is fully up at running at 12.5us In the new Din Handler the way the pin was calculated was wrong; Was: u32 pin = MIOS32_SRIO_NUM_SR*8*mux + 8*sr + sr_pin; Now: u32 pin = 8*sr + sr_pin; That made it all good :) Once I polish the app a little more I plan on starting a new thread in midification with full details on how to implement this. Thankx again TK, your the greatest! Jmayes

Ok, we are so close now I can taste it! (or at least drink it...) Corrected! I am getting DIN's now but with some strangeness. When I press pin-0, Mux-0 I get pin 40, pin-0 on mux-1 gives nothing (out of range?), mux-2 gives C0 and Mux-3 gives 00 (correct). I had to add the mux var to APP_DIN_NotifyToggle in order to pass it from your din handler. Dout is perfect! Time has gone up to 12.5us but that is fine, no need to optimize further. Oh, Ya I did not even see you put an IF around my (test) using J5-11, that fixed it (Duh!) Here's the app as it stands now. Thankx again! Jmayes Rodgers-App2.1a.zip

TK, YOU ARE THE MAN!!! This is exactly what I needed, I will buy you 2 bears- heck a keg if there is an option! Just a few minor things, I was able to get dout working but the din handler does not seem to be scanning. I don't think it's being called at all. Also that part where you did not optimize where it looked like a test is really needed, J5-11(input) changes it from mode1 to mode2 where the keyboards will be separated from the organ generators. (For some reason J5-11 input is not working). I also use J5-8 output which I am going to use for hardware blanking of the dout so when I send midi it won't loop back on the din's. Here is my (almost final) app Thankx again! Jmayes Rodgers-App2.zip

Looks like we were posting at the same time! I will look over what you have, that optimized spi.c might be just the extra I need. The reason I have to scan so fast is that the organ generator system multiplex's all 4 divisions on a single 61 note bus (time division). Since the keyers are analog if the single division mux pulse is slower then 12us it translates to something that can be heard (Hi pitch) when keys are played. They choose 10us which turns out to be barely under perfect. (hear-able pitch is above 20khz). I could slow it down and put a bunch of caps on all the generator outputs to snub freqs over 18k (or 16k) but that will lead to alot of extra work on the organ. My goal is to be able to do the upgrade with the least amount of mods to the organ itself. I am real close now, it's all working with about a 18k squeal (which I personally can not hear). Going to start going over what you sent. Thankx again! Jeff

That will be really great! Looks like I am hitting a wall now. Pre-8 is the smallest I can use before the hardware chain fails, I am using strong-outputs and the buffer you suggested as well as terminators at the end of the chain. Also I did some scoping and my din handler which takes 700us at pre-16 ends up taking 1500us at pre-4 so no wonder things were getting mucked up as multiple threads were overlapping. Sitting at 20us now, almost usable. It creates a high pitch whistle on the organ that only my young nephew can hear. Thankx again! Jmayes

Solved!!! Turns out the 800us I was triggering my custom DIN handler routine became too short (and caused overlaps) after I added the instructions for the extra pins I needed. Changing to 1ms has fixed all! Still can't explain why it caused a dout problem but at least I know what did it and can move on. I still need some help knocking the dead space down between SRIO scans if someone can help. Thankx again, Jmayes

Thank you TK for taking a look at this for me!!! Here are the only files that I have changed from the "Traditional" mios32 model, I have marked //JM on most lines That I have added or changed. This file set runs exactly correct on the J5 pins w/din and dout at pre-16 but when you change it to 8 the dout stops. Your comment leads me to believe that it is the midi in routine on uart0 what is failing, that would explain why I loose download ability too. (I do not use USB) Program description: Basically I have made all din and dout buffers 2 dimensional using the "muxctr" and "level" vars. I did also modify all the debounce and din handler code but now am not using it as I have added a new Din handler to the app.c using the user-timer to trigger it every 800us. Each scan is at a different mux level that repeats after 4. This allows for 3 manuals + Pedals (4 levels). Midi is input and output in 4 sequential channels starting at ch1 on uart0 (Midi port 1) I do not use USB at all, we can disable it if it will help. The biggest issue (other then the J5 pin weirdness) is the 7us before the SRIO scan and the 3us afterward. If I could reduce that, then I could run at a 16 pre-scalier. See 17us-scan1.jpg, note I took that shot with the pre-scalier at 8. Thankx again for looking over this for me, Any suggestions will be appreciated! Jmayes V13-outfile.zip

Have you ever seen the light at the end of a tunnel and just can't quite get to the end? I am almost there with my project but still there is one last road block (I hope the last one). Ok, on my quest to scan the buss on my Rodgers organ which must be done every 10us I have moved to the Core32, I have put the SRIO scanning into a tight loop so that the SR_Finish directly restarts the SRIO_SCAN. I use several mux pins (GPIO) that output between scan cycles. There are 4 scan cycles then it repeats. I have this working with J5A perfectly all the way to a pre-scalier of 8 which is getting my cycle time down to 17us. The final thing I needed to do is to add some additional GPIO outputs (4 more) in order to trigger the tone generators separately from the keyboards. Just a slight variation of what J5A pins are already doing. Now the weirdness, once I started using J5B pins I get no Dout. The scanning is working fine but there is just no data going to the SR's. Additionally when it does this the midi port will no longer allow MIOS studio to query it and I can't download without cycling power and letting the bootloader take over. Din is still working, the J5 pins (all 8 of them) are working as expected but there is just no Dout. I spent many hours putting rem statements in front of my code to see what was causing this. It came down to I can use EITHER the 4 pins of J5A OR 4 pins of J5B but NOT BOTH!! I could not find anything at all in my program that seemed wrong. Finally I changed the pre-scalier to 16 and boom, everything is working perfect (but 28us is too slow for my app). That proves to me that my code is ok. I was really hoping to eventually go to a pre-scalier of 4 in the final rev. (takes me to 12.5us cycle) I was using the OD option and 1k pull up resistors, along the way I tried the PP and no resistors and got the Dout to work some with all 8 pins but it was delayed??? It took like around 3-4 ms from when I sent midi to when the Dout would output, all I had to do is rem out J5A pins or J5B pins and it would start working perfectly again??? Also I am using a scope to monitor the Dout to the SR's to confirm there is no data outputting. I am using buffers on the clock, latch and data and I do have din and dout working down to pre-scalier 4 just not with 8 J5 pins. I will attempt to use J19 pins to get around this but I thought perhaps TK or another expert user might be able to put some light into my problem. I AM SO CLOSE! Here is the code In question, I put it in MIOS32_SRIO.C ........................... static void MIOS32_SRIO_DMA_Callback(void) { // notify that new values have been transfered srio_values_transfered = 1; MIOS32_BOARD_J5_PinSet(muxctr , 0); //jm organ muxpin off (J5A) MIOS32_BOARD_J5_PinSet(muxctr + 4 , 1); //jm keyboard mux pin on (J5B) //latch DOUT registers by pulsing RCLK: 1->0->1 MIOS32_SPI_RC_PinSet(MIOS32_SRIO_SPI, MIOS32_SRIO_SPI_RC_PIN, 0); // spi, rc_pin, pin_value //MIOS32_DELAY_Wait_uS(1); MIOS32_SPI_RC_PinSet(MIOS32_SRIO_SPI, MIOS32_SRIO_SPI_RC_PIN, 1); // spi, rc_pin, pin_value MIOS32_BOARD_J5_PinSet(muxctr + 4 , 0); //jm keyboard mux pin off (J5B) //JM Mux counter if ( ++muxctr >= 4 ) { muxctr = 0; } //mux pin on MIOS32_BOARD_J5_PinSet(muxctr , 1); //jm organ mux pin on (J5A) ................. Here are my MIOS32_Config.h def's #define MIOS32_DONT_SERVICE_SRIO_SCAN 1 //jm #define MIOS32_SRIO_NUM_SR 8 //jm #define MIOS32_DONT_USE_ENC 0 //jm #define MIOS32_DONT_USE_DIN 0 //jm #define MIOS32_DONT_USE_AIN 0 //jm #define MIOS32_DONT_USE_COM 0 //jm #define MIOS32_SRIO_OUTPUTS_OD 0 //jm Thankx again for any help someone can provide, Jmayes

I have my app working fully but it is still not fast enough. I am triggering the SRIO_start with the user_timer and I found that changing the prescalier value in the SRIO.C module would speed up the transfer to around 15us. Anything faster and the 5v pullups would fail. Now my biggest problem is processing the data after the xfer is too slow which at present is 150us. I also found that adding my code to the SRIO.C was way faster then in app.c so I am also doing that. Now I think I need to process data as the SRIO shift reg's are updating (in the same routine) in order to get to the next faster plateau?? Questions? Exactly where is the low level SRIO xfer code? Is there a better way? After more testing I found I can go as slow as 25us (including scan) and still achieve my goal. Thankx again for any help someone can provide, Jmayes

Ok, I have my Core32 tested and have my app (mostly) converted. I think I can figure out how to use the user-timer to trigger the transfers but can't quite wrap my head around the DMA thing. Would it be possible to get some more info or some example code? Thankx again for the help, Jmayes