robinfawell

Since sending this post I have done some further reading and realise what Moogah was referring to. I need to prototype my function for unsigned char and write the function as an unsigned char. ie No Void. I'm not there yet. The function will change the variables. I need to return values. I forgot to include the variable pin in the function. I'm getting there! I made an error in thinking that my problem was over. I have spent a few hours trying to find the error but no luck! There are no Led's on and nothing works in case1 and 2! The rest of the code is pre Led function and works well. I cannot find any faults in my logic but its wrong. The pre function version works fine. Here are the relevant parts of the code expanded for completeness. Sorry about the length. I will try to underline the relevant lines. #include "cmios.h" #include "pic18f452.h" void SendNote(unsigned char chn, unsigned char note, unsigned int velocity); void SendTremelo(); void SendDump(unsigned char dump_index); void SetLed_NoDump (unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin); void RecordSetup (); //unsigned char toggle_state [7]; // used for single (non "Radio" Group) Led Toggling unsigned char dump_index; //triggers sysex messages{ ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when an button has been toggled // pin_value is 1 when button released, and 0 when button pressed /////////////////////////////////u//////////////////////////////////////////// unsigned char memory_group_selected_stored_pin;//Memory Group Pins 0-5 unsigned char record_button_state;//Memory Group Pins 6, Record unsigned char pedal_group_stored_pin;//Pedal group, Pins 19-25 unsigned char tremelo_strength_button_state;//Tremelo Fort, Pin 28 unsigned char swell_princ_group_stored_pin;//Sw_P Group, Pins 33-34 unsigned char swell_mixt_group_stored_pin;//Sw_M Group, Pins 36-38 unsigned char swell_reed_group_stored_pin;//Sw_R Group, Pin 40 unsigned char great_princ_group_stored_pin;//Gt_P Group, Pins 42-47 unsigned char great_mixt_group_stored_pin;//Gt_M Group, Pin 49 unsigned char great_reed_group_stored_pin;//Gt_R Group, Pins 51-57 unsigned char pedal_couplers_group_stored_pin;// Pedal couplers pins 16 & 17 unsigned char sub_oct_coupler_button_state;//Pedal Sub-Octave pin 18 unsigned char swell_tremelo_select_button_state;//Tremelo Swell Select unsigned char great_swell_coupler_button_state;//Gt-Sw Coupler Select. unsigned char great_tremelo_select_button_state;//Tremelo Great Select //Use PB switch to input on Core 2, however use LED on Core 1 unsigned char i;// used for MIOS_DOUT_PinSet0 unsigned char group; unsigned char pin; unsigned char stored_pin; void DIN_NotifyToggle(unsigned char pin, unsigned char pin_value) __wparam { if (pin >= 0 && pin <= 5) group = 1; if(pin == 6) group = 2; etc;etc ////////Memory Group//// switch (group) {case(1) :{ if (pin_value == 0)// reacts only when pressed, momentary switch action SetLed_NoDump (0, 5, 9, stored_pin);// function memory_group_selected_stored_pin = stored_pin;//sets the variable for this group to the current stored pin after the function above. } break; //////////Record (Used with Memory Group) /////// case (2) :{ if (pin_value == 0) //stored_pin = record_button_state; SetLed_NoDump ( 6, 6, 7, (record_button_state)); } break; ////////////////////////////////////////////////////////////////////////////////////// //This function is called to set the Leds for Single Buttons and Group Buttons///////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////////////// void SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin ) char j; if(pin == stored_pin ) //Is the current pin the same number as he stored pin? stored_pin = canc_pin;//If so, then alter the stored pin to the cancel pin allocated number for the group else stored_pin = pin; //otherwise make the stored pin vale, the current pin value. for (j=low_pin; j<= high_pin; j++)// using j variable from 0 to 5 MIOS_DOUT_PinSet0(j);//set all pins in the group to "O" if (stored_pin != canc_pin)//provided the stored value of the pin is not equal to the cancel number MIOS_DOUT_PinSet1 ( stored_pin);//set the current stored pin value to a"1 } I will have to stop and go to bed, my head is spinning. Regards Robin

