Maybe you can try to record a system exclusive message from the organ into Sibelius. (Connect the organ's MIDI OUT port to your computer's MIDI IN port, start recording in Sibelius, change the registration on the organ, stop recording in Sibelius and see if it captured a system exclusive message.)

If you want to further understand how to modify or create your own system exclusive messages for these registration changes, I or other friendly MIDI nerds that hang out in this forum may be able to help explain things. Take a look over the information I found below and feel free to ask us to explain any parts that are confusing.

_____

Sibelius 4 Reference:
ftp://macgarden:publicdl@repo1.macintoshgarden.org/Garden/manuals/sibelius4-reference-en.pdf

Starting on page 18, the section "Flexi-time" (real-time input) describes the recording function.

* Page 20 describes MIDI data is recorded including "controller", "pitch bend, modulation, volume, etc.", but it's unclear if that means system exclusive is included in the kinds of things it can record.

* Page 22 describes recording options to "Keep program/bank messages", "Keep controller messages", or "Keep other messages" which "adds any other MIDI messages to the score" which perhaps includes system exclusive messages, but I can't tell for sure.

Starting on page 273, the section "MIDI messages" describes how you can put codes beginning with ~ in a staff text item and Sibelius will send corresponding MIDI messages during playback.

* System exclusive messages, described on page 279, begin with ~X. The example (~Xh40,h00,hf7) implies the ~X sends the beginning F0 for you, so you don't need to put that in yourself.

_____

Rodgers i557 i557c i577 i577c Owner's Manual

PDF page 54 (printed page 44) describes how each registration change sends a system exclusive message that contains the status of all the stops and couplers. It explains this system exclusive message could be recorded into a sequencer and then later played back into the organ. But this manual doesn't explain the format of the system exclusive message.

Rodgers i557 i557c i577 i577c Használati Utasítás [Hungarian]

This Hungarian manual describes the registration change system exclusive message starting on page 55. The Hungarian text is intelligibly translated by translate.google.com.

* (For comparison, I found the English manual for another model Rodgers organ has an almost identical system exclusive description: Rodgers Insignia 537 Owner's Manual -- PDF page 44, printed page 42. This helps suggest what the original English description for the i577 probably was.)

_____

My understanding is the format of the full registration change system exclusive message is

F0 Begin System Exclusive
41 Roland/Rodgers SysEx ID
10 Device ID
30 Model ID (30 = Generic organ data) (00 47 = i557/577 data)
12 Data Set Command
01 Subcommand byte
00 Offset byte
... Data bytes (35 bytes)
__ Checksum byte
F7 End Exclusive byte

It's unclear to me if the Model ID should be 30 for "generic organ data" or 00 47 for "i577/577 data" or if either is acceptable.

The Hungarian manual has tables (in English) that describes which bits in the data bytes are enabled for various stops. The English i557/577 manual also says the status of the couplers is contained in the system exclusive message, but the Hungarian manual doesn't seem to say which bits are used for the couplers.

Here are some test codes you can try in Sibelius that I think should send a registration change system exclusive message with all the data bytes zeroed out, which will presumably disable all the stops and couplers. The first one uses the "generic" model ID, the second one uses the i557/577 model ID.

~Xh41,h10,h30,h12,h01,h00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,127,hF7

~Xh41,h10,h00,h47,h12,h01,h00,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,127,hF7

Many thanks for the reply! I'm a newcomer to forums and yours is my first ever reply! I've not had time to go through your response in detail but it looks very promising - I look forward to coming back in a few days to say it worked!!

Eureka!
Your first suggested test code worked and cleared all the stops! Next step (when I've time) will be to try to set up stop registrations. Give me a day or two.
Many thanks again.

I have successfully entered my first system exclusive message to set up the registration for an organ piece I'm writing! I have downloaded a program called Midi-Ox which monitors MIDI
output and after careful scrutiny during which I changed and cancelled registration changes I think I'm beginning to understand! [How the penultimate byte (the checksum) is calculated still has me puzzled though although using the Midi-Ox monitor I can just copy it. ]
I am really grateful for all your help - many, many thanks.
John.

P.S. in the early days of MIDI when I was using a BBC model B computer (!) I wrote a little machine code routine of my own which fed into the MIDI stream (during bars rest) and enabled me to do program changes 'on the hoof', so to speak. Do you know of anything similar which is around today as I don't think my BBC Model B works any more?

John,

Thanks for the updates. Helpful to hear about your progress.

Regarding the checksum. In the examples Bavi gave you, disregard the first 4 bytes (header) and the last byte (the end of sysex).. The checksum value is a number added to the sum of the other data values so that the total becomes zero (7-bit values, so that 127 plus 1 is 128 which drops the top bit and becomes zero). If one of the example data values (currently 0) is changed to 1, then change the 127 to 126. MIDI-OX may calculate this for you? Or you could write a little prog to do the work for you?

It should be OK to write a prog to insert midi data into the stream, if you're mindful of how things work. Midi depends upon a specific sequence of midi bytes, never indiv bytes. So if you end up with two streams getting mixed up, neither stream will be correct and you will have garbage. As you suggest, if one stream is taking a 'rest', then the other stream could send a complete message (timing bytes, command, data, as required). Polling worked fine for my purposes, although interrupts allow more options but more complexity. The ports will depend on your hardware. Or you may want to keep everything going thru WinDoze, but that will be quite different from your BBC! You might be able to do what you need with MIDI-OX?

Just looked up about MIDI-OX, and seems you can create midi data from the PC keyboard (and I assume implement it immed). My reference above to 'timing bytes' refers to midi files, which could be created for playback within MIDI-OX, if you generate midi data for immed effect then you don't need any timing bytes. I have written progs which use the PC keyboard to play tunes, incl program changes and I think some controllers (this was a long time ago).

Geoff