Sign in to follow this  
Followers 0
John_W._Couvillon

4x64 Switch Matrix on midio128

6 posts in this topic

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

Share this post


Link to post
Share on other sites

We're still working on it ;)

At this stage, we're still working on the scan matrix code that will scan up to 32 x 32 which could also be 64 x 16 ie 1024 switch points.  Our hope is that we can produce something that could scan a large console with second touch.  If we can get that working satisfactorily, we will start to think about configuration.  We will need to consider how much data can be stored and how we get it in efficiently.

It must necessarily be a different beast to midio128 because it will only scan inputs - the DOUTs are used to activate columns in the matrix. It should contain at least OnOff and Toggle functionality in some form. It is definitely NOT a case of rewriting midio128 for matrix scanning.

I'm currently trying to work my way through the perl script that converts the .ini file and understand where that data ends up in midio128 because we're also working on the custom Midio128FM (For Miditzer).  It may be that this might be useful research for the scan matrix (or not) or there may be other useful ways of processing configuration data that I don't know about yet.

So it is moving but only slowly with so much else happening atm.

Cheers

Graham

Share this post


Link to post
Share on other sites

Moonskin,

Would you be so kind to update us on where your project stands?  The topic is still very relevant to midification.

Thanks,

Johnc

Share this post


Link to post
Share on other sites

I am working with Moonskin on this project. I got to a point where I hit a wall on the code and needed to go back to square one but other projects had higher priority so this one is on hold until July. The basic idea, which is to rewrite the innermost scanning loop in a way that allows the matrix dimensions to be set dynamically , looks feasible. As you can imagine, there are a lot of counters and indices flying around and I have some error in keeping them all properly synchronized. Its the kind of code where I need a bit of uninterrupted time so I can keep a clear head while I sort everything out.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Sorry johnc I still have your other thread open in a tab but have been very busy. Will reply soon!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0