To Moogah & Thomas There is no need for () on stored_pin. However there is in MIOS_DOUT_PinSet1 (stored_pin). I tried without and get a syntax error. Led behaviour I am looking for an explanation why there is a difference in the behaviour of Din pin 0 in the code you helped me with. Just after reboot, pin needs two presses before coming On. Other pins change fom Off to On on the first press. By the way this behaviour exists in the pre "Function" code. Regards Robin PS I should have informed you that my first code in the beginning of this post,Case 1 is preceded by if (pin >= 0 && pin <= 5) group = 1;

Thanks to both of you for your help. Thomas, I found the error with the 5th parameter. This should have been removed. It shows as a compiler error. I have (stored_pin) declared just under VoidNotifyDin Toggle. Hence it is outside the function. Moogah, you were right about == versus =. The application is setting a "Radio" group of momentary contact pin/led. Only one led should light at a time. The second press of the same button should cause the led to be off. System works except for one anomaly. More later. Thanks Robin

I would appreciate some help with a function. I have been successful with some simple ones. Here is the code, provded by Thorsten, that I want to convert into a function. There are multiple cases only 2 are shown. The lengthy code works. When I replace it with the function it fails. switch (group) ////Memory Group//////uses pin 0 - 5 {case(1) : { memory_group_selected_stored_pin = stored_pin if (pin_value == 0)// reacts only when pressed, momentary switch action //SetLed_NoDump ( 0, 5, 9, (stored_pin));///******* see A below //if button already selected, turn off LED's if(memory_group_selected_stored_pin == pin)//Is current button same as stored pin? ? { memory_group_selected_stored_pin = 9;// if same, set to pin 9. This is the cancel pin }else memory_group_selected_stored_pin = pin ;//save the current pin in memory_group_selected_stored_pin variable for(i=0; i<= 5; i++)//All LED's should be cleared MIOS_DOUT_PinSet0(i); if(memory_group_selected_stored_pin != 9) MIOS_DOUT_PinSet1(memory_group_selected_stored_pin);//set the LED for the current pin } break; //////////Record (Used with Memory Group) /////// uses pin 6 {case (2) :{ record_button_state = stored_pin if (pin_value == 0) //SetLed_NoDump ( 6, 6, 7, (stored_pin));///!!!!!!! see B below if(record_button_state == pin) etc A) The 4th line, that is commented out, is the function sending statement. B) This is a similar line to A) in Case (2) with the change of the last parameter. Here is my attempt at the function. void SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin) { unsigned char i; if(pin == (stored_pin) ) (stored_pin) == canc_pin; else (stored_pin) == pin; for (i=low_pin; i<= high_pin; i++) MIOS_DOUT_PinSet0(i); if (( stored_pin) != canc_pin) MIOS_DOUT_PinSet1 ((stored_pin)); return; } I am aware that there may be a local/gloal variable problem. I have tried out many changes but none work! Thanks in advance. Robin

Reply to Thorsten Thanks for the explanation. I do not understand all the hardware and software design aspects sufficiently to offer any proper alternative reasons for the problem. I would love to delve further into the reasons why the original setup with core 1 for console and core 2 for keys has a timeout problem and the opposite has no timeout problem. However I am very late with this project already. You may recall that with my original setup there was no timeout on the "console" core. The timeout was on the "notes" core. In a simple-minded way I believe that the midi activity is so high when sysex messages are being sent from the console core to the notes core that the notes from the keyboard cause a malfunction in its core. The program for the "notes" core is very basic. There is the normal Note On/Off code, there are two analog pots for controlling signal values. One thought concerns the fact that the cores are not synchronised in any way. I am using a cable to direct the midi and not using the Midi out from the first core. I have another cable from the console connecting a Dout to a Din on the "notes" core. Although the current system works fairly satisfactorily there is no doubt that when the stops are pressed whilst notes are played there is an interruption. I would guess that during the 0.3 sec the notes are ignored or corrupted. However I think that is tolerable. I plan soon to have a visit by a well experienced organist to take a critical view of the complete system. Regards Robin PS Sent Later I have tested the original SCPOP PC based system. It has similar characteristics as my current setup. When changing stops when playing there is some discontinuity in the SCPOP case it is loss of notes. The main problem would be hung notes. I have not experienced this yet with my design.

