robinfawell

I am experiencing problems with analog inputs to the Core module. I am using theanalog inputs unmuxed. So far I have connected 4 channels out of 8 and already have one channel interfering with another. I am using 10k linear faders. There is no spurious midi until I move the faders. I have connected the 0V 5V and slider cables to the core in star. All unused inputs are at ground. I have bus bars for the 5V and 0V close to the J5 inputs. So far I have not connected any capacitors across the slider inputs to 0V. For design reasons the connections vary between 10 cm and 1metre. The cable lengths may be too long. There are essentially 7 balance controls for the various organ voices. These are for the Flutes Mixtures Reeds groups/divisions for the swell and for the great keyboards (6) and one for the pedal sounds (1). There is also an overall volume (shoe?) control and a tremelo rate pot. I am seriously considering changing the design as follows. Allocating one DinX4 module for the balance controls. This would provide 8 X 4 bit inputs via 8 rotary encoders. I do not need 128 increments and believe that 16 increments will be OK. ( I would not get 128 in any case because of the dead band) Maybe 2bit encoders would be OK? I could use my two cores modules with only one analog input each for the volume and tremelo rate. I think that I will need more than 16 increments for the volume and tremelo rate. I am hoping that with a single channel there will be no midi interference. I would welcome any comments on whether a) I should persist with the 8 analog inputs. Am I being prematurely pessimistic? b) 16 increments is sufficient for the balance encoders. I know that some electronic organs do not have these "balance" controls. Or will 4 increments suffice? c) 4 bit encoders are practical d) That the midio 128 software will be adaptable. (So far I have only seen reference to 2 bit encoders) Best Regards Robin Fawell

Dear Thorsten I have have been successful in obtaining the correct Dout/LED behaviour for the Radio Groups. Thanks again! Analog Inputs I have 8 pots and no need to multiplex. Each of the pots is associated with Midi messages (Control Changes) 7 pots are effectively volume controls for the Radio groups No 8 is the tremelo Rate. BX YZ vv is the format where X = 0 1 or 2; YZ is 07 08 or 09 and vv is the pot value. For the tremelo YZ is 01 Any change in the pot value will send the relevant CC to the Sound Module. I also need to send the relevant Radio group CC and for Channels 0 and1, the Tremelo CC to the Sound Module at the end of each of the Radio Group Sysex message stored in Banksticks. I have read the example with 64 pots, 128 buttons and LEDS. Question 1. Am I correct in assuming that I can work with 7 bit AIN values and that the 10 bit values are for the LCD BCD characters? In other words can I dispense with MIOS_AIN_PinGet and use only MIOS_AIN_Pin7Get? Regards Robin

My thanks to Jim and Petri for their input. I will try out the "old" switches first. I can always replace the "old" switches when needed. I've enough to do with other problems. Regards Robin

