Building a MIDI keytar

I've made some changes to the preset layer format. Hopefully, this should simplify things.

0: MIDI Channel (0..15)
1: Transpose (By note) (-11..11)
2: Octave (0..8)
3: Keyboard Split Start (Byte)
4: Keyboard Split End (Byte)
5: Velocity fixed value (0: Variable, 1..127: Fixed)
6: Pitch Bend scale (Upper 4 bits: Left end value,Lower 4 bits: Right end value)
7: Modulation scale value (0..127)

Here's a rough sketch of the display / data entry console. It's not to scale.


The button marked 'E' is the entry button. The one marked 'X' is the escape or cancel button.
I offset it slightly so that it won't accidentally be pressed during data entry.

The other 4 buttons are arrow keys. When not in data entry mode, the arrow keys will move the cursor around the screen.
Once the 'E' button is pressed, you can use the up / down arrows to change the data.
Pressing the 'E' button will save the users' changes. If the 'X' button is pressed, the original value is restored, and edit mode is cancelled.

Since I'm using Timer #1 to scan the keybed, I'm also using it to scan the buttons. So, I plan on adding a button repeat and button repeat delay.

I'm also planning on adding a digital resistor to control the contrast, so I'll need to add a "System" page, and an easy way to invoke it..

As soon as I get it built, I'll post some pictures.

The switch layout looking good for me and intuitive.
I prefer an inline layout, because the enter butten can be pressed without You wanna do this.
MiDi Nibble 0...15 = Midi Channel 1...16 I guess that's clear.
Transpose by note should be done for the whole keybed, because the notes in the different split ranges has to fit.
Transpose by Octave should be done for the different split areas.
That can give You some issues in the overlap areas, but I have no better Idea.
So You have different menues for the Transpose values.
The pitch bend values go from 0 to 127 any time ?!
The pitch bend range is an seperate MiDi Command ?!

MJ . There seems to be a thing with embedded projects, 'we' always seem to be coming up with different / better / smarter designs ( HW and SW ) ... not sure if its a good thing or not ... Your project work is impressive ... and i guess enjoyable ...

wkrug said:

The switch layout looking good for me and intuitive.
I prefer an inline layout, because the enter butten can be pressed without You wanna do this.

Click to expand...

That's what I was thinking. TBH, I can be pretty clumsy at times, and I know I'll end up pressing the wrong button.

wkrug said:

MiDi Nibble 0...15 = Midi Channel 1...16 I guess that's clear.

Click to expand...

When you want to display the MIDI channel, just add 1 to it. When you send it, it has to be between 0x0 and 0xf.
So, that just made sense to me.

wkrug said:

Transpose by note should be done for the whole keybed, because the notes in the different split ranges has to fit.

Click to expand...

That makes good sense to me. Also, when the notes numbers are calaculated, they have to be clipped to the range 0..127.

wkrug said:

Transpose by Octave should be done for the different split areas.
That can give You some issues in the overlap areas, but I have no better Idea.
So You have different menues for the Transpose values.

Click to expand...

I still have to give some thought as to how the octave is going to be handled in software.
I like your idea of multiple splits. I was only planning on having at most two ranges.

wkrug said:

The pitch bend values go from 0 to 127 any time ?!
The pitch bend range is an seperate MiDi Command ?!

Click to expand...

PITCH BEND CHANGE
This function is a special purpose pitch change controller, and messages are always sent with 14 bit
resolution (2 bytes). In contrast to other MIDI functions, which may send either the LSB or MSB, the
Pitch Bender message is always transmitted with both data bytes. This takes into account human
hearing which is particularly sensitive to pitch changes. The Pitch Bend Change message consists of 3
bytes when the leading status byte is also transmitted. The maximum negative swing is achieved with
data byte values of 00, 00. The center (no effect) position is achieved with data byte values of 00, 64
(00H, 40H). The maximum positive swing is achieved with data byte values of 127, 127 (7FH, 7FH).

Sensitivity of Pitch Bend Change is selected in the receiver. It can also be set by the receiver or
transmitted via Registered Parameter number 00 00.