This reply is to KealyPaul and Greenfox The overiding design philosophy was to remove the PC from the SCPOP computer based design. This organ will eventually return to the local church to be played by the organist. As designed, the SCPOP utilised a display, keyboard and mouse. These items are not appropriate for the church and are not necessary. Therefore any software sysem eg jorgan miditser are not compatible in a simple way (I believe!) What I have done is to reduce the number of stops and other controls and replicate the SCPOP sysex messages and other Midi CC's to the SC. (In my case the SC 8850). You can read the SCPOP web site although now it is unsupported. The system uses thee midi channels for the upper, lower and pedal sounds. The stops for the upper and lower manuals are each in 3 Radio groups. ie only one stop from each group can be selected at a time. The individual stop sounds are layered and are a mixture of the SC Midi . The sounds utilise the SC Parts as follows:- Lower Manual parts 1-6, Midi Channel 1 Upper Manual parts 7-12, Midi Channel 2 Pedals parts 13-16, Midi Channel 3 In my case I have utilised core 1 for the 2 keyboards and Core 2 for the Console stops and controls and the pedal notes. The C program directs the various sysex messages that are stored in separate EEprom (Banksticks), to the Midi Out. There are a number of additional controls associated with tremelo an coupling stops. Core 1 and 2 have analog inputs which control the balance of the radio group outputs and depth of tremelo. I plan to have 5 or 6 preset memories that store favourite stop and balance control settings combinations. By the way the Radio Groups are :- Principals and Flutes Mixtures and Mutations Reeds and Strings. This is as you see, a stand alone system, No pc! It is not based on Midio 128 and is my software design with a lot of help from Thorsten. Regards Robin ,

Dear Paul Perhaps it was not explicit in my reply to Thorsten but I am delighted with the current state of the project. I now have a working design. I still need to tidy up the programming. The memorised setup program is yet to do and I plan to make a new console with engraved legends. The basic electronic design and program is complete. Regards Robin

Dear Thorsten I included the suggested code firstly in Core 1. No "Timeout" With the code in Core 2 "Timeout" occurred in some circumstances but not others. Before the details are given I should explain that the stops and the pedal notes are on Core 1. This connects to Core 2 with a cable not Midi to Core 2. The two Keyboards are on Core 2 which is connected to the synth by midi out. 1) There is no "Timeout" with the Pedal stops, even with one stop "Octave 8" at 2472 bytes and the others at 1236 bytes. 2) There is no "Timeout" with 4 Stops. These are however, fairly short at 756 bytes. 3) I have "Timeout" on all other stops. These have different file lengths mainly about 1250, a few just under 1000 and other at about 1400 There is an anomaly with the 2 Cancel sysex at 652 bytes that cause "Timeouts" even though they are smaller than the 4 stops in 2) at 756 bytes. The above results gave me a thought. The most midi activity occurs when the sysex messages are sent. Therefore it makes sense to connect the busy core module to the synth. This is not very scientific, I know. The result is that there is a vast improvement. There are no "Timeout" messages. There is an interruption of the notes for a fraction of a second but not for 2 or 3 seconds. I am curious to know the reason for the "Timeout" test and more importantly why the system works better with the "stops" module connected to the sound module, rather than the "notes" module. Thanks again Robin

Dear Thorsten I was replying to you explaining that I thought it was the length of the sysex messages when you sent the second reply. Debounce is not specified. Only one sysex message will be set with each press of a button. There are no multiple dumps. The CC's are very short. I dont think that they are a problem. Anyway the majority of CC's are volume, balance or expression values from pots. The coupling controls only change the channel numbers of the note on/off messages. On most stops there is at least 2 seconds delay before the synth will play notes. This is about a factor of 10 compared to the 0.32mS figure. (I think you mean 0.32 seconds) Could the Sound Canvas module delay the process? I cannot see any reference in the manual. Regards Robin

