robinfawell

Mark, I have confused you with discussing the subject of the possible improvement to the church organ project and the Hammond organ synthesis. The SCPOP organ uses a layering of "instruments" to simulate the various organ sounds. Typically 5 of the Sound Module parts are used to produce the desired stop. This is fairly complex, all sorts of data is transmitted. Typically a sysex of 1500 bytes are required by the Module to change a stop. All stops require this transmission. Some stops require over 2000 bytes. Therefore if a stop is changed during a performance the poor old SC8850 needs to cope with all the midi note On Off messages and the Stop Sysex message. I know exactly what the problem is. It cannot be fixed except by changing the Synth module. However my hardware implementation is no worse than the SCPOP PC system. The SC8850 is the problem. However the overall result is fairly satisfactory, but with a differently designed Sound Module it could be improved. It is unlikely that the church organ will ever be modified but the design of a better synth would be a challenge. There are no drawbars, I use integral membrane switches with Leds. The software is mine, (with a lot of help from Thorsten) it is a complete, unique application. The hardware consists of 2 core modules, 5 Din Modules and 2 Dout Modules and one 64k bankstick (to store the various sysex messages). There are 7 pedal stops, 8 swell stops and 14 great stops plus tremelo plus couplers. In a few weeks I may show the mechanical and electronic design of the console on the forum. I have begun to research hammond organ sythesis and already realise that to get a realistic sound may be difficult. Regards Robin

Thanks Mark The two projects I propose are really different. I used the Roland Sound module because the original Italian designers designed the PC based software system around the SC8850. I copied their sysex messages verbatim. The sounds are good. see http://www.scpop.de/ My version uses MIOS written in C. The system is purely based on MBHP items. ie No PC. I am wondering whether I should try to design or tailor the FM module to produce an organ specific sound module which will overcome the design defiecencies as I see them. The modified/ midified Conn organ will be returned to the church soon. The Hammond organ will be for me only. At this stage I only know that I like the sounds. I don't want to make the system as the original. I will be happy with just the sounds. The drawbar seems a good stops system. I play the piano a little and would probably prefer a velocity sensitive weighted keyboard. It would be interesting to utilise my newly acquired C programming skills to help to design the system. Regards Robin PS I have looked at your Drawbar system. I looks good!

I am now in the very final phase of my organ project based on the SCPOP sounds using the now obsolete Roland Sound Canvas SC8850 Sound Module. There are now only a few minor tasks to complete. I have begun to think of the the next project and have identified two fairly large tasks. 1) A hammond type organ based on a hardware synth. (see below) 2) A (church) organ specific sound module. After completing the SCPOP organ I have identified two major problems with the system. Firstly the system needs to send large sysex messages to change the stops. Secondly, when there is a need to do this during a performance the system suffers from Midi "choke" and the notes are ignored for about 0.3 to 0.5 secs. It would be better if the various organ stops could be called with a simple midi message (not sysex). I think that this means an organ specific synth module (independent of the notes midi messages) I would like to use existing MIOS based modules if possible. eg Midibox SID, FM. I need to understand the difference between the relevant Midibox modules and the Roland Sound Canvas Sound Modules. Can anyone suggest any good starting references? Regards Robin

After receiving Thorstens reply I looked again at the code that appears after Midi_ox is reset. I thought that I should also check my application that deals with the organ keys. This is a fairly simple program but does have Midi Out. I also looked at my Button and Led test program for the console. This has no Midi. I have found that after resetting Midi-ox the following sequence is is alway present for the applications that have Midi. 00000006 1 -- B4 40 00 5 --- CC: Pedal (Sustain) 00000007 1 -- B5 40 00 6 --- CC: Pedal (Sustain) 00000008 1 -- B6 40 00 7 --- CC: Pedal (Sustain) 00000009 1 -- B7 40 00 8 --- CC: Pedal (Sustain) etc etc up to 12 lines Therefore the problem might be with Midi-ox. I looked at the Midi-ox website and found some discussions about large sysex dumps. This is exactly what I am doing. The settings I was using to configure Midi-ox were too small. I increased the number to 512 and size of the buffers to 512 for both input and output and the system worked properly with no Midi-ox resets. There is a lot to learn. Robin

