jimhenry

Diode Matrix Input

52 posts in this topic

Hi Jim,

I conclude that for the moment you are just computing a Note Message based on the pin number?

yes - I tried to keep this example simple, so that it's easier for you to get an oversight over this driver.

Were you planning on going that far or do you want to hand that off to John or myself?  Would it be of help if I were to create midio_presets.inc type tables for the configurations that will be supported initially?

it would be a big help for me and a good starting point for you. I assume that you want to add much more features in the future, therefore it makes sense that somebody else begins with the table integration (nice exercise) and enhances his code step by step.

The SM_NotifyToggle is a hook which can also be placed into another include file where the MIDI routine starts. The table entry can be calculated from SM_BUTTON_COLUMN and SM_BUTTON_ROW

What configurations will be offered initially?  8x8 and 32x16 presumably.  Anything else?  (Terminology wise should we refer to DINxDOUT or DOUTxDIN for the matrix configuration?)

I will create another example for 16x32 (DOUTxDIN sounds better: "16 times 32 inputs"), everything else only on request.

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Hi Jim,

this will work. Now you can address each entry from the SM_NotifyToggle hook in the following way:

SM_NotifyToggle
        ;; calculate address to table entry

        ;; set TBLPTR[LH] to base address
        TABLE_ADDR MIDIO_Presets_OffsetOut

        ;; add offset: 6 * 8 * column
        movf    SM_BUTTON_COLUMN, W
        mullw   6 * 8
        movf    PRODL, W
        addwf   TBLPTRL, F
        movf    PRODH, W
        addwfc  TBLPTRH, F

        ;; add offset: 6 * row
        addwf   SM_BUTTON_ROW, W
        mullw   6
        movf    PRODL, W
        addwf   TBLPTRL, F
        movf    PRODH, W
        addwfc  TBLPTRH, F

        ;; if button released, add 3
        IFCLR   MIOS_PARAMETER2, 0, rgoto SM_NotifyToggle_Pressed
SM_NotifyToggle_Released
        movlw   3
        addwf   TBLPTRL, F
        movlw   0x00
        addwfc  TBLPRTH, F
SM_NotifyToggle_Pressed

        ;; copy 3-byte entry to MIDI_EVNT*
        tblrd*+
        movff   TABLAT, MIDI_EVNT0
        tblrd*+
        movff   TABLAT, MIDI_EVNT1
        tblrd*+
        movff   TABLAT, MIDI_EVNT_VALUE

        ;; send MIDI event and exit
        goto    MIDI_EVNT_Send

I hope that the assembler passes and that this routine works - I haven't tried it

Since the offset is calculated step by step and 8-bit overflows are avoided, more than 256 entries are possible

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

I have the MIDI message table working to a point where I could use some guidance. Consider this code that I am using:

    ;; copy 3-byte entry to MIDI_EVNT* 
    tblrd*+ 
    movff   TABLAT, MIDI_EVNT0 
    tblrd*+ 
    movff   TABLAT, MIDI_EVNT1 
    tblrd*+ 
    movff   TABLAT, MIDI_EVNT_VALUE 

      movlw      0x9f
      movwf      MIDI_EVNT0

    ;; send MIDI event and exit 
    call    MIDI_EVNT_Send 

First, it seems that a call rather than a goto is needed for MIDI_EVNT_Send. Does that look right?

Where I am really stumped is that something seems to go wrong with setting MIDI_EVNT0 from the table.  If I add the two lines just before the call to force the value into MIDI_EVNT0, then MIDI messages are produced as expected.  Without those two lines there is no MIDI output.  I am baffled as to how the load of MIDI_EVNT0 from the table could be preventing MIDI output.  What can I do to figure this out?

I notice that a flag is set to produce LCD output to show what input point is closed but there is no display support and a message is given on the LCD that there is no realtime display.  I tried grafting in the display from MIDIO128 but it seemed like that interferes with the input somehow.  Is there some reason why this example can't support a realtime display?  Or do I just need to try harder?