After nearly 3 years I have a working organ based on a US Conn Church organ and the Italian SCPOP organ design. The electronics are based on 2 core modules, 5 Din modules and 2 Dout modules. The modules are programmed in C. The system sends Midi Note On/Off from the 2 keyboards and pedalboard to a Roland Sound Module (SC 8850). The Roland unit also receives sysex messages generated by the console "stops" as well as various Midi CC messages. Everything works as planned except for one very essential feature. There is a significant delay when the organ stop is changed. This means that there is a period when no further playing can occur. There is either a silence or a hung note during the transfer period of about 2-3 seconds. This is unsatisfactory. Most of the sysex messages are about 1000 bytes +- 250 bytes. There are 2 at 2756 bytes. I need to solve this problem to make the organ a practical proposition. Here are some possibilities. I would need an improvement of at least 10 times the transfer speed. The Roland Sound Module has a USB input as well as Midi. I could change to a USB or IIC module. Perhaps the transfer rate of the current system could be speeded up. Is this a practical course of action? Change to MIOS_SRIO_UpdateFrgSet ? I would welcome any ideas. Regards Robin

Hi Thorsten, Is there any advantage in which Core should be last? The Note On/Off activity can be busy with chords which can be doubled and possibly quadrupled by coupling. Perhaps it does not matter. Regards Robin

Thanks Thorsten. That was very quick! Thanks Robin

I have made an incorrect assumption regarding my Roland Sound Canvas Module. I have thought for some time that I could merge two Midi Inputs. This is not the case. I need to merge the Midi Out signals from 2 Core modules. The first Core produces Sysex messages, Control Changes and Midi Note signals from the pedalboard. There is no Midi In. The second Core produces the 2 keyboard Midi notes and one Control Change. There is no Midi In (at present). As I understand it I can connect the 2 cores together using J11. Also that my program should designate Core 1 as MBLinkForwarding point and Core 2 as MBLinkEndpoint. My case, however, seems the opposite of the Midibox link example. In my case I want no filtering; I want all the Midi messages from Core 1 Midi Out to be present on Core 2 Midi Out. Should I designate both cores as "Forwarding" ? From my viewpoint core 1 and 2 could be interchanged. Any guidance will be greatly appreciated. Regards Robin

Thanks to both of you for your replies. Re the Midi suggestion, at present there is no midi connection between the 2 cores . The Roland Sound module provides a merge function. If it works, the "electrical" solution is the simplest. I will report back on the outcome. Regards Robin

Although this topic concerns my organ project it seems to have a general nature and I have addressed it to the Design Concepts section. I have 2 independent cores both programmed in C and both sending Midi messages to a Sound Module. Due to my need for Memorised Setup which is programmed in Core 1, I would like to control one Din on core 2. I propose to use a push button and its related Din / Dout on Core 1. The Dout will have 2 functions; to drive an LED on the console and to connect to a DIN on Core 2. Effectively this is the equivalent of a Push button on Core 2. I cannot see any reason why this should not work, providing the correct hardware and software polarities are observed. I realise that an opto_coupler could be used but is it really necessary? I would welcome any comments. Regards Robin

Thanks Thorsten The suggestion worked. In my case situation was made worse by having the core in the centre of the console. The Din and Dout interconnect cables travelled left from the core then travelled right, crossed over the core to the remaining Din/Dout module on the right. The common signals Ground/+5V/SC/RC cable lengths were thus halved in the revised layout. The SO and SI cables stayed the same length. However these signals are regenerated in each Din or Dout module. This would suggest that screening of the of LED and switch wiring is less important. Regards Robin