Dear Thorsten I need to use the Dout module to confirm (by LED's) the selection of the Radio Group Meta events and other sysex commands. I have examined the Midio_din.inc and Midio_midi.inc files and have assumed that I will need to further modify the Midio_Meta.inc to provide the correct LED behaviour in line with the Meta events. I will be using amongst others the MIOS_HLP_GETBitORMask and MIOS_DOUT_SRSet functions. Am I on the right track? Regards Robin

I seem to recall that reed switches were mentioned on the forum in connection with the above. Has any one any suggestions ie optical. The organ I am rebuilding has leaf spring mechanical switches. I would prefer not to use these. They are fairly old and I think that there must be another better way. Regards Robin

Thanks Thorsten I really appreciate your offer. I will clean up some of my work so that it is straightforward. The C programming will be new to me. However I will look at the files. Best Regards and Thanks again!

Dear Thorsten This is proving to be a very difficult project. It seems as if I may be suffering from noise spikes due to long leads between DIns, 1st Din to Core , Core to BS, Push buttons to Dins. The system works perfectly following a reboot. It does give proper results sometimes, only with about 10 of the 56 Radio group PB's. Plan I propose the following:- To connect one EEprom only, as directly as I can to the J4 connecter. To connect all unused inputs and outputs to GND using a 4.7k resistor (using a connecter). Have 1 Din connected as close to the J9 connecter as possible. Have no Douts connected at the beginning. Keep the PB_ Din leads short. I can then check for extra F0. Have you any comments? Regards Robin

Dear Thorsten At this point in time I have not included the long byte messages such as "reset" (0x4560 count) in the BS tables. Mostly the bytes are 1000 2000 and less. I am aware that long messages can cause the core to be reset. I dont think that should be the case with sysex messages 1000, 2000. But maybe this is a bad assumption. The clrwdt function was in the loop when I was checking the transmission of "reset" above. I took it out to eliminate this as a possible cause of the 'extra F0' error. I had assumed that it was mainly required for these long messages. When does the WDT normally operate? I have only seen the core upload with "reset" Regards Robin

Dear Thorsten I've rebuilt my BS, neater this time, tried a few things, decoupling, grounding all Ain pins. and No luck! I've tried your test for Double F0. It shows none! However the test to cross check also failed. I confirm that I measured pin 27 for RD4 and that I substituted 0x00 for 0xF0 in movlw 0xF0 (3rd active line). I located the LAST_RECEIVED_BYTE EQU 0x019 in app defines... I guess that at this point there may be a problem with the test or my modifications. Midio_Meta.inc I've wondered for some time how I should exit my "meta" program. The original program shows 2 methods:- goto MIOS_MIDI_BeginStream goto MIOS_MIDI_Tx BufferPut I am just using "return". ie call MIDIO_SYSEX_Send_Block return I've tried the first goto above, it seems to behave the same ie F0 F0! Here is the code extract from my version of Midi_Meta.inc that follows the derivation of BS, Address and Count ;;-----------------------------------------------------------------------------------------------;;----------------------------------------------------------------------------------------------- movf TMP3, W call MIOS_BANKSTICK_CtrlSet call MIDIO_SYSEX_Send_Block return;; Is this OK? Midi_Stream? MIDIO_SYSEX_Send_Block MIDIO_SYSEX_Send_BlockLoop ;;clrwdt;; used for Reset large file call MIOS_BANKSTICK_Read ;; Expects Addr in ;;MIOS_PARAMETER[12], Read byte from BS call MIOS_MIDI_TxBufferPut ;;Decrement 16 bit loop counter, loop until counter is zero decf TMP1, F skpc decf TMP2, F bc MIDIO_SYSEX_Send_BlockLoop return;; This may need changing BANKSTICK_DUMP_TABLE ;;BS No Addr Count dw 0x0000, 0x0000, 0x04D4 dw 0x0000, 0x04D4, 0x04D4 dw 0x0000, 0x09A8, 0x04D4 dw 0x0000, 0x0E7C, 0X09A8 etc, etc dw 0x0002, 0x21CC, 0x04D4 dw 0x0002, 0x26A0, 0x03C0 ;;-----------------------------------------------------------------------------------------------;;----------------------------------------------------------------------------------------------- Most of the code above is yours. I would be very pleased if you could check it esp. the returns. Thanks Robin

Hi Thorsten I have accidentally damaged my 32k Bankstick. I have made a 64k bank version using 2 of the the Microchip 512k modules. I am getting some strange results. Is there anything different to the use of the 32k version? For convenience in wiring and using the 256k diagram I will use Banks A = 1 and A = 5 . At present I am trying to download to Bank 1. Does MPLAB know or care that I am using the 64k version? Thanks Robin

Dear Thorsten Extra F0 Problem After too many hours, trying various changes without any luck, I am coming to the idea that I may have an inteference problem caused by ringing or oscillation in one or more of the components. Core; DinX4; Bankstick; Push Buttons. As a start I will provide power supply decoupling to all (except the PB's) of the above. My reasons are as follows:- A) The sysex messages are corrupted only at the beginning. I have now found that my large byte sysex is preceded consistently by F0 XX YY. At the moment I cannot remember the exact codes. However it is the first 3 bytes of the "Reset" sysex message. The other sysex have a repeated F0 at the beginning. B) Perhaps the noise spike and/or oscillation coincident with the press of the PB causes the leading code(s) to be read spuriously from the BS and then this routine is repeated with the correct code. C) The checks of countdown using checkpoint show the correct decrementing of TMP[12] D) The BANKSTICK DUMP routines were those emanating from your good self. If they were mine then I would not be so confident! Sysex generated following reboot are 99% correct. (No leading errors) Can you think of a way of determing by measurement or code manipulation the reasons why I get these errors. Best Regards Robin

Dear Thorsten I've increased the Midiox setting and included the clrwdt in the address loop counter. It works well apart from my "Extra F0" problem. As you may recall some of my sysex byte counts are relatively small 480 bytes. Will there be any disadvantages using clrwdt in this way for these smaller counts? Regards Robin

Hello TK Thanks for Answer 1) I will do some experimentation along the lines you suggest. Re2) Extra F0 I have no control over the leading additional and unwanted F0. It just happens. It is not really random. It only happens on the 2nd and subsequent button presses after rebooting. The first button press after a reboot always gives a correct Sysex message. I cant think of what is different with the logic before 1st press and afterwards. Could it be a carry bit or something ? The midiox display shows that the decremented count is behaving properly. On more consideration, are you suggesting that I just accept that the sytem will produce a spurious 0xXX and that I should precede all Sysex messages with 0xFE ? Hence if the 0xFE occurs or not, it will not matter. Best Regards Robin