Problem still remain despite my earlier optimism. I have a frustrating problem with Sysex messages generated indirectly via the Memorised Setup. When Sysex messages are generated direcly via the organ stop pushbutton (DIN) they are rock solid. However when they are generated by storing the same DIN on EEProm (internal not Bankstick) they fail about 1 in 9 times. In this case Midi-ox freezes. I had a similar problem with a different method using DIN_NotifyToggle. In that case core resets occurred. This is not the case here. The following CC's appear on Midi-ox after releasing from the freeze. I need to reset the Midi out on Midi-ox. 00000006 1 -- B4 40 00 5 --- CC: Pedal (Sustain) 00000007 1 -- B5 40 00 6 --- CC: Pedal (Sustain) 00000008 1 -- B6 40 00 7 --- CC: Pedal (Sustain) 00000009 1 -- B7 40 00 8 --- CC: Pedal (Sustain) 0000000A 1 -- B8 40 00 9 --- CC: Pedal (Sustain) 0000000B 1 -- B9 40 00 10 --- CC: Pedal (Sustain) 0000000C 1 -- BA 40 00 11 --- CC: Pedal (Sustain) 0000000D 1 -- BB 40 00 12 --- CC: Pedal (Sustain) 0000000E 1 -- BC 40 00 13 --- CC: Pedal (Sustain) 0000000F 1 -- BD 40 00 14 --- CC: Pedal (Sustain) 00000010 1 -- BE 40 00 15 --- CC: Pedal (Sustain) 00000011 1 -- BF 40 00 16 --- CC: Pedal (Sustain) There are 36 bytes in the present case whereas there were 8 bytes before. See the earlier posts in this thread. There is no definite consistency with the results and noise or interference must be a possibility. The direct method is a result of pressing a pushbutton say 0x08, the memorised set up stores 0x08 in EEProm and later on in Playback mode the 0x08 is read and then uses the same logic to generate the Sysex message. I suppose that Midi-ox may be more noise sensitive than the Synth. However that may be wishful thinking. Any thoughts anyone? Robin

Problem solved. Did anyone spot the error in the for loop? I didn't. for(d<=1; d>=13;d++) It should be for(d=1; d>=13;d++) the < before the = is the culprit. I am going to take Warnings more seriously from now on. Robin

It has happened again. This time I know the circumstances. I am trying to minimise my code by introducing a for loop. (see below). As soon as I compiled I received the following warning. There is a sequel to this warning. In the past I ignored Compiler Warnings. In this case the for loop fails to work for some reason. The code looks OK. Robin Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\C_Stops>make Makefile generated. Makefile.bat generated. Assembling MIOS SDCC wrapper ========================================================================== Compiling main.c Processor: 18F452 pic16_allocRegByName:963 symbol name _ReadStoredValues_d_1_1 regop= 00D471E8 gen.c:1890: WARNING: need to allocate new register by name -> _ReadStoredValues_ d_1_1 ========================================================================== Compiling pic18f452.c Processor: 18F452 ========================================================================== Linking project ========================================================================== Converting to project.syx Block 003000-0033FF allocated - Checksum: 2D Block 003400-0037FF allocated - Checksum: 26 Block 003800-003BFF allocated - Checksum: 09 Block 003C00-003FFF allocated - Checksum: 7D Block 004000-0043FF allocated - Checksum: 09 Block 004400-0047FF allocated - Checksum: 34 Block 004800-004BFF allocated - Checksum: 60 ========================================================================== SUCCESS! C:\C_Stops> ///////////////////////////////////////////////////////////////////// void ReadStoredValues( unsigned char pin) //__wparam ///////////////////////////////////////////////////////////////////// { unsigned char memorised_stored_pin; unsigned char d;//to increment EEprom reads q = ((pin-1)<< 5) + 10;//determines EEProm address depending on Memory pin number. for(d<=1; d>=13;d++) SendDump(MIOS_EEPROM_Read(q + d)); //SendDump(MIOS_EEPROM_Read(q + 1)); MemorisedStopsSetLed (8, 14, 15, MIOS_EEPROM_Read(q + 1));//pedal stops //SendDump(MIOS_EEPROM_Read(q + 2)); MemorisedStopsSetLed (24, 24, 25, MIOS_EEPROM_Read(q + 2));//tremelo strength //SendDump(MIOS_EEPROM_Read(q + 3));