TK's suggestion of making parallel connection of the common signals to Din and Dout makes a lot of sense. If the connections (Ground/+5V/SC/RC signal) are in parallel then the capacitance can be halved (approx) since capacitance is proportional to cable length. This leaves the non common signals which must be chained ie SI on the Din module and SO on the Dout module. It is difficult to be certain, but these signals are regenerated on each module and the degeneration of these signals may be less. For SI and SO there is always the the possible improvement by matching the cable impedance. See http://www.fairchildsemi.com/an/AN/AN-393.pdf. Solution (d) from the above might be worth a try. I would try 100pf with 100ohms (the ac termination method). I will try the parallel connection suggestion above and report on the outcome. Many thanks to all. Robin

I would welcome any comments on this problem, especially from those who have solved such problems. I have completed the C code for the 2 keyboards using a Core Module and 4 Din Modules. This works fine. I have used unscreened Din - Din cables for the keyboards. I have finished the basic hardware and software (in C) design for the organ console. This uses a second Core module , 2 Din modules and 2 Dout modules. This works fine. However when I add the 3rd Din module and the 31 pedal switches and a Din -Din cable of 1 metre I get interference and the LEDS previously working behave randomly with some fluttering ie half on. If I shorten the pedal cable to 0.5metres. The system works. However this solution is not practical. The console to pedalboard dimension is about 0.8 metre. My guess is that have loaded the 4 core connections RD0, RD1,RD2,RD3 with too much cable capacitance and the signals have degraded. The Din and Dout interconnect cables are screened. I admit that, with hindsight, I could have minimised the Din - Din and the Dout - Dout cable lengths. However to minimise these cable lengths would mean lengthening the switch and Led wiring. Also I would need a new layout with a new wooden front panel with a fair amount of woodwork. (A lot of work!) An alternative would be to mount the 3rd Din module nearer the console. This would mean pedal switch cable lengths of about 1.8 metres. Question 1 If I extend the Switch and Led cable lengths, is screening necessary? Quesion 2 Is screening LED cables more important than screening Switch cables. I do understand that most Midibox Constructors will not have the need for such long cables. Here are my total cable lengths. Core - Din - Din (1.8 metres) Core - Dout - Dout (1.2 metres) Best Wishes Robin Fawell