Share this post


Link to post
Share on other sites

Hi Jim,

if the branch to MIDI_EVNT_Send is at the end of your function, the you should either use the "goto", or a "call" (like now) and thereafter a return. Don't forget the return or goto, otherwise undefined code (or the function below) could be executed at the end

To the MIDI_EVNT0 problem: I noticed that the eight bit of the first byte is always masked out in the MIDIO_OUT_ENTRY macro (...(event_on_0)&0x7f...). This has some special reasons, but they don't matter in your case.

You've two possibilities:

1) change the macro:

MIDIO_OUT_ENTRY MACRO event_on_0, event_on_1, event_on_2, event_off_0, event_off_1, event_off_2
        db      event_on_0, event_on_1, event_on_2, event_off_0, event_off_1, event_off_2
        ENDM
2) or set the eighth bit before this value will be sent out:
        bsf     MIDI_EVNT0, 7    ;; set 8th bit (indicates a status byte)

The reason why sm_example2 doesn't support the LCD is just that I wanted to achieve the highest performance. A display update on every button change would cost ca. 200-300 uS, it depends on your display and the number of characters... The DISPLAY_UPDATE_REQ flag is just a good method to prevent additional updates if some buttons are pressed at the same time (only the last button change will be visible on screen). There are methods to save performance (e.g. printing out one character only on every display tick), but I wanted to make this example so uncomplicated as possible ;-)

You could copy&paste "USER_DISPLAY_Init" and "USER_DISPLAY_Tick" of the sm_example1 for debugging

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

It is confirmed that setting the MSB before sending the event solves the MIDI_EVNT0 problem. I left the MSB clear in the table so that the table can be written with a SysEx in the future if desired. I should have read the comments more carefully.  :-[

Share this post


Link to post
Share on other sites

My compliments to you Thorsten. The MIDIbox and MIOS are absolutely brilliant! ;D The more I learn about them, the more impressed I am.

The Switch Matrix application is coming together beautifully. I now have an 8x8 matrix, table driven, supporting on/off events and push button events. Does anyone have a need for toggle events?

I have the display showing the last button change and the MIDI message sent in response. I think those displays should be always available because with a large number of switch inputs, the ability to see what the MIDIbox is receiving as input is almost essential. It is also extraordinarily helpful to immediately see what MIDI message is sent in response to a button change to verify the table setup.

To minimize the load on the processor from the display, I put the display in USER_Timer and added a counter so the display is only looked at once every 256 mSec. There is sometimes a just noticeable lag between a button change and a display.  My thought is that the display is primarily for "static" testing and does not need to be realtime. Does anyone see any problems with this approach?

If no one sees any shortcomings with what I have described, I'll clean up the code and make it available for others to test.

Share this post


Link to post
Share on other sites

Thanks Jim! Nice to hear that programming MIOS makes fun :)

Some words to USER_Timer: this is an interrupt service routine, which means that it breaks your main program. Therefore you've to take care that the LCD driver doesn't use the same resources (data registers, IO ports) like the routines which are called from USER_Tick or similar. This would be the case if a BankStick is connected, or an extension like the AOUT module (connected to J10)

Another problem is, that an "ISR" has to be processed within ca. 300-600 uS, otherwise it could happen that an incoming MIDI byte gets lost (the MIDI In driver cannot interrupt another ISR).

Therefore I would suggest to use the timer only for setting a flag which requests a display update. The display output itself can still be handled from the USER_DISPLAY_Tick hook.

Best solution:

SM_Notify_Toggle sets DISPLAY_UPDATE_REQ,0 (bit #0) on a button change

USER_Timer: sets bit #1 if bit #0 is set and thereafter clears bit #0

USER_DISPLAY_Tick: prints the button message if bit #1 set and thereafter clears bit #1

An additional possibility to minimize the latency would be the print only a small number of characters (all others which never change could be print from USER_DISPLAY_Init)

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

I really must learn to slow down and read the comments.  :-[

Yes, of course putting the display code in USER_Timer is a bad idea. Thank you for saying it so nicely. I have now organized things so that USER_Timer sets a flag to hold off a display update for 256 mSec after the previous update.

Share this post


Link to post
Share on other sites

Hello everyone!

I'm in the process of modifying and (not least) midifying an old Rodgers Trio 321 and for some time I've put some thought into what I would like to do. Consequently, I have somewhat started a "midibox project" myself, but as it's always more easy and fun to cooperate with others, I wanted to give a project of this size and quality a chanse.

One of my objectives is to make non-destructive modifications, as the organ itself isn't bad at all and very well possible to improve even more. The non-destructiveness applies even to the midification.

This makes me somewhat hesitating as to using the MidiBox for the project. If I understand it correctly after having read this thread, the principle of choice for the keyboard scanning is the matrix principle. I may have some kind of objection to this (sorry!) One of my reasons not to choose this principle is that if I want to midify in a non-destructive way, the easiest way of connecting the keyboards (the busbar type) is to use the existing signalling and contacts. To connect them to a number of shift registers, possibly one series for each keyboard (4 in total, or 5 if the stop rail is considered as well) to improve on scanning speed would be less messy to construct. All that is needed is some pruning of the input voltage to suit the shift registers (likely zener diodes).

If, on the other hand, a scanning matrix is used I either have to discard the original keying and by that disabling the organ as-is or make some quite messy electronic switching in the matrix. If I remember correctly I've got some 25V as keying voltage in the keyboards. What I'll have to do is to install a number of either switch ICs with the same kind of voltage pruning as for the shift registers, but use a more complicated sheme.

Now... Please correct me, if I'm misstaken or someone has got some clever ideas on this!

Greetings,

organearl

Share this post


Link to post
Share on other sites

I also have a Rodgers Trio 322.  My original plan was to MIDIfy the Rodgers but then I came into two Wurlitzer consoles.  My Rodgers has had ongoing contact problems and I can't even begin to contemplate MIDIfication of the Rodgers until those are resolved.

What I had planned on for the Rodgers was to tie the Vcc of the 5 volt MIDI logic to the positive keying voltage.  I would use a negative 5 volt regulator to create the ground for the MIDI logic.  This would allow the keying voltage to pullup the logic input to positive.  I forget what the plan was as far as pulling down.

None of this has been tried.  Before you do anything else, you need to build a small test circuit and verify that you can get logic out without disturbing the Rodgers keying circuit.  As I recall there are two or three different circuit configurations used.  Probably different between the Solo voices and the Tibias.  There may also be something different on the Pedal keying.  I never got to the point of considering the Stop circuits.

I do recall reading something recently that mentioned that Rodgers MIDIfication tends to affect the sound of the orginal tone generators.  You need to be very careful that you sense the inputs without disturbing the orginal tone generators.

Now that I have gotten involved with the MIDIbox, I think my first choice for the input logic would be the 74165 shift register of the DI board.  If the above scheme will allow you to connect the inputs of the '165 to the Rodgers, then MIDIbox will give you what you need to turn those inputs into MIDI messages.

I haven't gotten to the point of expanding the switch matrix beyond the 64 inputs that Thorsten did as a demo of the concept, but Thorsten thinks it could be expanded to 1,024 inputs.  If MIDIbox can handle that many inputs for switch matrix, then it probably can handle more than 128 inputs via a straight shift register chain.  But it probably is less work to just use 2 or 3 MIDIO128s chained together if you don't mind a little bit more hardware since you won't need to do any programming.

Share this post


Link to post
Share on other sites

I also have a Trio which I have midified using the standard MIDIO128. So far I have only the Solo manual hooked up and I have been using a sampler to get some percussion voices. The keying voltage on the Solo and Great is +12V and I used a simple resistor dividers to get to +5v. There is no interference with the tone generators since the keying voltage is only gating the signal. To midify the Acc and Pedal a more sofisticated method has to be used. The Acc keying voltage is normally about +6V and goes up to 12V when Acc ff stop is on. The Pedal keying voltage is 4V and goes up to 7V when Pedal ff is on. The idea with zeners should work I guess.

The Stop keys are a different story since most of them operate by grounding one end of a relay, 12V on the other end.

I'm seriously considering remove the entire Rodgers circuitry. I has served me well for 30 years but now it's time to move on.

Per S

Share this post


Link to post
Share on other sites

I'll  do my homework a little better... I've got the schematics for the Trio, but this far I've only had a little time to really work it through. The 25V I wrote about was from memory and from a measurement on the fly I made of curiosity.

At the moment I'm thinking of a more flexible and much faster method of encodeing the keyboards than matrix scanning or shifting and actually it seems cheaper as well, at least to me as I've got quite some old electronics around.

Per - if you're going to trash the original electronics and you are in Europe I believe I'm interested in the left-over parts. You see, I like the idea of old analog electronics too, not only midi & synths! :) (Well, I would be interested even if you are not in europe, but the shipping costs are high from US...)

Greetings!

Share this post


Link to post
Share on other sites

Per - I just checked your profile and discovered that we are in the same country! That is very surprising to me, as I by now was quite sure I was the only Trio-owner left in Sweden!

Greetings from the north of Sweden!

Share this post


Link to post
Share on other sites
At the moment I'm thinking of a more flexible and much faster method of encodeing the keyboards than matrix scanning or shifting and actually it seems cheaper as well, at least to me as I've got quite some old electronics around.
Hard to imagine. Thorsten measured the switch matrix at about 80 microseconds for 64 notes input. Partswise you should be able to do a switchmatrix on the Trio with a core, 3 input registers and two output registers.  The PCBs are more expensive than the parts on the shift registers.  The necessary diodes are about $4 in the US.  Of course you can't value your time at anything or the costs go through the roof. ;D But I look forward to hearing what you are thinking!

Share this post


Link to post
Share on other sites
Per - I just checked your profile and discovered that we are in the same country! That is very surprising to me, as I by now was quite sure I was the only Trio-owner left in Sweden!

Greetings from the north of Sweden!

Small world, isn't it. I was quite certain too I was the only Trio owner.

We'll get in touch.

Per S

Share this post


Link to post
Share on other sites

Jim, maybe this is a better place to discuss the Diode Matrix we had at http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=midification;action=display;num=1093426954

And leave that topic for midi to pipe organ conversion.

As I said 16 x 32 will be fine for me I think.

Was your plan to call the manuals more often than the stops? Stop delay can be higher than manual delay. Although the tests say it isn't much. I'm glad AIN will work to.

How to connect to the matrix.

If you have an 16 x 32 matrix you have 48 wires. On the market there is an 2x25 pin to mount on a PCB. With a box around the pins this will be solid. I used IDE computerkabel for my pedalboard. This is 2x20 pins plus box. When 2x25 pins is used you can easily connect a new set of knobs with a cable available at the local shop or an internet store.

My plan is to build stops and use one of the 16 outputs for every division. This is four in total for three manuals and pedal. Up to 128 stops can be controlled by this. 32 per division. That should be enough :-)