I examined my code to check for recursion. I could not find out why this was occurring. I spent a couple of hours trying various things but nothing worked. I kept getting core resets. In the end I decided to use an alternative method that did not involve DIN_NotifyToggle. The method was more straightforward and seems to work wih no suggestion of core resets. The memorised setup seems to work and I am tidying up the code and looking at the operation to ensure that the button operation is ergonomic and reasonably intuitive. Regards Robin

Dear Thorsten I am nearing the end of the organ project ( I hope!) and found that there was a problem in starting the organ in a common sense way. In fact to select any organ stops it was necessary to push either the "Record" or "Playback" button first. This was not logical. I decided to see if I could initialise the variable to the "non Record" "non Playback" state (7). I knew that if I could achieve this, the organ would start by selecting an organ stop. and made the following entry in the void Init(void) function play_rec_group_stored_pin = 7; It worked ! Many Thanks again. Robin

As before, the warning has now disappeared. The name the warning was referring to was a function. I cannot now send you the full message. I tried the sdcc website but could not find anything. Thanks Robin

I keep getting the following warning after compiling. Warning; need to allocate new register by name. I have had this warning in the past and have ignored it. Can anyone help? Regards Robin There is a sequel to this warning. In the past I ignored Compiler Warnings. In this case the for loop fails to work for some reason. The code looks OK.

Hello Thorsten Thanks for confirming that this is a watchdog timer problem. I have the clrwdt in my bankstick read dump but the EEProm read is only one byte. Would I need to take any such care with the following repeated functions? DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 1)), 0x00); DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 2)), 0x00); DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 3)), 0x00);

I have reached the final hurdle with my organ project. The organ itself is working. The last stage is the memorised setup. I use the internal EEprom to store the pin Numbers (DIN) which are associated with the stops, couplers and pot values. There are 6 Memory buttons and ultimately there will be 21 stored values associated with each of the 6 Memory buttons. I am now able, using the MIOS_EEPROM_Read function to obtain the relevant stored DIN values to generate DIN_Notify_Toggle functions. These effectively will simulate the the pressing of the organ stops. Using the memory buttons in "Playback" mode I sometimes achieve the correct results. I am using Midiox to record the Sysex messages, There is a gremlin that sometimed adds an additional Sysex message to the end of a correct larger Sysex message. This is F0 00 00 7E 40 00 01 F7 There is a definite pause between the correct Sysex message and the additional bytes. I would estimate about 1/3 to 1/2 second. I should add, that the sysex messages generated directly by the pushbutton stops are consistently correct. Those generated indirectly are sometimes faulty. The additional Sysex message when it occurs is the same. It does not seem to relate to the beginning or (end) of the adjacent sysex message stored in the bankstick. It seems to be somewhat related to certain Memory buttons but not consistently. Does anyone recognise the message? Could it be a message from the core? Your help will be appreciated. Robin Since sending the post I remembered that the sysex message is the core upload request. Why would this be generated?

Hi Thorsten Perhaps I should have made it clearer. I don't think that the Midi-ox method is able to read the 64 kBankstick contents either. I used F0 00 00 7E 40 00 01 40 00 40 00 F7 (for BS 0, Device ID 00) and received 5128 bytes mainly 00's. Regards Robin

Thanks Michael Here is the top of my revised applicaton c file. #include "cmios.h" #include "pic18f452.h" extern volatile unsigned char record_button_state; void SendNote(unsigned char chn, unsigned char note, unsigned int velocity); void SendTremelo(); void SendDump(unsigned char dump_index); void SendPedalNotes(unsigned char pin, unsigned char pin_value); //void WriteMem ( unsigned char q, unsigned char pin); // void Memory_IO(unsigned int start_addr); unsigned char SetLed_NoDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin, unsigned char pin_value ); unsigned char SetLed_SendDump(unsigned char low_pin, unsigned char high_pin, unsigned char canc_pin, unsigned char stored_pin, unsigned char pin, unsigned char pin_value ); //void RecordSetup (); //void Set_Mem_Led_Rec_1 ( unsigned char value, unsigned int flag_addr, unsigned char pin, unsigned char pin_value);//used when Record is set unsigned char dump_index; //triggers sysex messages //unsigned char memory_group_rec_1 [6]; volatile unsigned char record_button_state = 17;//Record Pin 16 unsigned char k;// used to "count" flag memory locations unsigned char q; unsigned int addr; I have tried to follow your suggestions but the record_button_state remains at 0. Please note that there are two entries at line 3 and the 15th line. Is this what you intended? Thanks for spending your time in helping me. Robin

