New Midibox KB built!

[Duggle]

I've just built a dual manual (upper and lower) 2x 61keys using 2x 5 octave velocity sensing key board from Fatar sourced through local Doepfer agent.

I've used a standard LPC17 MBHP Core, 2x DIO Matrix PCB, connected as per the excellent doco and instructions set up by TK.

It works!

There is room beside each keybed for mod wheel and pitchbender.

Some observations (and questions):

• The suggested settings for velocity response are a bit "top heavy" (Meaning the average strike gives a velocity of over a 100). I think I prefer it if its in the 40 to 60 range. This way it is easy to perform accents, more dynamic.
• I've improved this a little by making delay_slowest smaller say 1000 (the suggested was 2000). Better, but still not proving a very smooth transition from soft-light to heavy-fast.
• I suspect a concave velocity curve is what I'm after ( with increasing velocity on input, the output velocity increases from left to right on a velocity curve diagram.) Rightmost curve, below.
• The pitchbend modwheel combo I'm thinking of fitting to each keybed is a Doepfer one. It states on the website that the potentiometer on each wheel does not travel the full distance. In other words, if 0 and 5V is attached, the wiper voltage will only go from 0 to about 1.6V. I assume the best "fix" for this would be in software?
• The pitchbender has a centering spring, I would assume the software would need to recognize when the bender is "at rest" to provide a pitchbend of "zero"?
• I would like a sustain pedal for each keybed. I assume the most straight forward interface for this would be the analog (using pullup/down resistor) with each footswitch? (It would mean I'm using all (6) analog inputs.)
• I've not seen the firmware source code yet, I assume it is/will be available?

Thanks TK, for putting together another great midibox project!!!!

[TK.]

Cool that it works at your side as well! :)