Also I like preset thumb buttons beneath the manuals. To do this I came up with an idea that makes full use of the matrix form.

First plan: mount under two manuals 32 buttons. 64 in total.

But I have to set and get them in jOrgan so 'll use a switch. In one position they will connect to one channel  in another they will connect to another. This means 32 buttons and a switch for 64 inputs.

But wait this can be expanded. So I'll use 2x 16 buttons and a (set of) switch(es) to connect to 4 channels. Two to set the presets and two to read them.

The same switches on multiple channels can also be used for the manuals. In this way you can select one of the channels to connect your manual with. In this way you must be able to make a 3 manual organ with only two manuals. Just connect a threewayswitch to each manual (or exactly two, one for each 32 notes). And select the division with this switch. I have to take a closer look at the schematics to see if coupling is available two i.e. use two (or more) output connectors on one input.

In this way I will have (channel numbers may be different)

Channel        Use

0                    Manual I

1                    Manual I

2                    Manual II

3                    Manual II

4                    Manual III

5                    Manual III

6                    Pedal? Not necessary yet I think.

7                    Stops I

8                    Stops II

9                    Stops III

10                  Stops Pedal

11                  Preset 1-32   set

12                  Preset 33-64 set

13                  Preset 1-32   get

14                  Preset 33-64 get

