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):
-
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?
-
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
