Jump to content

John_W._Couvillon

Members
  • Posts

    350
  • Joined

  • Last visited

Everything posted by John_W._Couvillon

  1. Robin, What is the current status of your 16x16 matrix project? I have not been attentive to updates of the posts on this subject, but still have a 3 manual stack to midify, but am having no luck. The photo below will illustrate what my keyboards look like. They were originally in a matrix, but that part o of the original instrument was not liberated. Actually, each of the keyboards is set built for use in a matrix, as you can see from the blowup. As a last resort, I can use TK's 8x8 arrangement with one core per keyboard, but one 16 x 16 would do the trick with one. Would appreciate any help you might be inclined to offer. Jim Henry - If you read this post, any input you may have, built on your collaboration with TK on the same subject, would also be great! Thanks Johnc attachments - to follow - files to big
  2. ok Trevor Yes some stupidty showing, the Java app is for jOrgan. Can this be added on top of jOrgan, or does it go in one of the jorgan folders? Help me out here - how do i get from the printed text you posted to an app to load? Thanks, Johnc
  3. Trevor, Since your development is not mios based, what hardware is required to run the Java, a core running mios128, plus DINs and DOUTS? Can this additional core be daisy chained with encoders for keyboards, pedal, pistons, etc. This looks good! Johnc
  4. Hey Johnh, I have been away from the forum for some time, but am still very interested in your progress on the subject of this thread. Please email me so we can catch up. Johnc
  5. Johnh, I have been away from the forum for a while, but am still interested in the project we discussed sometime ago. Please email me so we can catch up. Thanks, Johnc
  6. Stryd_one, Yes, I found "Set_BSR MIDIO_BASE" and as I read the "apps_define.h", its located in register location 0x80. My question is what number is stored in register location 0x80, and which of the .inc files puts the number in the register, or does it matter. If the midio_base address is only used to calculate other banked register addresses, then it doesn't matter. Hey, sorry to be "thickheaded" on this, but would like to get it straight in my thick head. You said I could search the application files using "using grep or your IDE or similar" . What is "grep" and "IDE"? Thanks for your patience!!!! Johnc
  7. Questions; Is the default midi trigger table in "mios_mt_table.inc" overwritten with the configuration for DINs and Douts that are specified in the midio128 .ini file? All through the .inc files, the term "SET_BSR MIDIO_BASE" appears. Where is the value of MIDIO_BASE specified? Thanks, Johnc
  8. Lylehaze, Thanks for the input. Yes, I agree and for this project all of the 128 inputs and outputs will be needed. Just wanted to know if it was legal to do that. Evidently, from you reply, you have to go one way or the other, not both ways at the same time. I will look at the url ref. you provided. Hope you won't mind my asking some questions later. Thanks, Johnc
  9. Hey thats great! The fog is lifting. So I could write an app called "comb_action.inc" to do the capture/combination action functions, and put a hook in the main.inc program to get to it, eh? If I wanted to use one of the existing DIN or DOUT pins that are available on the pic as a dedicated I/O, is that permisable. One last question, Will mios run an app that utilizes only the DIN and DOUT pins on the pic with appropriate code, no shift registers, etc.? Thanks loads! Johnc
  10. Stryd_on, Thanks so much for the reply. Although I am not into "C", I can follow your answers and examples, I'm incouraged by what I read and am confident that What I am attempting to do, can be done. Personally, I have spent much more time reading, following and getting to know assembly and can work my way through the code pretty well. Mios is again another story. I guess that I have two problems, Understanding mios, how it is structured and what a complete application has to contain, and the detailed code to implement the app. I keep looking for the main block of code that dictates the program loop and keeps the cycle going. My conclusion is that the Main. inc is now where that takes place. Everything that happens is a spin off, sub routine, whatever from main.inc. As a start, I am looking to use midio128 with minimum change to the default, out of the box application. However, knowing that some of the code won't apply, to simplify things, why not just delete that part of the code. If the call to the routine, subroutine etc., is not there, then it won't be included in the program. Other reasons for staying with MIOS and midio128, is that there may be a need in the future to include other typical features found on a pipe organ console, and from my reading, the basic routines needed are already included in mios. Sorry about the duplicated posts, and the length therein. I am interested in your comments as well as those of TK concerning this application. Actually, I truly believe that a combination/capture action application using mios and midio128 could have as big an impact on use of midibox as the original app for the Orchestron (sp) that started the ball rolling with midio128. Existing commercial systems that perform the same functions start in the $5,000 to $10,000 range. Thanks again, and I look forward to your reply. Johnc
  11. Hello Jim, Thanks for the reply! I like your idea and will continue to look for more posts on the subject. Sitting next to me is a three manual stack that I intend to install in my console when something becomes available such as your project could produce. At the same time, I am working on a project to build a stand alone, capture/combination action using midibox and midio128, with some modification to the code, that would work with miditzer, jorgan whatever. As you well know, the only item remaining that prevents miditzer and jorgan from being fully functional organ relays is the ability to operate SAMS from a remote console. Hopefully, this project would bridge the gap. See my posts in the assembly programming section of the forum. I am proposing a standalone system, with the basic items to start off. "Set" piston, 10 pistons on three manuals, 5 pistons on pedal, and approx 20 SAMS per division plus couplers, etc.. No midi in or out is involved initially except the traditional contact on the SAM that is connected to the remote console keyboard encoders for use by miditzer or jOrgan. A second contact on each SAM (70 - 80 total)would tie in to DINS for the capture system core and I/O. DOUTS would include ULN2803 drivers for the on magnets on the SAMS ( core plus 4DIN and 4DOUT cards). All off magnets would be directly driven with 12vdc through the gen cancel piston, with a clean contact on the piston for input to miditzer and jOrgan. Following your lead, the system would be configurable using the .ini file to identify the stops and traditional config data.. I have chosen to stay with mios, etc. for obvious reasons, mainly available code, flexibility of mios, ability to transfer to the pic thru midi, etc. Unfortunately, I am a beginner with assembly but have learned alot. Taking a hint from many posts, my reading has increased ten fold, and It is becoming more evident that everything needed to do the code work is available, but I still have questions, which I have put on the forum. No answers, however? I had hoped that those users of midibox with knowledge of organ systems and assembly code would respond, but not so. Considering a basic system to start with, no adds (see comments at the end of the post): 1. Since there are no pots, encoders, or midi in or out, can the sections of code dealing with these be eliminated to simplify the code? 2. Where is the best point in the code to insert the code logic, just after the notify event, where a button has been toggled? Perhaps a call to a new .inc file that includes all the handling. program sequence : the set button interrupts the program, or starts the capture action, when the manual selection of stops is complete (moving tabs as desired), the appropriate piston is depressed (i.e. Great_1) this captures the stops. Basically, causes the DIN pin status to be read into the shift registers then shifted out what would be a 128 bit word, representing the captured stop arrangement. I don't think that its feasible to save the complete 128 bits as one word, so I propose to make 16 shifts, one register of 8 bits at a time, converting the 8bits to hex and storing in a table of some sort. So there would be 16 numbers stored for each "set" capture action. Recovery of the stored setting would be by depressing the piston. The program would recover the stored numbers, convert back to binary, set the bits in the output registers of the DOUTS, and when all 16 registers are set, enable the outputs. Looking at the DOUT shift register chip, the OE pin is held low on Smashtv DOUT cards. If the OE pin is held high, output is disabled until it is set low, so an unused output pin on the pic could be used to control all OE pins at one time, thereby moving the set shift register to change state, and output the settings to the ULN2803, and the magnet coils. Back to the table mentioned above. In terms of a matrix of rows and columns, the table would have a row for each piston and 16 columns, one for each shift register in the DIN. Actually, with one matrix of 16 columns, each piston is a general. Or there could be 6 matrices, one for each division with 10 rows and 3 columns each, or some combination of generals and divisionals. A future add could be to store the captured data in a bankstick and add multiple levels of memory. Also, adding midi in, miditzer or jOrgan could set the stops in the dout registers through midi message, and then enable the output to the magnets. Of course, the developed application would be free for all to use, including the code and would use basic midibox components, except for the minor change on the DOUT cards. In past days, months, years, questions posted on the forum, even dumb ones, received answers. Had that not happened, my use of midibox would have finished before it started. Would really appreciate someone to converse with. Especially your comments about the above. Thanks and best regards! Johnc
  12. Moonskin, Would you be so kind to update us on where your project stands? The topic is still very relevant to midification. Thanks, Johnc
  13. Anyone. If you are using DIN4x with 128 input pins. Will mios function MIOS_DIN_SRGet output a hex number that in binary form, represents the status of each of the 128 input pins? The intent is to read the status of 128 input pins and save in the form of a number which can be recalled, transferred to the dout SR register and output to devices. Output pin status to match original input pin status. Or, do you have to read the status of each DIN pin save to memory, then recall and set the Dout pin. Hardware would be: Input: 1 din pin called "set" 117 maintained contact, on/off switches, one per DIN pin. 10 momentary contact on/off switches. Output: 127 Magnet coil drivers, ULN2803 Program sequence: 1. "set" input starts cycle 2. 117 input maintained contact sw's are set in random pattern. 3. Program has 10 memory levels, each capable of storeing a hex number, which when retrieved from memory by one of the 10 momentary switches returns the stored switch pattern sets the appropriate pins in the dout and outputs to the receiving magnet coils. Each of the ten levels can have different arrangements stored. Perhaps there is a macro or code segment already written that can perform this function. Your help will be appreciated. Thanks, Johnc
  14. TK, Stryd_One, Having read through the wiki details I'm still confused about altering, changing, adding code. If an APP using midio128 does not deal with encoders, pots, etc. Is the applicatble code just deleted, Semi colon placed in front of the code lines, or what. I did notice that on some apps, VOID was at the beginning of some of the lines of code, but I assume that was just for example purposes. As a newbie to assembly code, it can be confusing, especially the more complicated code snipits. In my years of reading and posting on this forum, answers to questions have always been quick and thorough with sensitivity for those newbies that or short on background. Personally, I would rather be told, "go read this or that, dumbie" rather then no comment at all. Please don't leave those of us who struggle with the software behind in the dust. Midibox with all of its ramifications has opened up many, many opportunities for me to learn new things. I applaud your work TK and you to Stryd_one, and greatly appreciate what you have developed. Thanks again, Johnc
  15. Graham, Moonskin, Have either of you gone any further with your investigatiion of the 4x64 matrix and midio128? The idea of modifying midio128 to operate a matrix, whereby, configuration could be done via the ini file sounds great. Problem is that a 4x64 would cover two manuals and pedalboard, with 64-70 pins available for stops, pistons, swell shoe. What about a bit larger matrix say 8x64. Would it be possible to adjust the midio128 code such that the matrix size is set as part of the ini file? That would make the app usable for 2, 3, 4 manual consoles with all the bells and whistles as well. Going a bit farther, it would not be difficult to develop a dedicated "matrix" PCB with necessary parts of the basic core, LCD and space for the max DINs and DOUTS, as required for the largest matrix size. That way, the PCB and modified midio128 app could be a universal keyboard encoder usable by anyone and the whole thing would be on one PCB. Perhaps call the app "midiokey128" . My organ now has two cores daisy chained with 4 DINs on each and lots of wire to do a 2 manual, pedal, swell, limited number of stops and pistons, with lots of wire. The "midiokey128" would certainly simplify things and reduce the parts count considerably. Anyone with comments, please jump in! Johnc
  16. Good Morning and Merry Christmas! Stryd_on - All is cool in the deep south! Mellodramatic-Far from it! As a newbie, the simplicity of midibox is what attracted me. Organ Guys are for the most part non technical types interested in the final products ability to make their organs play. There are products out there that are much less sophisticated and much less flexible, yet they do the job and one doesn't need a soldering iron. The beauty of midibox is that the kits are much less expensive, immensely flexible and the tech support from users makes it all work. I well remember my first post on the forum spelling out what I wanted to do in midifying an organ console. Comments on the forum amounted to "you want to do what? we don't know anything about organs". Boy we have come a long way. Can't say how thrilled I was to hear from Per S, and Jim Henry, and many others that that wanted to do the same thing that I was doing. We collectively worked at the many problems, sharing solutiions, explaining details, educating and as a result there are numerous instruments playing and providing enjoyment to many. Stupid questions - TK must have had to bite his lip to keep from laughing. However, his help was always there, as it was from many. When the technical answers didn't cut through the fog, someone always rephrased it in plain terms to educate the dumb Heads. TK - thanks again for the midio128! Enough said! Merry Christmas to all, and Happy New Year! Johnc
  17. Hello Eric, There was a day, not long ago, when all questions, comments, suggestions, tips, were welcome on this forum, and the best help came from the user who was working his way through the process. Having been rebuked by the forum moderator, I will be a little less prone to put my two bits worth out there. However, Midiox is a super product that has served many, many over the years, and is still used by many. I must say that a 1% probablility of a problem using it is a pretty good reason to use it. I will also say that Thorston Klose is a super guy who has always been very, very supportive and patient with his help. One can't say enough about the quality of all of the midibox device designs, mios and all the apps programs. Midification has been my focus for several years, and my original cores running midio128 are still going strong. All the Best to you, and Merry Christmas! Johnc
  18. Esagmuller. You are overcomplicating the process. If you purchased the PIC with the bootloader and mios in place, then your are good to go. I have loaded midio128 and the ini file several times and use midiox as I find it to be the simplest. the procedure I follow is simple: Be sure that you have the latest version of midio128, corresponding to the latest version of mios. Make a note of where you have unzipped the midio128 files to. Look at the files and find the " Main" sysex file, It will have a small icon beside it. Be sure that you have a midi cable connected from the midi output device on the computer to the midi in connector on the core. If you have a cable connected fo the midi in connector on the core, remove it. Turn on the power to the core. 1. Load "midiox" and start the program. 2. Pick "Options" in the file menu, and select "midi devices". A window will come that will list the input and output midi devices. In this case you will be sending from the computer to the core so you need to highlight the midi output device you are using and then pick "OK" 3. On the "options" menu, be sure that there is a check by "pass sysex", if not checked, then check. 4. Pick the 5th icon from the left which will open the output monitor. 5. Click on "view", on the midiox menu at the top of the screen, then click on "sysex..." down on the list. This will bring up a window with title "SySex View and Scratchpad" which is divided into to sections, the top "command window" the bottom "Display Window" 6. on the "sysex view and Scratchpad" menu at the top of the window, pick "command window", and then from the list, "load file". this will bring up your different folders so that you can locate the midio128 sysex file. Navigate to the folder that has midio128 and locate the midio 128 sysex file, pick it and it should load. You should see the file in the command window. Now you are ready to send it to the core. 7. Pick the top blue band on the "SySex View and Scratchpad" and drag it off to the right, exposing the Monitor Output window. 8. On the "SySex View and Scratdhpad" top menu, pick "FILE" and then pick "send sysex file". 9. As you do this watch the Monitor Output window and you should see the file appear on the output window. If successful, midio128 should be loaded. Next step will be editing the .ini file which will configure midio128 for you. If you are successful with the above, email me and I'll take you through the .ini editing process. Johnc
  19. Trevor, Hey, your console looks to be in top condition. Did you re-finish it? My organ has 5 ranks of pipes running along with jOrgan and I don't experience any latency on the pipes or virtual pipes. Since my console is remote of the pipe chamber, it has 2 cores and 8 DIN's for keyboards, stops, swell, pistons. The jOrgan computer is in the pipe chamber about 30 feet from the console and operates with a cat5 cable carrying the midi messages. Its been running for 2 years without a hitch. As for sams, I have them on hand, but have not installed them since I plan to change out my console to a three manual. You should serioursly consider using at least a 16x16 matrix for the inputs since it cuts down tremendously on the midibox modules. The 2 encoder core can handle 128 outputs each, which would get you 124 SAMS. You would use some outputs for the encoder matrix, but you still should have plenty for SAMS. Recently, I took a long look at linux over xp, and I am encouraged at what I found. Seems like I got a 50% improvement in boot up time. Take a look at the posts from Graham Goode on the jOrgan users forum. He has done a terrific job on a package for installation of puppy linux and jOrgan. Good luck on your project Johnc
  20. Hi Bill, As mentioned by Per S, The midi dump that you got from Midiox should match your .ini file. I agree, you should re-check your .ini file. Seems strange to me that you would get such a mixed up list. A couple of suggestions: If your keyboard contacts are dirty and are not making good contact, you can get repeat messages, clean your contacts with a good solvent. Also, if the contact is not making at all, or your wiring is open, you will not get a message on the midiox dump. If midio128 is sending some of the messages accurately, then I would rule out mios and midio128. If the program was corrupt, you would not get anything. I would concentrate on the .ini file, keyboard contacts and wiring. Lastly, use the most recent apps software accross the board. mios, midio128, the current .ini file and start over. Good Luck! Johnc
  21. Hello Forum, Having scratched, dug, solicited advice on this subject, a very simple solution is availlable. the latest version of jOrgan, version 3.3 includes a very flexiible message system for defining I/O on the organ, and between jOrgan and remote midi decoders for driving pipes. It is now a simple task to accomplish in software what we were trying to do in paralleling the outputs of the uln2803. each ULN driver is dedicated to one magnet. Look up jOrgan its now a fully functional organ relay, including driving SAMS (new), multilevel memory, combination action, and fluidsynth. Thanks to all who responded with advice and input. jOrgan coupled with midibox technology is awsome! Johnc
  22. Shum, Thanks for the input. Sorry I am so slow responding. actually, there is a third solution which I think is the best. Ver. 3.3 of jOrgan which is a Shareware, Virtual Organ program, will accomplish the unification for you in software, whereby, you only need one ULN driver per magnet. In addition you can have a full multilevel memory, and combination action on top of that. Not only that, You can have one 8' octave of pipes linked to any number of ranks, all done with configuration of the software. thanks again, Johnc
  23. Robin. You seem to have some talent for modifying asm and C. Take a look at the thread in midification, with my name on it concerning custom modification of midio128 to drive SAMS. Johnc
  24. Stryd_one, Well my asm is non existant. I was hoping that one of you super programmer guys would jump in. Anybody out there interested? I know that there are several who have commented on asm questions and issues who probably have need for this application. As all may or may not know, There is a solution to the SAMS issue with jOrgan, however, for older SAMS that stick, or don't always function, this application will protect the magnets from burn out by providing a pulse rather then a continuous output. More info is available on the jOrgan Forum. Johnc
  25. Hello Forum Members: Question for you programmers in assembly or C: Would it be possible to re-configure midio128 for a dedicated setup (core and DOUT with ULN Drivers) such that the core programming responds to incoming noteon/off messages, produces a corresponding output on each pin of the DOUT, but applies a user configurable time out ( set in the ini file) after which it turns off the output. In otherwords, the output pin stays high for a adjustable time, regardless of how long it takes for the note off message to be received. Time out to be 10 seconds to 1 minute, or so. The custom programmed core and DOUT would be dedicated to driving SAMS magnets on the organ console which could be many more then 128. The output would be essentially a pulse which would cause the SAM to respond, but would prevent burning up the coil by prolonged activation. If This could be done leaving the input features of the midio128 intact so much the better. If however, the number of outputs can be increased beyond 128 by eliminating the 128 inputs, then that would be good, as it takes two outputs per SAM, so an organ with 100 SAMS would require 200 outputs. 256 outputs would be great. Johnc
×
×
  • Create New...