15                  Left for for example crescendo pedal

I hope this is all clear and usefull for other users.

Share this post


Link to post
Share on other sites

What ever came of this project? Are the test files TK made posted anywhere currently? And was there ever a x64 matrix config made (4x64 or 8x64). The reason I ask is that most of the older Rodgers organs (I believe the Trio included) have a scanning system that scan's the whole keyboard at once, each of the keyboards are diode matrix-ed so that all the C1 keys, C#1 keys, D1, keys, etc of all keyboards and pedals are wired together and the keyboard buss-bar contains the scanning pulse. A simple async ring counter is used to drive the scan pulses. The Generator diode keyer matrix is also provided the same keyboard scan pulses so they knew which sounds to put on which keyboards. Couplers in this system were free, all they (Rodgers) had to do was muk with the scan pulses a bit to make any keyboard play sounds from any division.

Now that aside, IF the Midibox did scan 64 at a time it would encompass a whole keyboard (61 notes) and I could disable the old async scan generator and use the scan pulse from the Midibox instead. Going a step further if I were to assign the generator matrix a different set of scan pulses (from another midibox doing the same DO functions in reverse) the keyboards and generators could effectively be separated. WITHOUT un-wiring anything!

If this could be pulled off then only 1 chain of DI's and one chain of DO's would be needed to midi-fi most of the older 70's & 80's Rodgers organs and enable midi to be used alongside the old electronics or in-between the keyboards and old generators with out having to do any buss wiring changes.

I used to service these models and know them inside and out, I can do any hardware design needed and provide documentation and schematics but my firmware skills are limited. I would love to see someone jump in and help on the asm side of things. Jim, do you still want to do your Trio?

Midibox is great stuff!

Jmayes

Share this post


Link to post
Share on other sites

I'm getting confused again....

For my project (hammond regent 4172,) I bought seven DIN kits from smashtv to handle each of the inputs from the organ. Am I going MAD or am I setting myself up for failure?

Share this post


Link to post
Share on other sites

I was hoping that someone could point me to the test diode matrix scan routines TK made. The old links are no longer good. Sorry if my above post was too wordy, was just thinking out load.

Thankx again all,

Jmayes

Share this post


Link to post
Share on other sites

Hard to imagine. Thorsten measured the switch matrix at about 80 microseconds for 64 notes input. Partswise you should be able to do a switchmatrix on the Trio with a core, 3 input registers and two output registers.  The PCBs are more expensive than the parts on the shift registers.  The necessary diodes are about $4 in the US.  Of course you can't value your time at anything or the costs go through the roof. ;D But I look forward to hearing what you are thinking!

Jim Henry,

Is the download reference you included earlier, before TK mad his adjustments, current with all suggestions from TK, If not, please arttach a new reference.

I have a three manual keyboard stack with keyboards configured almost exactly like the units that TK included in an earlier post. Each has 8 points for col's/8 points for rows. Can the matrix be expanded to an 8 x 32 so as to use one core, rather then 3 with the 8x8 matrix? If this has been done, could out point me to the thread. The switch matrix thread has spread out over so many posts, that it is difficult to find the most recent data.

Thanks,

Johnc

Share this post


Link to post
Share on other sites