Dear SmashTV I sent you an email off the forum. I thought at the time that there was something wrong with the forum. I have since found out that my recently installed firewall settings were the problem. Since sending you the email have come across your discussion on designing new Din's and Dout's using IDC dual row connectors. This would be very attractive to me. Have you some idea of time scales. Regards Robin

Dear Thorsten Thanks for your last tip. I was able to verify that the bankstick address was correct and that the problem lay in the MIDIO_SYSEX_Send_Block routine. I now have the Radio button behaviour that I want. Each button concerned with the sound selection works with 2 exceptions. 1) Reset. This is a long sysex message with a count of 16470 (0x4056). As you suggested I have used the clrwdt instruction as below. The TremF and TremS work OK. Their count is 2756 (0x0AC4) They probably don't need the WDT. Do you agree? ;;GrpF0 sends Reset and TremS and TremF MIDIO_META_Handler_F0 movf MIDI_EVNT1, W clrwdt;; Reset Count = 5 secs, Trems = 0.9 secs rgoto MIDIO_BANKSTICK_DUMP_GET I observe that the LCD display shows that the system is rebooting. The Midiox recorded sysex shows a count of about 6350 dec. This figure varies a little. Have you any suggestions? I suppose I could split up the message. But I'm not sure how to introduce the delay(s). 2) Extra F0. This seems to affect all PB's. The behaviour is inconsistent. Mostly there is an extra F0, sometimes not. The Sysex message is preceded by an additional F0. ie F0 F0 xx yy zz .. ..F7. I have designed the organ so that it is possible to extend the PB's in each radio groups and have several cases where I have an address with a Count 0000. In these cases instead of sending nothing I send a Sysex message "F0" only. I don't think it is switch bounce. The PB bounce spec is typically 0.5 mS <2.0mS. I am worried about the random behaviour. Any thoughts on these problems will be appreciated. Best Regards Robin PS Since sending you this message I tried an experiment. Before pressing the PB, I disconnected the power to the core. In each case the Sysex message was correct. ie No extra leading F0. To me this is difficult to explain!

My thanks to you John for your reply. I am in the thick of it, at present, battling with the programming of the organ "stops" Do I understand you correctly that it is often the case, that the shoe control operates only the Swell "volume"? Perhaps I should think of the balance controls as non- organist presets. The SCPOP design has a faifly elaborate scheme whereby one can couple (1) the pedal swell and great, (2) the swell and great (3) have individual control of all three. At this stage it is a detail. I can wait and see which is the most practical. BTW this is a chuch organ to be played by organists (not by me). Regards Robin

