Program Modification Scan Matrix using C

[robinfawell]

I have been analysing the QBas Scan Matrix program that is written in ASM.  I would like to modify it to incorporate changes due to velocity variations between black and white keys.

When reading about Assembler and C, I learned that it is sometimes more efficient to program in C and allow the compiler to compose the the ASM code. The article however,  pointed out that C should not be used where interrupts were involved.

Looking at QBas 16 X 16 scan matrix I wonder whether there would be scope for writing in the program in C and including asm code where needed. (Using __asm “asm code” __endasm)

I would guess that the likely asm code would include would be the following.

Manipulations of clocks associated with Dout and Din.

Code such as the Function SM_VEL_Timer that uses FSR2 and IRQ_TMPx

Question Should I just use asm for sm_fast? or is there some scope for using asm within C?

I would appreciate any guidance.

Robin

[stryd_one]

When reading about Assembler and C, I learned that it is sometimes more efficient to program in C and allow the compiler to compose the the ASM code.

Efficient for the coder (you), but not for the chip ASM is generally a great deal lighter.

The article however,  pointed out that C should not be used where interrupts were involved.

Nah you can use C in ISRs. of course, you need to make those as fast as possible, so ASM is preferable… but you can always write the code in C, and once the concept is proven, inline some ASM (__ASM etc) in it’s place.

Looking at QBas 16 X 16 scan matrix I wonder whether there would be scope for writing in the program in C and including asm code where needed. (Using __asm “asm code” __endasm)

Yes, but it would probably be better to use the original ASM in an include file, as with the C scan matrix examples by TK. Much easier to rewrite that way, too

Question Should I just use asm for sm_fast?

Well short answer is; yes.

Medium answer is; Yes, but you can wrap C around it/use ASM within a C app, inline (__ASM) or by include

Long answer; In a perfect world, your C compiler would be so perfect that it would optimise the output ASM so well that there would be no difference. In the real world, the ASM that the compiler generates is not too hot. For it to be 5-15 times slower than hand-written ASM is not uncommon. However, if you write the C in a certain way, you can make the compiler output some pretty darned clean ASM. In my experience (which doesn’t mean it’s the rule) that means knowing the compiler’s habits, which is a matter of trial and error. A great example is in array accesses. Structure your data in the right way, and manipulate it in the right way, and sometimes optimising with ASM is hardly necessary. Go at it hap-hazard, and expect slow big crappy ASM to be generated. It might not even work. That said, coding in C is way easier and way faster.

Generally I have found (and been advised by others - I should have taken their advice in the first place) that the best way is the middle-road. Write your code in C because it’s faster to prototype it. If you find areas that need optimisation, either rewrite the C more cleanly, or go ASM. In your case, the optimised ASM is already there, so I’d just include it and work on making the necessary variables and functions exposed to C, and then write my mods in C. If your mods turn out to be too heavy, then you can always optimise them to ASM too, and you’ll basically have a C app that just includes a bunch of ASM, which is about as good as pure ASM.

'Course, if you’re an ASM guru and just learning C… I’d just go straight to ASM.

[robinfawell]

Thanks Stryd_One for such a comprehensive reply.

In QBas 16 X 16 program the SM_VEL_Timer uses FSR2 and IRQ_TMPx.  Is it possible to write in C and “force” the code to use FSR2 and IRQ_TMPx?

Robin

[QBAS]

About this code: unfortunatelly I implement resolution for velocity only in range 256.

Now after your inputs (in another topic) I will for sure go into bigger one.

Also I will implement correction for black keys, since white keys has less sensitive.