Thanks jackchaos, I've already tried that. In my program the value 17 is picked and the value stays at 17. I need to initialise the value outside the function somehow then allow the function to change the value from (say) 17 to 16 during the operation. Robin

I have a problem where I have variable "record_button_state" that is not behaving as I want. I would like it to have an initial value of 17(dec). I have tried to initialise it by the global declaration :- unsigned char record_button_state = 17; However in testing the result, using Midi-ox I find that the inital value is 0 not 17. The variable picks up another value in operation. It should have values of 16 and 17 during the operation of the system but not 0. Please help. Robin

Just to bring this thread up to date.... I can verify that MIOS Studio successfuly uploads 64kEEProm Banksticks. It is a requirement of my Organ design that stored Sysex messages are read from Banksticks. I have verified that the 64k contents were uploaded correctly using the application software.. This still leaves a question mark on Serge's Loader and Step 5 of the Bankstick Transfer Example. I am only referring to "reading back the data" procedures. Is it intended that MIOS Studio will be extended to Read back Bankstick data? Maybe it is already? Robin

Thanks for your comments Stryd_One. Using your tip regarding the Project Map, I changed the function using my alternative *3 code. The result is that the function grew from 140 to 142 bytes. You don't always get what you want! Robin

Thorsten kindly provided me with code to address Bankstick memory locations. Part of this code includes the following line. unsigned int addr = dump_table[dump_index*3 + 1]; Bearing in mind that multiplying gobbles up bytes. Would the following work? And would it be more efficient? unsigned int addr = dump_table[dump_index*2 +dump index + 1]; unsigned int addr = dump_table[(dump_index << 1) + dump_index + 1]; Or would the compiler carry out the *3 function efficiently in any case? Robin

I have spent a long time, most of today, coming to a conclusion that my probem was attempting to carry out bankstick write and read functions whilst the application was loaded. You must do this task before loading the application. ie in the READY state or with MIOS 1.9c whilst "BOOTLOADER IS UP T0 DATE." Thorsten makes this clear in Page 2, Step 2 of Bankstick Transfer Example. I missed the importance of the paragraph. I think that I am right in pointing out that Serge's loader will not carry out Request Sysex Dump commands with 64k EEproms. Neither will the instructions on Step 5. The 03 command is obsolete. I tried sending the 2nd sysex message only F0 00 00 7E 40 00 01 40 00 40 00 F7 , but this produced 5393 bytes of mainly 00's. Robin

I have been battling very unsuccessfully for about 16 hours, trying to load my sysex messages into a 64k Bankstick (external EEProm). I have tried many different ways but all is in vain. I have used MPLab to compile a main.asm file with org at 400000 to include 39 individual sysex files. This produces a main.hex and main.lst amongst other files.The lst file looks perfect. At TK's suggestion I have defined labels in asm file so that the sysex start addresses are tabulated. This also will enable file length in bytes to be calculated conveniently using Excel. All the addresses are shown correctly and all the sysex content is correct. Using both methods (Serge's loader and MIOS Studio) I have uploaded the main.syx file converted by the hex2syx program to the core. Both method show block acknowlegement. Hopefully this shows that the core is receiving the data. The MIOS studio also shows Midi In and Out activity. Here comes the problem! When I try to read back the sysex messages from the Bankstick I get nothing from Serge's loader. I have also used the suggested Midi_ox method bankstick dump and get the following two sysex messages. F0 00 00 7E 40 00 03 00 F7 F0 00 00 7E 40 00 01 40 00 40 00 F7 This is a repeat of the sent message requesting a 64k dump! I have made 2 new 64k EEprom modules that both give send acknowledgements. Both seem to work on writing but not on reading. I'm going mad! I'm obviously missing something. My recent problems were caused by very simple errors. I notice that with MIOS 1.8 + the address structure is changed for banksticks and that there is no need for the 03 command. I am wondering if this change could affect Serge's loader and the Midi-ox request dump request method. Please help. Robin Robin PS I have made the link between J4 SC to pin 28 of the core.

Problem Solved. I left an END statement in 6th "include" file. Robin

I have tried MPLAB 6.4 but no luck! Robin

Thanks. To some extent that would be irrelevant at this point. I am at the compile stage, well before the uploading of the data to the Bankstick. I will go back to an earlier version of MPLAB and see what happens. Thanks Robin