Dear Thorsten I have been trying now for two long days to find the cause of failure of my button handler. Initially it looked as if was working (sort of). I can generate sysex files of nearly the same length as the originals by pressing the relevant PB. Usually each button needs pressing twice to get a fairly close match in Byte count. The first Byte count (using Midi-Ox) is usually smaller. Sometimes the file is an exact match of the original but rarely. Often the count is 1 byte greater. Sometimes the cause is an additional F0 at the beginning of the file. ie F0F0 XX YY........F7 At your suggestion I am using the Meta Handler. I am using a jumptable to sort into groups based on F0 F1 ....FA (EVNT0). To simplify things a little I am keeping the radio groups based on F0 F1 etc very simple at present and only generate a MIDI_EVNT1 based on the PB value and send this via "rgoto MIDIO_BANKSTICK_DUMP_GET" to the Table Address generator and thence to the Sysex files stored in the Banksticks. I suspect that I have made a simple error. I have used your checkpoint methods to try to resolve the matter but no luck as yet! Do the symptoms above suggest any possible causes of error. Yours in Desperation! Robin By the way all the organ pedal notes located on this core module, 32 in number are OK.

Hi Thorsten Thanks for the information. The Ain comments will be useful. I have read quickly the test applications and understand superficially the concepts. It seems to me that because I am using the Midio128 to send Midi messages to the Roland Sound Module and that no midi messages are received that I only need to complete the Midi Out table in the ini file. Is this correct? If I am not requiring Midi In do I leave the values as they are? You are right . As I understand you, I need to send single messages each time the button is pressed. ie @Toggle mode. I'm sorry to keep returning with more queries. Regards Robin I have now loaded the 128 ini file and was very pleased to see that the LCD is showing both @Ononly and @Toggle messages. Most of the table is correct looking at the LCD

Dear Thorsten I am proceeding with completing the Midio128.ini files. I am not completely sure that I understand what I'm doing. The answers to the following should help. I have 9 pots. One of these is the Tremelo rate. I need to send the value to Channels 0 and 1. In my case B0 and B1. I have 2 Push Buttons that need to operate in Toggle Mode. I have called them TremF_PB and TremS_PB. Each channel should receive the same modulation value when selected (vv) and (00) when deselected. ie B0 01 vv B0 01 00 and B1 01 vv B1 01 00. What entries should I make in the MIDI_OUT and MIDI_In sections of the .ini file forthe pot and the 2 Push Buttons. Regards Robin

Dear Jim Thanks for your input. I have constraints imposed by the cabinet of the original Conn Organ. The gap for the foot control is only about 8" and the present "rocker" is about 6" wide. I dont think that the complexity of the rest of the organ designdoes will warrant anything more complex. I will probably keep the mechanics of the shoe control. I see the relative sound levels being set prior to each performance. I will want to add about 12 presets to store the various voice selections as well as the slider values for the Great and Swell individual levels. It will be feasible to adjust the levels during a performance. I suppose it depends where the faders are located on the console. Bet Regards Robin