So code will be change, but I`m very inetersted in improovments, simplifing, adding comments etc. for

better understable, better possibilities for using by other people.

[stryd_one]

Is it possible to write in C and “force” the code to use FSR2 and IRQ_TMPx?

a) Yes

b) You don’t need access to them anyway because they’re internal to the ASM function

c) If you did rewrite it in C (why) you don’t have to use FSR2, you could use other vars

d) I’d avoid FSR2 because it’s used by the wrapper. I had a feeling it was saved but I can’t find .. wait.. Re: RAM handling in ISRs

e) All of the above

[robinfawell]

Reply to QBas.

I understand asm a little and C slightly more.  However I am very willing to help in presenting the scan matrix code with more explanation.

You may have the circuit diagram of the Fatar 88 keys keybed.  If you have please email it to me or place on the forum. I have a diagram (gif) of the 5 octave keyboard.  This shows two sections.  The left keyboard shows 32 keys (64 contacts) connected to a 16 pin connector. 

5 Octave Keyboard

Left Section Connector T0, T1, T2, T3, T4, T5, T6, T7 ; MK0, BR0, MK1, BR1, MK2, BR 2, MK3, BR3

The right hand keyboard has 3 keys missing on the MK7, BR7 bus and also uses the same size connector eg

Right Section Connector T0, T1, T2, T3, T4, T5, T6, T7 ; MK4, BR4, MK5, BR5, MK6, BR 6, MK7, BR7

I assume that the “T” wires correspond to the eight Dout shift registers outputs and the “MK” and “BR” correspond to the 16 Din shift register inputs.

88 note Keyboard

For the 88 key version I assume that there will be two 32 key sections (as above, left section) with a 24 key section. Perhaps the 24 key section will use T8 - T15 ie a second Dout register and also reuse some of MK0, BR0 - MK7, BR7 again. (I calculate 3 MK/BR contact sets?)  Guess MK0/BR0, MK1/BR1, MK2/BR2.

Please let me have your comments.

Robin

[robinfawell]

To QBas

Please ignore the previous message.  I think that I have made an incorrect assumption.  It is likely that the Dout strobe is the same as for the 5 octave Fatar keybed.  The left and middle sections of the 88 keys circuit will probably be

Left Section Connector T0, T1, T2, T3, T4, T5, T6, T7 ; MK0, BR0, MK1, BR1, MK2, BR2, MK3, BR3 (32 Keys)

Middle Section Connector T0, T1, T2, T3, T4, T5, T6, T7 ; MK4, BR4, MK5, BR5, MK6, BR6, MK7, BR7 (32 keys) and the

Right Section Connector  T0, T1, T2, T3, T4, T5, T6, T7 ; MK8, BR8, MK9, BR9, MK10, BR10 (24 keys)

This will require three DinX4 modules and one DoutX4 Module.

The scan matrix will be 8 X 24 of which 8 X 22 will have 2 contacts per key for velocity sensing and a further 16 single contacts will be available for other uses (sustain pedal etc)

The T0 -T7 connections will connect to the Dout Module and the MK and BR connections will be Din inputs.

Please let me know whether I am correct.

Robin

[robinfawell]

I am still working on understanding QBas scan matrix 16 X 16.  I’m now about half way. 

The velocity calculations rely on measuring the time difference between the first and second contact.  This will of of course vary depending on how strongly the note is played.

I have the Fatar circuits for the 51 note keybed.  I assume that the 88 key version works the same.This shows the first and second contact as normally open.

However the first contact is labeled Bk = Break ? and the second contact Mk = Make?  This might imply a normally closed first contact and a normally open second contact.

I wonder whether a Fatar keybed user such as QBas or SounDuke or others could clear up this matter or me?

Thanks Robin

[John_W_Couvillon]

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

[John_W_Couvillon]

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

[John_W_Couvillon]

Robin,

see photo attached

Johnc

[robinfawell]

John

My project is working in terms of generating the 88 piano notes. I have also made some (minor) code changes to enable the use of the sustain and soft pedal. I am using the midibox based on MIOS32 to generate midi which then passes to a PC running Pianoteq which is a piano softsynth. I have not had the time recently to complete the case woodwork and to box in the pedals.

There is more work to do on the resolution/ accuracy of the time delay. It is this delay that is used to determine the velocity (loudness) of each note.

Your project is an organ project which may not need the velocity sensing. The C code for generating midi is much simpler in that case. In my organ project I used an obsolete Roland Synth. If I was starting today I would use a PC organ synth. However my knowledge of these synths is very small.

The later MIOS32 system is ready made for USB interfacing. However you could use the older hardware if you want.

There is no need to use the QBas matrix. Modify TK’s fast scan example. You will find this in the Repository.

To do this you will need to learn some C programming. Look at the information in the doc folder in fastscan_button_matrix_16x16 and in the app file. The latter contains the C code. At this stage do not be put off by the code. Most of the difficult code was programmed by TK for the velocity sensing aspects.

I will try to help you if I can. Dealing with note generation is not that difficult. I am guessing that the stops should also be achievable.

Let me know which system you will use.

Robin