USER_Tick, debounce and DIN changes in MIDIO128

[moonskin]

I've been trying to work my way through understanding some aspects of MIDIO128.  I'm particularly interested in adding some code to USER_Tick.  My understanding is that USER_Tick follows all the other routines but I'm not clear about the timing relationship between this and debouncing.

On a single scan, if any DINs have changed then debouncing is started.  When USER_Tick is returned to next, has the debouncing finished or does it take several "trips" through USER_Tick before this is completed?

My second question: is there any documentation that I can look at to see where and how the DIN pin status is stored and retrieved in order for it to be checked for changed pins?  I've looked at where I think it is in the code but I can't seem to get what is happening. ???

Thanks

Graham

[stryd_one]

When USER_Tick is returned to next, has the debouncing finished or does it take several "trips" through USER_Tick before this is completed?

The debouncing happens as the DINs are scanned, and then the NotifyChange function is called after it is complete. The Tick function is separate, it just loops around whenever MIOS is not busy doing something else (like scanning the DINs)

My second question: is there any documentation that I can look at to see where and how the DIN pin status is stored and retrieved in order for it to be checked for changed pins?

It's not really documented because you shouldn't need to worry about it, MIOS does it for you ;)

[moonskin]

Thanks for the info.

I've been looking at the various matrix scan ideas and was thinking over a scheme where two lots (2x61 note manuals per lot) of switches feed into a single set of DINs via diodes.  The common lines would be switched (via a single pin and buffers) in USER_Tick and a flag set or unset so that the MIDI status byte could be changed to a different channel value appropriately before sending .  eg the ini file sets the first two manuals to channels 1 & 2 then if the flag is set for the alternate manuals, add 2 to the status byte so it comes out on channels 3 and 4 (Note numbers are constant on each lot of manuals - only the channels change.)

This would give me effectively a 128x2 matrix albeit a rather specialised one, but one much easier to wire than a 16x16 one.

The trick will be whether I can swap the DIN status for each lot in and out from storage in a reasonable time within USER_Tick. That's why I need to understand how they are stored.  I'll keep working away at the code to see if I can get my head around it.

Thanks again.

Graham

[stryd_one]

You should store them in your application, no need to mess with MIOS or read code.

Hint: http://www.ucapps.de/cmios_fun.html#MIOS_DIN_SRGet

I think a 32x8 matrix would be much easier.....

[jimhenry]

Graham is trying to MIDIfy on organ console. A 32x8 matrix is easier if the switches are set up as a matrix, i.e. the common bus is divided. Organs generally have a common bus for all 61 keys and may have a common bus that extends across an even greater number of stop switches. In such a situation, it may be easier to bring in all keys in parallel.

What I think would benefit Graham is to start with TK's second switch matrix example and morph the 8x8 matrix into a 128x2 matrix. Actually, I think 64x4 might be more advantageous. I think Graham is hoping to finesse a single DOUT bit from the Core to do the 128x2 with 4 DINs. But you can do 64x4 with 2 DINs and 1 DOUT which saves 1 board and quite a bit of programming effort.

[moonskin]

Perhaps I should clarify my thinking here.

While I'm quite happy to use a matrix for myself, the educator in me is not so sure it would be useable for many.  MIDIO128 works so well because it is so straightforward to connect.

I'm thinking about this aspect along with the fact that MIDIO128 is a mature, stable app.  This gives a strong platform on which to base modifications as well as retaining all the benefits.  It strikes me that with MIDIO128, there is plenty of left-over power to be utilised.

I also think about the fact that not all keyboards can be adapted to matrix wiring whereas matrix wired keyboards should be able to be wired with a common bus.

I also like the idea of 4x64 because it retains the ease of wiring - 1 DOUT pin to each common and 1 DIN to the same note on each keyboard via a diode and still allows common bus keyboards to be used.  I would also think it fairly straightforward to develop a PC board to hold the diodes with connectors for ribbon cables to sit between keyboards and DINs.

So it's not actually the software implementation that concerns me but rather the ease of connection that is my focus. I'll keep thinking and investigating all the possibilities - keeps Alzheimers away so I'm told. ;D

Cheers

Graham

[stryd_one]

Graham is trying to MIDIfy on organ console....Organs generally have a common bus for all 61 keys and may have a common bus that extends across an even greater number of stop switches.

While I'm quite happy to use a matrix for myself, the educator in me is not so sure it would be useable for many

.....

So it's not actually the software implementation that concerns me but rather the ease of connection that is my focus. I'll keep thinking and investigating all the possibilities

Ahhh I see now! Good on you for considering future builders, that's awesome :D

Clearly this is somewhat organ specific - a subject I'm not entirely well versed on, so I'll keep my misinformed opinions to myself ;)

Regarding the 'long matrix' idea, you could probably write a driver for 8x128 with some ease, and use #defines to specify the size of your matrix, to limit scanning of each buss to your required size (In your case, 2x128 or 4x64) That'd be good I guess because it would allow for organs with different layouts (like the common busses that extend beyond the keyboards that jim mentioned). I'll butt out now ;)

Rock on moonskin!

[greenfox]

I will be interested to try this if it could be done using a config file like MIDIO128.  the 4x64 would be the easiest to work with for organs I think.