Click to expand...

I may end up taking Pitch bend sensitivity out of the keytar and leaving it in the actual instrument where it belongs.
Either that, or adding provisions to send an RPN to a synthesizer to set Pitch Bend sensitivity.

The real issue is MIDI congestion. It's not good to send too many MIDI messages at a time, because you can jam up the
instrument. So, Volume, Modulation and pitch bend will be sent at a much lower rate than the note values.

And only when they've changed. The same is true for MIDI note on / off.

granddad said:

MJ . There seems to be a thing with embedded projects, 'we' always seem to be coming up with different / better / smarter designs ( HW and SW ) ... not sure if its a good thing or not ... Your project work is impressive ... and i guess enjoyable ...

Click to expand...

granddad: That same thing holds true with music, and songs that you write. They're never really finished,
and there's always something you can tinker with to embellish them.

So I decided to take a stab at writing the Keytar firmware in C.
A little bit of a rocky start, but so far, so good. The serial display stuff did not work,
so I ended up copying my assembler routines over to the C project.

The display now works. Next, I'll port the timer tick code over to the C project.

P.S.: I made a small change to the timer1 tick code. The reset line is on RA11, and it was getting clobbered by the address
write to the 'AC138.

Post #143 is the schematic.

Post #154 reflects that change.

MichaelaJoy said:

clobbered

Click to expand...

A useless bit of information , the Clobber is an old make of printing press . It oscillated the plattern , the operator had to feed the paper in and
not get clobbered as they took the print out !

granddad: Not useless at all!
I now know the origin of the word.

Thanks for that.

MichaelaJoy said:

Post #154 reflects that change.

Click to expand...

Why make people search for your changes. Just post the new stuff. I for one will not go searching back through pages to find some edit. I may even stop following this thread if it gets too hard to follow - see what I mean? You didn't even link it!!!

Mike.

Pommie: Thanks for letting me know.

In the future, I'll post the way you suggested.

Ok: Here is the latest version of the hardware and software. I'll be adding the C code when I'm sure it's working.


Post #143 is the schematic.

Post #154 is the firmware.

I updated the schematic to show the correct ports.

Post #143 has the new schem.

MichaelaJoy said:

In the future, I'll post the way you suggested.

Click to expand...

Or not.

Mike

Pommie: I'm not sure I understand. You brought up a valid point about providing a link to the schem and source.

Why wouldn't I want to do things in what seems to be a sensible fashion?

No, I was suggesting that you post new schematics in the current post. Updating old posts will make the discussion meaningless for people reading this in the future.

Mike.

Pommie: I see. I was trying to avoid posting multiple versions of the schematic and software
to keep from cluttering up the thread.

TBH, I've been thinking about breaking the schematic up into sections, seeing as how I have to build my keytar
in four pieces.

I'm also rewriting the firmware in C. So far, so good, although there a few timing issues that I need to address.

As soon as I get things sorted, I'll do that, as well as post pictures and timing diagrams.

I'm also rewriting the firmware in C. So far, so good, although there a few timing issues that I need to address.

Click to expand...

Does Your IDE have a simulator included?
Then You can try to figure out how many time the different routines need to process.
Additional You can set a Port at the start of a routine and reset it at the end.
So You get the time how much processing time any routine needs with an Oscilloscope. - Often helpfully!

wkrug: That's exactly what I did.

I use an Oscilloscope to measure the timing. It works well.

For the case You can get some ideas here:

Well that was a first ... takes 'One man band' to a new level .. Could he be using MiDi over Bluetooth ?

Could he be using MiDi over Bluetooth ?

Click to expand...

I don't know.
I guess X-BEE pro or an normal serial Adapter like RFM12BP could be an alternative.
And the range should be better.
( I've made a telemetry sytem for RC airplanes longer time ago with RFM Modules ).
It depends of the local frequency restictions.
In europe a maximum of 10mW is allowed at 868MHz for an duty cycle of 10%.
434 Mhz is overloaded with to many units like Baybyphones LPD and so on.