Dear Thorsten Thankyou for putting me straight. I am beginning to see how the radio groups (I have 7) can be implemented. I am assuming that I can use F0 to F6 as follows F0 for radio group1 F1 for radio group2 ... F7 7 Each of the above can have a jump table. (Jumptable RadioGroup 1, 2, 3 etc. Then using the second meta event byte, I can use its number in the following way MIDIO_DIN_RADGRP1 ;; checks whether current Table number is equal to this RADGRP Last Entry Number. ;;If not, send Din No Sysex. If so get table entry No of this RADGRP Cancel Sysex. ;; In: Current_Table_Entry (somehow) SET_BSR MIDIO_BASE movf Current_Table_Entry, W, BANKED cpfseq MIDIO_LAST_Table_Entry_RADGRP1 rgoto MIDIO_BANKSTICK_DUMP_GET movwf MIDIO_LAST_Table_Entry_RADGRP1 movlw 0x80; Table entry No of RADGRP1 Cancel ;; 0x80 chosen as I am getting short on Din's rgoto MIDIO_BANKSTICK_DUMP_GET Question I have shown the table entry of 0x80 2 lines above. Is this value OK, or am I limited to 7F? I need to store setups of specific sound selections, pot values. Maybe up to 12 sets and then recall these to re-setup the sound module. Without going into any real detail will this be practical? Thanks for your help. I think I'm learning (Slowly!) Regards Robin

Dear Thorsten I am in the process of implementing the Din Mode Entry Table. As you may remember I have extended the Din Mode Jumptable and have now increased the No of entries to 12. There will be a mixture of Din functions. Some are Midi for the 32 note pedalboard. Some will be used to trigger the Radio Group Sysex. Others will be used to send simple Midi Control Changes to the Sound Module. I need also to store various combinations of stop selections in Memory. I believe that it is feasible to extend the table MIDIO_Presets_DIN_MODES in Midio_Presets.inc past the 0x0F address. I propose to use 0x80 to 0x86 for Table Entries. There are no Input Pins associated with these table entries. Actually they will be used to trigger "Sysex cancel" messages. Please comment. I see that you to fill in the unused area with 0's. Could you clarify the question of entries in the table for spare or unused Din's. Should I use 00 or FF. I am using Mode 00 for @OnOff At present FF is unused. Does it really matter in any case what the entry is because without the unused input being switched the table won't be addressed. Best Regards Robin

I have damaged the backlight LED by carelessly positioning the connector on the header on the core module. Does anyone have any experience of replcing theLED. Is the idea feasible? Regards Robin

To Jim Henry or anyone familiar with conventional organs. I need some advice on how to deal with overall volume and relative balance for the SCPOP organ. I want to fall in line with normal organ design practice as far as is practical. CURRENT DESIGN The organ has 2 keyboards (Great and Swell) and a pedalboard. The keyboards each have 3 groups of sound files. Flutes and Principals Mixtures and Mutations Reeds and Strings The pedal has only one group of sound files. There are independent "volume" controls for each keyboard group, the 3 potentiometers control the relative signal level (by Midi Control changes 07,08 and 09 between the Flutes (07), Mixtures (08) and Reeds (09) for the lower Manual and the upper manual is dealt with in a similar way with another 3 pots. The present design has only one potentiometer for the pedals. This controls the "volume" of the pedal sounds by employing the "expression" parameter 0B. Each of the keyboards has an additional single pot which is used to raise or lower the composite sound levels for both of the keyboards. This uses the "expression" parameter 0B. This brings the total No of pots to 9. It is obvious that I will need an overall volume control, a foot operated potentiometer. The current design may be fine for the PC based system. I use my mixer analogue slider to change the overall volume. It seems to me that I should use Midi. NEW DESIGN I am proposing to change the design as follows:- The relative level of the keyboard sounds will be controlled by 3 pots as before. I will remove the "expression" pots. I will control the pedal sounds with Midi CC 07 (volume) rather than "expression." The foot control pot will send identical "expression" (0B) parameters to the pedalboard and also to the 2 keyboards. This means that there will be:- 3 pots for each keyboard sending Midi parameters 07, 08 and 09. 1 pot for the pedalboard sending Midi parameters 07 (say) 1 foot operated pot sending Midi parameter 0B to send expression to all three 'boards altering the signal levels in tandem. Is this a practical solution? Any advice will be welcome. Regards Robin

Dear Thorsten Thanks for the tips on checking the revised program. I have now corrected the syntax errors using MPLAB and have used the checkpoint method on a couple of points in your program (Not my changes) just to see what happens. It works! I am uncertain when and how I should deal with BANKED transfers. I know that BSR means Bank Select Register and that is used for non Access addressing. I need to determine which entry points need the code you have detailed and how to recognise when there is a need to restore BRS. How do you restore BSR? Regards Robin