Dear Thorsten I have looked at the problem for a good few hours now and apart from trying to devise a completely new parallel program to control the led's and generate the SendDumps I can't see how to interlace the read EEprom routines with the present design. Perhaps you would look at a typical section of the code and see if you can make any suggestions. }else{ //////// Pedal Radio Group Sysex ////// //////////////////////////////////////// if( (pin >= 19 && pin <= 25) && (pin_value == 0)){ if(group1_selected == pin)// checks that current pin is the same pin as stored pin { group1_selected =26;//Pedal cancel pin = 26; pin not wired on DIN module SendDump(dump_index = (26 - 19)); //Send Pedal Cancel Sysex to Sound Module }else{ group1_selected = pin ;// current pin stored SendDump(dump_index = (pin - 19));//Send appropriate Pedal Sysex message; dump_index set to 0 } for(i=19; i<= 25; i++)//All LED's should be cleared for all group pins MIOS_DOUT_PinSet0(i); if(group1_selected !=26)// checks that the stored pin is not the cancel "pin" MIOS_DOUT_PinSet1(group1_selected);// sets the Led }else { ////////Tremelo Fast/ Slow Sysex///For comments see Comments in Pedal Section above///// if( (pin >= 28 && pin <= 2 I am working on a function RecordMemory to read the groupxselected values into the EEProm at present. I have just about figured what to do. It might be simpler to have a separate section to control the LED's and generate the SendDumps rather than trying to integrate with the code above. Regards Robin

Dear Thorsten Thanks for the code for the Auto Reset trigger. This is now incorporated and working. I will start the Memory programs very soon. Regards robin

Dear Thorsten Please accept my thanks for your efforts in helping me with the organ console. It is probably the major design hurdle. The dump_table/dump_index coding was solved a few nights ago. I have to connect the keyboards pedalboard and console together and I need to test the AIN inputs some more. There are also a few small remaining problems. Automatic triggring of "Reset" at Switch-On. I have a button on the console which triggers a "Reset" 0x4056 byte sysex message. This takes a few seconds. I would also like to trigger this at the time (or just after) the DC power is applied to the system. Is there a standard method using the PIC or do I devise a circuit to do this? Stop Memory System The main organ "Stops"consist of 27 buttons and Leds arranged in 7 groups of "Radio" buttons. I would like record use 5 "Memory" buttons to recall 5 differet setup patterns. The idea is to select the combinations in the normal way and use a "Record" button in conjunction with each of the buttons in turn to memorise each combination. The patterns would be chosen offline. This would mean that I would need togenerate 7 SendDumps on pressing any of the memory buttons. I imagine that there might be timing restrictions on sending such messges at one time. Please help me a little. Thanks Robin

Thanks Synapsys I will keep the modifier in the prototype and the function statements. Regards Robin

Dear Thorsten I sent a question to you yesterday regarding my SendNote function. I had spent a lot of time trying various changes and could not get it to work. I then read one of my C references this morning that states that it is good practice to prototpe the function by placing the function after the include statements. It now works! I have theref0re deleted my query. I have now prototyped the SendTremelo function as well. I did get an error concerning the fact that the prototype differed from the function (later in the program). This was due to the "__wparam" at the end of the function. I deleted it fom the function. The error was removed. What is the purpose of this function ending and should I have deleted it? Regards Robin

Thanks Thorsten, SendTremelo is working! However in reading the "Send CC Events on Pot Movements" I noticed the use of 'unsigned int pin_value' as a variable in the function statement. I have tried both unsigned int and unsigned char as the pin_value variable in my SendTremelo. Both work. I suppose that the 7bit value obtained by the PinGet function limits the value to 7 bits in any case. Is there any difference between the following? MIOS_AIN_Pin7bitGet(0x00); MIOS_MIDI_TxBufferPut(pin_value); and MIOS_MIDI_TxBufferPut(MIOS_AIN_Pin7bitGet(0x00)); Regards Robin

Dear Thorsten I am making some progress on the tremelo programming but am having difficulty with dealing with the pot value. I can send fixed Midi messages but do not know how to "load" the 3rd TxBufferPut with the pot value.. See the following code. // This function is called when Tremelo Message should be sent. //B0 01 vv and/or B1 01 vv should be sent ///////////////////////////////////////////////////////////////////////////// void SendTremelo() __wparam { unsigned char pin; if (MIOS_DOUT_PinGet(61)==1) { MIOS_MIDI_TxBufferPut(0xB0); MIOS_MIDI_TxBufferPut(0x01); MIOS_AIN_Pin7bitGet(0x00);//This does not work! MIOS_MIDI_TxBufferPut(pin_value); } if (MIOS_DOUT_PinGet(62) == 1) { MIOS_MIDI_TxBufferPut(0xB1); MIOS_MIDI_TxBufferPut(0x01); //MIOS_AIN_Pin7bitGet(0x00);This does not work! MIOS_MIDI_TxBufferPut(pin_value); } } This function is called in one instance by AIN_NotifyChange. ///////////////////////////////////////////////////////////////////////////// // This function is called by MIOS when a pot has been moved ///////////////////////////////////////////////////////////////////////////// const unsigned char midi_status[7] = {0xB2, 0xB0, 0xB0, 0xB0, 0xB1, 0xB1, 0xB1}; const unsigned char midi_byte[7] = {0x0B, 0x08, 0x07, 0x0B, 0x09, 0x08, 0x0B}; void AIN_NotifyChange(unsigned char pin, unsigned int pin_value) __wparam { //Send Midi Control to Sound Module eg B2 0B XX, B0 08 YY etc // Pots for Pins 2 -7 if( pin >=1 && pin <=7 )// Pots for Pins 2 -7 { MIOS_MIDI_TxBufferPut(midi_status[pin - 1]); MIOS_MIDI_TxBufferPut(midi_byte[pin - 1]); MIOS_MIDI_TxBufferPut(pin_value); }else { //Pot 1 Tremelo Modulation if(pin == 0){ SendTremelo();// Function } } Could you explain how to read the tremelo pot in the SendTremelo function.