Organ Coupling

[robinfawell]

This is a coding question.  Probably for Thorsten.

I need to couple the upper keyboard to the lower keyboard and the pedalboard to the upper and lower keyboards. This will only happen when the relevant coupler(s) is(are) selected.

This is achieved by doubling the midi note on and the midi note  off and changing the channel number on the second pass.

In my system Midi channel 0 is used by the lower keyboard, Channel 1 by the upper k/b and channel 3 for the pedals.

I have looked through the Midio_128 coding and have concluded that I should modify the lines in Midi_event.inc following

MIDI_EVNT_Send_8x ; Note Off

MIDI_EVNT_Send_9x ; Note On

The coupling selection is associated with specific Din/Dout pins and I will utilise the Dout "flag" status to generate either single or double Note On/Off with the midi channel change with the latter.

Am I on the right track ?

Regards Robin

[TK.]

Hi Robin,

I would suggest to put this feature into midio_din.inc, because this is the origin point where the MIDI event is generated, and all informations are available: you can check if a Note event should be sent, and you can send multiple MIDI events from there depending on the state of a certain DIN pin (just do this check with MIOS_DIN_PinGet)

The advantage is, that this doesn't falsify the results of the very generic functions in midi_evnt.inc - you would still be able to send single notes independent from the state of the "coupling function"

Last but not least this is the easiest solution - just add the code below MIDIO_DIN_Send

Best Regards, Thorsten.

[robinfawell]

Thanks Thorsten

I am not really sure how to proceed.

I believe that I can cope with the controls and "gating" from the coupling select buttons.

However I cannot figure how to generate the 2nd and 3rd (required in one case) midi event.

From your suggestion to use Midio_ Din.inc I assume that somehow you will be sending the 2nd midi event by triggering another pin number of equivalent Note but with a different Midi channel.

It seems that this will also mean that the 128.ini file will need to have defined the note and channel of this 2nd "input"

This may present a problem for me.

Core 1 has the 31 pedal notes and the Meta handler based organ stops.  The Core 1 128.ini defines these.

Core 2 has upper manual (61 notes), lower manual (61 notes) and two only Meta handling controls (actally used to couple the upper and lower manuals) . Again, Core 2 128.ini defines these.

The might be a problem in coupling the pedals to the upper or lower manual.  The or is important.  Due to polyphony constraints only one manual can be selected at one time.  The pedal 128.ini file has no "knowledge"  of the Core 2 128.ini file.

Coupling means that if the pedal coupler selects the upper keyboard then the notes played on the pedal will also utilise the organ steps that have been already selected on the upper keyboard.  In the old days this was achieved by mechanical coupling.

Coupling between the upper and lower manuals should be OK on my reasoning.

Your reply will be appreciated.

Regards Robin

[TK.]

Hi Robin,

I fear that the whole MIDIO128 application confuses too much. In fact you don't need to write anything into a .ini file (resp. into the midio_presets.inc file) - such possibilities only exist for people who want to configure the software without touching the code.

You are writing your own software, which only requires a small subset of the preprogrammed MIDIO128 features.

Your application mainly relies on MIOS functions, and mainly exists of selfwritten code. All the MIDIO128 stuff is only unnecessary ballast which makes the whole thing more complex than it could be.

I will give you a short example in the hope that it opens your eyes - it's written in C, and it requires the MIOS C wrapper (plus the tools which are listed under http://www.ucapps.de/mios_c.html)

Just download the C skeleton (which can be found at the MIOS download site), and ensure that your core is running with MIOS V1.8 (absolutely required!)

Open main.c, and put following code into the Init() function:

void Init(void) __wparam
{
  // initialize the shift registers
  MIOS_SRIO_NumberSet(16); // shiftregisters
  MIOS_SRIO_UpdateFrqSet(1); // mS
}
[/code]


and following code into the DIN_NotifyToggle() function:

[code]
void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam
{

  // send Note C-1, C#1, D-1, ... with the keys assigned to DIN pins 0..60

  if( pin >= 0 && pin <= 60 ) {

    // send note on if key pressed (pin value == 0) and note off if key not pressed (pin value != 0)
    MIOS_MIDI_TxBufferPut(pin_value ? 0x80 : 0x90);

    // note number can be calculated
    MIOS_MIDI_TxBufferPut(40 + pin_number); // 40 corresponds to C-1

    // send velocity: 0x7f if note on, 0x00 if note off
    MIOS_MIDI_TxBufferPut(pin_value ? 0x00 : 0x7f);
  }

}

type "make" in the DOS shell and upload the new .hex file

However I cannot figure how to generate the 2nd and 3rd (required in one case) midi event.

If you now want to send additional notes, then just replicate the three MIOS_MIDI_TxBufferPut lines, and modify the MIDI channel. For Channel #2, write 0x81 instead of 0x80, and 0x91 instead of 0x80

If the note values sent by the second core are different, then this only changes the calculations (xx + pin_number)

I'm sure that we will also find C equivalents to the other functions you've already programmed (e.g. the SysEx send function) - you will notice that the code will be much better readable (and especially: changable) then assembly based code - and thats the reason why I strongly recomment you to use another programming language - your project is predestinated for C

Best Regards, Thorsten.

[Per S]

Robin,

Apart from coding technique there are some logistic procedures to think about. As I understand it you have separate cores for the pedal, Core 1 and the manuals, Core 2.

Assume the following simple cases, manual to pedal coupler on

One case:

Press and hold Middle C on the pedal. Then press Middle C on the manual. No Note on for the manual should be sent because it’s already on, sent by the pedal.

Another case:

Assume you hold Middle C on both the pedal and the manual. If you release the manual C  (still holding the pedal) no note off should be sent. Note off for the manual should not be sent until you release the pedal Middle C.

I can see some challenges here since you have two independent cores and one doesn’t know what the other is doing.

Per S

[robinfawell]

Dear Per S

Thanks for your input.  I have not even thought about the implications of your observations. There is no doubt that the SCPOP organ behaves the way I described to TK.  However so far I have only tested the "software organ" one channel at a time.

My understanding is that two things may happen.

Firstly that the previous On message is cancelled.  Second that the next message is ignored.  This  behaviour depends on the desgn of the  sound module.  I should be able to test this soon.

Is Coupling a matter that  you have dealt with?

Regards Robin

[robinfawell]

Dear Thorsten

You have suggested before that I should use C programming.  I decided last time to persevere with Assembler.  I have had some success now with Assembly programming and have dealt with the various modes of button behaviour to my satisfaction.  As you know all of this was using the meta handler.

I am quite happy to spend a few weeks to learn C but 6 months might be too long. My previous programming knowledge is over 30 years ago and it was minimal.

I have sent for a C program book from Amazon and will look at what you have done and try your test example.

Regards Robin

[TK.]

Hi Robin,

I'm sure that learning C is a step into the right direction, regardless how long it will take. C isn't that complex, you will find a lot of features in the book which you will never use (like struct's or enumerations), maybe the first chapters will already describe all the stuff you need to know in order to realize your application in C :)

Best Regards, Thorsten.

[Per S]

Hi Robin,

I did some work regarding stop and coupler control years ago using the old version of the MIDIO128. I never completed that mainly due to two reasons.

One is that it’s easy to clobber up the MIDI interface with lots of Note On/Off. The MIDI specification isn’t really suited for controlling organs. If several identical Note On are sent, the synth may layer them (volume increase) or re-trigger. But it only takes one Note Off to stop the sound regardless of how many Note On have been sent.

If an Octave coupler is active and C2 and C3 is pressed only three Note On should be sent, C2, C3 and C4. Now if C3 is lifted Note Off should not be sent to C3 but rather to C4.

Add some pitch control, 16’, 8’, 4’ and 2’ to Sub and Octave couplers you will have to send 6 Note On for every key depressed. Now hit it with ten finger chords and the MIDI interface will be quite busy.

Another and decisive factor was the availability of Virtual Organs for PC like the Miditzer, Hauptwerk and jOrgan. These applications handle all the controlling and handling of stops. They also don’t suffer from the speed limitation of the standard hardware MIDI interface.

Now I’m using three cores with 384 DIN, standard MIDIO128 with a small addition to handle the swell function. Only simple MIDI messages are sent, no extra processing. Three manuals, pedal, stop keys and combination pistons are all midified. The MIOS and MIDIO128 are rock solid, never had any problem.

Per S

[robinfawell]

Thank you Thorsten and Per S for your comments

I cannot change the basic system and must persist with the Sound Canvas SC 8850 and with 2 core solution.  I would if necessary use another core!

I take Per's comments regarding Midi choke but bear in mind that I have128 voice poliphony.

At present I have two cores independently working.  The SC 8850 has 2 Midi In . 

I am wondering if I should change the system to route the Midi out from the 2 keyboards (Core 2) via Core 1 using Midi Merge.  Would this work to improve matters?

I called Edirol (Roland) this morning to find out more about how the module will react to "coincident" Midi On messages on the same Midi channel and the possibility of losing Note Off .  They will get back to me.

Regards Robin

[Per S]

At present I have two cores independently working.  The SC 8850 has 2 Midi In . 

I am wondering if I should change the system to route the Midi out from the 2 keyboards (Core 2) via Core 1 using Midi Merge.  Would this work to improve matters?

In my opinion it’s much better to stay with separate Midi in. A Midi Merger will not improve anything.

I should clarify my statement about choking the Midi interface. Normally you can’t outplay the Midi interface. But if the application needs to control many ranks of “pipes†and each key depression sends 10-15 or even more “Note On†then there might be problems.

If, on the other hand, only a few “Note On†are sent with each key depression there is no cause for alarm.

Per S

[robinfawell]

Dear Thorsten

I have started to look at Core 2 Programming using C. This core is fairly simple and uses 122 pins just for the keyboards.  There will be either 1 or 2 pins for coupling purposes where I can begin to test the problems discussed by Per S.

A thought occurred to me that I may be able to reduce the midi choke possibilities by letting Core 1 know the extent of coupling in Core 2 ( and vice versa) by connecting Core2 DOuts  to Core1 Dins and vice versa.

I haven't thought this through completely. But it seems possible that I could restrict how much coupling can take place if this proves to be a problem.

However is this type of Core interconnection allowable?

Regards Robin

[TK.]

Hi Robin,

yes, this is allowed. You only have to take care that all interconnections are asynchronous signals.

This means, there is a certain propability that some signals are one SRIO update cycle (period: 1 mS) earlier sampled than the others. 

This is no issue so long each signal is handled seperately. But once you are combining signals to a bus (e.g. to transfer a "x"-bit information), you need an additional signals which says, that the bus value is valid. If this is the case, I can write down some additional notes on this topic, but I need to know, which informations you want to transfer exactly.

Best Regards, Thorsten.

[robinfawell]

Thanks Thorsten

I think that this problem should wait until I have tested the coupling sensitivity of the sound module.  This is some way off.  I have to revise hardware and software due to the C program.

At this stage it is enough to know that I could limit the degree of coupling if I need to.

Regards Robin