I got very similar proposals from the first users at the german board - it depends on the outcome with MBNG if this will be solved once MBKB has been merged into the MBNG firmware, or (if performance isn't good enough) if I will program the enhancements into the MBKB firmware only.

Like for all published applications, the source code of MBKB is available in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_kb_v1%2F

If you would like to help:

- you could try to develop an algorithm for a flexible (user-definable) velocity curve. Maybe Spline based?

- PitchBend min/max and center handling is also an open topic (I've no idea how to provide a simple configuration interface for this)

- sustain: I'm unsure if it's better if a sustain pedal just sends CC#64 (this would already be possible), or if it should prevent that NoteOffs are sent until the pedal is released.

CC#64 can already be assigned to an analog input (e.g. you could use the modwheel input for kb 2 and assign it to CC#64, if kb 1 inputs are already allocated)

For the "holding Note ON" approach a small firmware extension would be required (the state of all notes is already stored in an array, so that this wouldn't be a big deal).

Once the best solution is clear, I could add dedicated sustain pedal inputs to J5B.A4 and A5

Anyhow, the schematic for a sustain pedal can be found here:

Best Regards, Thorsten.

[Duggle]

I'll look at the firmware, thanks for the link.

I'll think about the v curve options. Perhaps a system of presets with the alternative method of modifying the underlying parameters, would suit most users.

I suppose with pitchbend one would want the full range of digital values produced and to have the synth/receiver determine how it responds. This suggests a one off calibration procedure where the min and max values of the sensor are acquired and stored in eeprom. If the pitchweel is spring loaded, then it may work to have the value acquired at powerup used as the center.(keyboards commonly use this method to work out if a footswitch is normally open or normally closed.) In addition any constant reading in the neighborhood could be taken as "zero".

I'm thinking the only way I've seen it done. The sustain pedal only sends the CC, and the receiver decides how to process it. The way of "pre processing" the sustain of notes is interesting, but should definitely be just an option IMHO (actually it would be handy in certain circumstances such as recorded midi data where the CC event is edited out or otherwise lost, however it suffers from the fact that "information is lost", you could not edit the performance of the sustain pedal after the act of recording).

[TK.]

I'll think about the v curve options. Perhaps a system of presets with the alternative method of modifying the underlying parameters, would suit most users.

 

You are welcomed to take over this part! :)

 

 

 

I suppose with pitchbend one would want the full range of digital values produced and to have the synth/receiver determine how it responds. This suggests a one off calibration procedure where the min and max values of the sensor are acquired and stored in eeprom. If the pitchweel is spring loaded, then it may work to have the value acquired at powerup used as the center.(keyboards commonly use this method to work out if a footswitch is normally open or normally closed.) In addition any constant reading in the neighborhood could be taken as "zero".

 

You are right - a calibration procedure is probably the most simple way the configure the firmware.

I will consider this.

 

 

 

I'm thinking the only way I've seen it done. The sustain pedal only sends the CC, and the receiver decides how to process it. The way of "pre processing" the sustain of notes is interesting, but should definitely be just an option IMHO (actually it would be handy in certain circumstances such as recorded midi data where the CC event is edited out or otherwise lost, however it suffers from the fact that "information is lost", you could not edit the performance of the sustain pedal after the act of recording).

 

Thanks for your feedback - now I'm sure that sending CC#64 is the right way. :)

 

Best Regards, Thorsten.

[Duggle]

I've found that the variable set by

set srio_num 4

is set correctly to 4 but only until the next power up where it reverts to it's default value of 2.

The result for me is that kb 2 is not active until I issue the above command (despite having previously typed the store command).

thanks

[Duggle]

You are welcomed to take over this part! :smile:

I've been thinking about the spline approach you suggested. According to wiki a spline is a piece wise function where different segments of the domain are evaluated by different polynomial functions.

There would be a "run time" part where the velocity of each note event is calculated. Also, another part which runs when a new curve setting is made by the user, which calculates the coefficients of the polynomials.

I'm thinking that by specifying 3 spline "knots": start (similar to delay_slowest), end (similar to delay_fastest), middle (the delay time specifying a point between 2 polynomial curves), shape1 (determines curve of 1st polynomial), shape2 (curve of 2nd poly). The polynomials would be 2nd degree, parabolic. This would give a very wide range velocity curves without too much complexity, especially the run time function (which need to be reduced to integer calculations).

I'll have a play with some maths packages and we'll see how I go!

[TK.]

I'm very interested on your findings, because this would also help me to improve the curve definitions in MBCV V2! :)

 

I fixed the unstored SRIO num bug, added a sustain pedal function, and analog inputs can be calibrated in V1.007

-> 

 

Best Regards, Thorsten.

[Duggle]

TK, I noticed that the router settings work but are not stored. I used

set router 1 IN1 all OUT1 all

store

it worked, but not after powerdown.

 

BTW:I have a pitchbender and  mod wheel working really well. (I'm not sure about the calibration procedure working right, I'll let you know about this with more detail....)

[Duggle]

Hi,

has anyone else the above noticed the above problem, that is the router setting "forgets" between power-ups, although "store" is done?

I have an external merger rigged up as a work around.

Or has this been fixed already?

Thanks

[TK.]

Router settings are not stored in EEPROM, therefore they won't be recovered after power-on.

 

Background: if the MBKB application will be replaced by MBNG in future, it isn't worth the effort to "finalize" this one.

 

Best Regards, Thorsten.

[Duggle]

Could you give me a hint to permanently route

IN1->OUT1

IN2->OUT2

IN2->OUT1

in the code?

(I think this should be quick and easy for me)

Thanks

[TK.]

Wouldn't it be better if you would use MBNG instead?

 

However, this file shows you, how to configure the router nodes: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fsrc%2Fmbng_file_c.c

search for "router"

 

Best Regards, Thorsten.

[Duggle]

Maybe I should use NG for the KB.

However, would this work? ( could add more routings for USB, but it isn't used)

/////////////////////////////////////////////////////////////////////////////
// This hook is called when a MIDI package has been received
/////////////////////////////////////////////////////////////////////////////
void APP_MIDI_NotifyPackage(mios32_midi_port_t port, mios32_midi_package_t midi_package)
{
  // -> MIDI Router
//***not using router***  MIDI_ROUTER_Receive(port, midi_package);

//***route "hardwired"***

switch( port ) {
    case UART0:  MIOS32_MIDI_SendPackage(UART0, midi_package); break;

    case UART1:  MIOS32_MIDI_SendPackage(UART0,  midi_package); 
                 MIOS32_MIDI_SendPackage(UART1, midi_package); break;
  }


  // -> MIDI Port Handler (used for MIDI monitor function)
  MIDI_PORT_NotifyMIDIRx(port, midi_package);

  // forward to MIDI Monitor
  // SysEx messages have to be filtered for USB0 and UART0 to avoid data corruption
  // (the SysEx stream would interfere with monitor messages)
  u8 filter_sysex_message = (port == USB0) || (port == UART0);
  MIDIMON_Receive(port, midi_package, ms_counter, filter_sysex_message);
}

[John_W._Couvillon]

Duggle,

Since you are well into the midibox KB, and with success, perhaps you may have an answer to or suggestion to a problem I am having with the KB pcbs.

Given;  LPC-17 USB connected to XP, P4.  midio128 ver3. latest release.

             2 KB  PCBS encoding 3, 61 note KB's ( KB1 encodes Accomp, chanel 1, KB2 encodes main, channel 2,  KB3 encodes Solo, channel 3.  KB4 (DIN4/DOUT4) encodes all sense contacts   on   61 SAMS with output on channel 5).  All three keyboards have diodes per TK directions.  There are no other connection to the LPC, or its router, other then the control surface.

Problem:  All 3 Keyboards are fully encoding, producing 0X24 thru 0X60, and on the correct channels.  However, KB1  (DIN1/DOUT1 connected to the accomp Keyboard) adds a note on and note off on channel 4 with the note value 0x2E for any key pressed, even key 0X2E ( with channel 1)

 

i have checked over the 3 M8x8 in the .MIO file and everything seems to be ok.  None of the matrixes are using channel 4.

i have gone over the solder connections of both KB PCB's, touching up all solder points with no change.

I switched the Keyboard connections for the three keyboards around, and the problem followed the accomp keyboard.

The DIN and DOUT ic's are new.

based on the 8x8 matrix, a single DIN IC problem or single DOUT Ic problem effect multiple notes which is evident when looking at the matrix.  An open diode will effect only one note and it will not play.   Correct me if I am wrong, but a shorted diode should not cause the problem, since the key contact is open.

 

I am stumped!

 

johnc

[Duggle]

Hi John,
I don't have midio128 and am not familiar with it, so I only have a few general suggestions:

• enable debug mode and observe the MIOS Studio terminal window for feedback.
• flash test apps into your core and thoroughly test each keyboard and and each matrix din/dout pcb in isolation (e.g test a matrix pcb o.k, then use it to test all the keyboards in turn.
• When your satisfied that all hardware is working correct (I suspect it is or else you'll find something wrong in the previous step) look at your configuration data. (e.g is a control surface element i.e button etc, mapped to the SR that is in one of your matrix?)

good luck with this!

PS it might be best to continue this in another thread.

[John_W._Couvillon]

Duggle,

Thanks for the reply,

I will move the thread to Troubleshooting and name it  " Midio128 Matrix Problems"

Johnc