The switch matrix project has indeed gotten scattered. I've started and stopped so many times without ever achieving a solid success that I've forgotten what was working and what brought me to a stop. My last effort was trying to help someone MIDIfy four organ manuals. My victim, er, collaborator eventually got frustrated and went with a commercial solution. I think the MidiBox side was close to working but I think he was done in by disorganized wiring and testing. For what it's worth, we conducted the entire effort by posts in the Miditzer Forum. You'll have to register for the Forum (free) and then you can wade through our entire exchange:

Miditzer Forum: Midibox switch matrix project

As I recall, QBas' 32x32 code is attached to at least one post in that topic. Sorry I can't be more specific but my memory of this is so jumbled you'll be better off reading through the correspondence on that project.

Share this post


Link to post
Share on other sites

Back to the matrix subject.

For other midibox users:

Following the thread mentioned by jim henry in his post above, The pictures below show my progress in setting up the hardware for a 32x32 matrix to encode three keyboards plus pedal.

The DINX4 and core(18f452) are new. The DOUTX4 is one previously as a pipe magnet driver and had the ULN2803 chips. Those have been removed and jumper switches installed to bridge from chip to connectors. The PCB at the bottom of the assembly routes the DOUT outputs to connectors. Since the output connections were soldered to the pins, I didn't want to try to de-solder fearing heat damage.

My link

My link

My link

Voltage checks have been completed, as well as continuity check for bad solder joints, so all is ready to install the ic's and fire it up.

The plan is to use the QBAS 32x32 app, or some modification of same developed by Jim Henry (thread on miditzer forum).

The assembly will fit under the keyboard along with the core.

Johnc

Edited by John_W._Couvillon

Share this post


Link to post
Share on other sites

Btw.: I've worked on MIDIO128 V3 in the last days.

It runs on a MBHP_CORE_LPC17 module and will provide such nice features like:

- storing/restoring presets on SD Card

- integrated MIDI file player (files played from SD Card)

- support for USB MIDI

- support for up to 3 MIDI IN/OUT ports

- support for OSC over Ethernet

- optional user interface which can be directly connected to the core (no additional shift registers required): http://www.ucapps.de/mbhp/mbhp_scs_proto2.jpg

- device can also be configured from the MIOS Terminal in MIOS Studio

- preset files can be edited as a spreadsheet in Excel (or OpenOffice)

Adding a 32x32 matrix driver would be a simple task for me, so if you are interested I could add this option

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Btw.: I've worked on MIDIO128 V3 in the last days.

It runs on a MBHP_CORE_LPC17 module and will provide such nice features like:

- storing/restoring presets on SD Card

- integrated MIDI file player (files played from SD Card)

- support for USB MIDI

- support for up to 3 MIDI IN/OUT ports

- support for OSC over Ethernet

- optional user interface which can be directly connected to the core (no additional shift registers required): http://www.ucapps.de/mbhp/mbhp_scs_proto2.jpg

- device can also be configured from the MIOS Terminal in MIOS Studio

- preset files can be edited as a spreadsheet in Excel (or OpenOffice)

Adding a 32x32 matrix driver would be a simple task for me, so if you are interested I could add this option

Best Regards, Thorsten.

TK,

Thanks for the response.

I think that it would be great to incorporate the 32x32 matrix capability into the ver.3 of midio128. I am not current with the MBHP_core_LPC17, other then it is a much more powerful core, with much more of a future then the old 18F452 core that I am using.

Will there be a ver.3 that will run with the older cores, such that I should hold up for a while on my project, and forget about adapting the QBAS 32x32 app?

If not, then I am too far along to start over with the new core. Jim henry and elepharo had success with getting the 32x32 app working (miditzer forum), so my plan is to continue along the same path they followed.

However,in support of those looking to apply the diode matrix to midifying keyboards, I encourage you to continue with whatever your plan for Ver.3 of midio128 as regards the 32x32 matrix.

I did repair the links to the pictures of my project, so have a look.

Thanks again,

Johnc

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