To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: bug report Cc: Bcc: X-Attachments: In-Reply-To: References: Here is a bug report. I'm using MidiQuest 6.00 on Windows 95 (4.00.95.a). Let me know what other details you require. Working on a library (TX81Z). Clicked on Edit button. Edited patch for a while. Decided I didn't like the edits and wanted to go back to the previous settings. Couldn't find an undo, so clicked on Close button ("X"). MQ asked if I wanted to save. I clicked on No. These three faults occurred: MQ32 caused an invalid page fault in module MQEDIT32.DLL at 0137:007275d2. Registers: EAX=00000000 CS=0137 EIP=007275d2 EFLGS=00010202 EBX=00ae4ce0 SS=013f ESP=009fc280 EBP=009fc288 ECX=8009d4b0 DS=013f ESI=000001fb FS=2e9f EDX=00000001 ES=013f EDI=00000000 GS=0000 Bytes at CS:EIP: 83 78 65 00 74 3e 8b 93 96 00 00 00 8b 72 65 8b Stack dump: 000001fb 00ae4ce0 009fc2b4 0072364b 00ae4ce0 00000000 00000005 00ae4ce0 00000000 00000000 00000169 000001c5 00000000 009fc2d0 0052c0a9 00ae4ce0 MQ32 caused an invalid page fault in module MQEDIT32.DLL at 0137:007275d2. Registers: EAX=00000000 CS=0137 EIP=007275d2 EFLGS=00010202 EBX=00ae4ce0 SS=013f ESP=009fc280 EBP=009fc288 ECX=8009d4b0 DS=013f ESI=000001fb FS=2e9f EDX=00000001 ES=013f EDI=00000000 GS=0000 Bytes at CS:EIP: 83 78 65 00 74 3e 8b 93 96 00 00 00 8b 72 65 8b Stack dump: 000001fb 00ae4ce0 009fc2b4 0072364b 00ae4ce0 00000000 00000005 00ae4ce0 00000000 00000000 00000169 000001c5 00000000 009fc2d0 0052c0a9 00ae4ce0 MQ32 caused an exception c0000026H in module KERNEL32.DLL at 0137:bffb87cc. Registers: EAX=00000000 CS=0137 EIP=bffb87cc EFLGS=00000202 EBX=00000000 SS=013f ESP=009fc080 EBP=009fc090 ECX=009fc0cc DS=013f ESI=009fbfbc FS=2e9f EDX=009fc188 ES=013f EDI=81598b50 GS=0000 Bytes at CS:EIP: 5d 5f 5e 5b 8b e5 5d c3 8b 4c 24 04 f7 41 04 06 Stack dump: 009fc090 bffb8a58 00000000 009fff68 009fc0b4 bffb88d7 009fff68 009fc0b4 009fc188 009fc1a4 009fff68 009fc188 009fc1a4 009fc0d8 bff7663c 009fc188 To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: another crash & bug report Cc: Bcc: X-Attachments: In-Reply-To: References: After working in the library for a while again, I created a bank from selected sounds in it. I saved the library, closed it; saved the bank, closed it; attempted to load the current bank into the bank editor to make sure my settings had been saved and got: MQ32 caused an invalid page fault in module INAMID32.DLL at 0137:006d48ea. Registers: EAX=00000000 CS=0137 EIP=006d48ea EFLGS=00010212 EBX=815a2fb8 SS=013f ESP=016bff04 EBP=016bff18 ECX=00012459 DS=013f ESI=00000001 FS=2f7f EDX=00000065 ES=013f EDI=00000001 GS=0000 Bytes at CS:EIP: 8b 04 4d 58 6c 6d 00 3b 45 08 75 5a ff 75 14 e8 Stack dump: 00000001 00000001 815a2fb8 000003c3 006d6c58 016bff34 bfe63892 82bdb0d4 000003c4 006d6c58 006d6d21 005580bd c0fda2d0 bfe63393 82bdb0d4 000003c4 To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: followup to "another crash & bug report" Cc: Bcc: X-Attachments: In-Reply-To: References: Subsequent to my previous message (see below), I am unable to get a bank from the TX81Z. HELP! I need to be able to work on this bank! Thanks. -= To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: followup to "another crash & bug report" Hello Stan, Sorry to hear about the problems. We have heard about very few crashes with v6.0 but you obviously are having some problems. First, there are some updated DLL files in the Download section of our web site at http://www.squest.com. Have you downloaded these? Second, what MIDI interface are you using and what drivers are you using with it. Finally, What version of Windows are you using? Actually, I am suspicious that you may be having problems with the MIDI drivers for the interface. That has been our most prevelent problem with v6.0. Please keep us informed. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, January 12, 1997 10:14 PM To: 76702,2205 Subject: followup to "another crash & bug report" Subsequent to my previous message (see below), I am unable to get a bank from the TX81Z. HELP! I need to be able to work on this bank! Thanks. -= From: "Stan (Sawyer) Stewart" Subject: RE: followup to "another crash & bug report" Cc: Bcc: X-Attachments: In-Reply-To: References: At 08:18 PM 1/13/97 EST, you wrote: >but you obviously are having some problems. First, there are some updated DLL >files in the Download section of our web site at http://www.squest.com. Have you Yes, I've added these updates. I downloaded them again to make sure the versions hadn't changed. (Shouldn't these change the output of the version number in the Help/About box? This is the normal routine.) >downloaded these? Second, what MIDI interface are you using and what drivers are MQ32/M. The drivers are the ones that came with it, version 1.02. There are no updates on the opcode web page. >you using with it. Finally, What version of Windows are you using? Actually, I Windows 95 (4.00.95.a). >am suspicious that you may be having problems with the MIDI drivers for the >interface. That has been our most prevelent problem with v6.0. Please keep us >informed. Why is it working for all other instruments, then? (two D110s, Wavestation SR, UltraProteus, M-OC1, XD-5, several effects, several synths for which I must use the generic drivers, etc.) > >Sincerely, > > >Michael Lambie >Sound Quest Inc. > >---------- >From: "Stan (Sawyer) Stewart" >Sent: Sunday, January 12, 1997 10:14 PM >To: 76702,2205 >Subject: followup to "another crash & bug report" > > >Subsequent to my previous message (see below), I am unable to get a bank >from the TX81Z. HELP! I need to be able to work on this bank! > >Thanks. > > -= > >===========Previous message====================================== >After working in the library for a while again, I created a bank from >selected sounds in it. I saved the library, closed it; saved the bank, >closed it; attempted to load the current bank into the bank editor to make >sure my settings had been saved and got: > >MQ32 caused an invalid page fault in >module INAMID32.DLL at 0137:006d48ea. >Registers: >EAX=00000000 CS=0137 EIP=006d48ea EFLGS=00010212 >EBX=815a2fb8 SS=013f ESP=016bff04 EBP=016bff18 >ECX=00012459 DS=013f ESI=00000001 FS=2f7f >EDX=00000065 ES=013f EDI=00000001 GS=0000 >Bytes at CS:EIP: >8b 04 4d 58 6c 6d 00 3b 45 08 75 5a ff 75 14 e8 >Stack dump: >00000001 00000001 815a2fb8 000003c3 006d6c58 016bff34 bfe63892 82bdb0d4 >000003c4 006d6c58 006d6d21 005580bd c0fda2d0 bfe63393 82bdb0d4 000003c4 > > > > To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: followup to "another crash & bug report" Cc: Bcc: X-Attachments: In-Reply-To: References: I'm not including all of the previous messages. Let me know if you need that information again. I'm the guy who is/was having problems loading a bank from a TX81Z (Windows 95 with MQ32/M, etc.). Here's what I did to fix it: 1. Remove the driver for the tx81z from the driver list. 2. Add the tx81z driver back into the list. 3. Tah-dah! It works again. This makes me very uncomfortable, but at least things are working again for now. Date: 14 Jan 97 05:11:13 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: followup to "another crash & bug report" Hello Stan, I'm glad to hear that you got things working. It sounds like something must have been written into the wrong memory area and this got saved. Anyway, if the problem starts repeating itself or you can give us any other insight to start working from we'd appreciate it. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, January 13, 1997 9:26 PM To: 76702,2205 Subject: RE: followup to "another crash & bug report" I'm not including all of the previous messages. Let me know if you need that information again. I'm the guy who is/was having problems loading a bank from a TX81Z (Windows 95 with MQ32/M, etc.). Here's what I did to fix it: 1. Remove the driver for the tx81z from the driver list. 2. Add the tx81z driver back into the list. 3. Tah-dah! It works again. This makes me very uncomfortable, but at least things are working again for now. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart qsource@aimnet.com resume at www.aimnet.com/~qsource/resume.html To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: another crash Cc: Bcc: X-Attachments: In-Reply-To: References: Tech Support, Windows 95 MQ32/M midi interface 1. Open Wavestation SR driver. Single click on Performance. 2. Click on N Lib button. Here's the crash dump: MQ32 caused an invalid page fault in module USER.EXE at 0011:00000971. Registers: EAX=00000001 CS=1727 EIP=00000971 EFLGS=00000206 EBX=00021604 SS=36b7 ESP=0000848a EBP=009f84a8 ECX=00023bc4 DS=16af ESI=00023bc4 FS=37d7 EDX=00010b6f ES=0b6f EDI=00001604 GS=34bf Bytes at CS:EIP: 26 8b 77 06 eb 03 8b 76 e8 83 7e f6 00 74 09 c4 Stack dump: 00023bc4 16040006 4ca80b6f 3b6800a7 00000002 7d010000 c1a600a7 84f40055 0000205e 16040000 00010b6f 00023bc4 856036b7 00060000 624c0000 16af0002 I sure hope I don't have to go through this with every driver in the lineup! -= Subject: another crash Cc: Bcc: X-Attachments: In-Reply-To: References: Tech Support, Windows 95 MQ32/M midi interface 1. Open Wavestation SR driver. Single click on Performance. 2. Click on N Lib button. Here's the crash dump: MQ32 caused an invalid page fault in module USER.EXE at 0011:00000971. Registers: EAX=00000001 CS=1727 EIP=00000971 EFLGS=00000206 EBX=00021604 SS=36b7 ESP=0000848a EBP=009f84a8 ECX=00023bc4 DS=16af ESI=00023bc4 FS=37d7 EDX=00010b6f ES=0b6f EDI=00001604 GS=34bf Bytes at CS:EIP: 26 8b 77 06 eb 03 8b 76 e8 83 7e f6 00 74 09 c4 Stack dump: 00023bc4 16040006 4ca80b6f 3b6800a7 00000002 7d010000 c1a600a7 84f40055 0000205e 16040000 00010b6f 00023bc4 856036b7 00060000 624c0000 16af0002 I sure hope I don't have to go through this with every driver in the lineup! -= Subject: crash when choosing not to save *again* Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM --nothing else running-- Wavestation SR driver: 1. Open BenHall.sql from the MidiQuest CD-ROM. 2. Browse patches for two minutes. (Realize the library is worthless without the underlying patches for the performances. 3. crash MQ32 caused an invalid page fault in module MQEDIT32.DLL at 0137:007275d2. Registers: EAX=00000000 CS=0137 EIP=007275d2 EFLGS=00010206 EBX=00a9e690 SS=013f ESP=009fb4ec EBP=009fb4f4 ECX=8009cb68 DS=013f ESI=000001ae FS=0d97 EDX=00000001 ES=013f EDI=00000000 GS=0000 Bytes at CS:EIP: 83 78 65 00 74 3e 8b 93 96 00 00 00 8b 72 65 8b Stack dump: 000001ae 00a9e690 009fb520 0072364b 00a9e690 00000000 00000005 00a9e690 00000000 00000000 000000c4 00000199 00000000 009fb53c 0052c0a9 00a9e690 ...then hose the whole system...(this should not happen if you're following the Windows95 API, by the way) MQ32 caused an exception c0000026H in module KERNEL32.DLL at 0137:bffb87cc. Registers: EAX=00000000 CS=0137 EIP=bffb87cc EFLGS=00000202 EBX=00000000 SS=013f ESP=009fb2ec EBP=009fb2fc ECX=009fb338 DS=013f ESI=009fb228 FS=0d97 EDX=009fb3f4 ES=013f EDI=815b6890 GS=0000 Bytes at CS:EIP: 5d 5f 5e 5b 8b e5 5d c3 8b 4c 24 04 f7 41 04 06 Stack dump: 009fb2fc bffb8a58 00000000 009fff68 009fb320 bffb88d7 009fff68 009fb320 009fb3f4 009fb410 009fff68 009fb3f4 009fb410 009fb344 bff7663c 009fb3f4 Let me know when you come up with some patches for version 6 again. -=< To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: crash when choosing not to save *again* Cc: Bcc: X-Attachments: In-Reply-To: References: Ooops, missed a step in the recreation: 2. Browse patches for two minutes. (Realize the library is worthless without the underlying patches for the performances.) 2b. Click on close box. Answer NO to "do you want to save". 3. crash... Should be easy to reproduce since this is the third time something like this has happened to me... -= Subject: Wavestation SR drivers Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) Bugs in Korg Wavestation SR drivers: (single) Performance. 1. Any edits or attempts to send "Current Data to Instrument" result in checksum errors on the instrument display. (Does this mean that I cannot trust that this data will ever be sent to the instrument in the correct form from the single Performance driver?) 2. Even though I load the patch banks, the patches are displayed with generic names (INT n) in the Performance editor. Question about "features" in the SR drivers: 1. If I am running MQ with any Wavestation SR parameters open and press any key on the SR that changes patch or editing parameter, the display reports that it's receiving sysex data. (It must be from MQ, because if I close it, the receives stop.) Is this as it should be? It seems unnecessecary. 2. What are System 2 and System 3 (they load sysex parameters only and not an editor)? Thanks. -= To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: another crash X-Status: A Hello Stan, We've got 4 emails here from you. We may answer them all in one message spread them out. 1. We can't recreate the crash on creating a Performance Library. Does this happen to you consistantly? Have you tried reloading the drivers? Did this make any difference? 2. Regarding crashes of the Wavestation Performance library after auditioning then closing the library. Again, I'm afraid we are unable to duplicate this. Are you using a library that was created under V6 or is the library older? If it is older, try creating a new library and move all of the patches/performances from the older to the newer library. This may take care of the problem. 3. System 2 and 3 are additional global SysX parameters which were not in the original Wavestation. We did not create editors for these. I believe that the parameters are related to some rarely used sample related features. You should be able to tell easily enough about them by looking in the SysX section of your manual. 4. One "feature" of MQ v6.0 is that if it receives patch change commands, and bank windows are open then the bank will jump to that patch and send it. This was to give some external control to the program and had been requested by a user. I think that is what is going on here except I don't know what the program should be doing anything with SysX changes. What we probably need to do is provide an enable/disable function for it. 5. Your INT n problem. You shouldn't have any problems with displaying the actual names in the instrument BUT, you have to have a "Patch Bank 1/2/3" open for the names to display. If you load a single bank of 35 names, this will not display. I think that is what is causing you problems. Can you confirm? 6. We can't see a problem with the Wavestation Performance and checksum as a single send but let me ask, if you click on Performances in a Performance bank to audition them, do you also get a checksum error? Please let me know. Finally, while thinking about your crash problems last night and wondering why you had them when we aren't getting calls from other people, I wondered whether you are running any virus protection software. Is there a possibility that the computer is infected and that this is the cause of some of your problems? Please keep us up to date. Sincerely Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Saturday, January 18, 1997 8:13 PM To: 76702,2205 Subject: another crash Tech Support, Windows 95 MQ32/M midi interface 1. Open Wavestation SR driver. Single click on Performance. 2. Click on N Lib button. Here's the crash dump: MQ32 caused an invalid page fault in module USER.EXE at 0011:00000971. Registers: EAX=00000001 CS=1727 EIP=00000971 EFLGS=00000206 EBX=00021604 SS=36b7 ESP=0000848a EBP=009f84a8 ECX=00023bc4 DS=16af ESI=00023bc4 FS=37d7 EDX=00010b6f ES=0b6f EDI=00001604 GS=34bf Bytes at CS:EIP: 26 8b 77 06 eb 03 8b 76 e8 83 7e f6 00 74 09 c4 Stack dump: 00023bc4 16040006 4ca80b6f 3b6800a7 00000002 7d010000 c1a600a7 84f40055 0000205e 16040000 00010b6f 00023bc4 856036b7 00060000 624c0000 16af0002 I sure hope I don't have to go through this with every driver in the lineup! -= To: Michael Lambie <76702.2205@CompuServe.COM> Subject: RE: another crash X-Status: Michael, Thank you for your thoughtful responses to my problems with MidiQuest. My answers and comments are embedded in your reply. On 21 Jan 1997, Michael Lambie wrote: > 1. We can't recreate the crash on creating a Performance Library. Does this > happen to you consistantly? Have you tried reloading the drivers? Did this make > any difference? I have not tried reloading the driver for the Wavestation. The reloaded TX81Z driver has also crashed when clicking on the N Lib button, so I don't think reloading the driver will necessarily help. > 2. Regarding crashes of the Wavestation Performance library after auditioning > then closing the library. Again, I'm afraid we are unable to duplicate this. Are > you using a library that was created under V6 or is the library older? If it is > older, try creating a new library and move all of the patches/performances from > the older to the newer library. This may take care of the problem. I have no old libraries. All were created with version 6. > 3. System 2 and 3 are additional global SysX parameters which were not in the Thanks for the info. > 4. One "feature" of MQ v6.0 is that if it receives patch change commands, and > bank windows are open then the bank will jump to that patch and send it. This > was to give some external control to the program and had been requested by a > user. I think that is what is going on here except I don't know what the program > should be doing anything with SysX changes. What we probably need to do is > provide an enable/disable function for it. Where is this documented? I think a toggle switch for this is a good idea. > 5. Your INT n problem. You shouldn't have any problems with displaying the > actual names in the instrument BUT, you have to have a "Patch Bank 1/2/3" open > for the names to display. If you load a single bank of 35 names, this will not > display. I think that is what is causing you problems. Can you confirm? I'll check this out tonight. Where is this fact documented? > 6. We can't see a problem with the Wavestation Performance and checksum as a > single send but let me ask, if you click on Performances in a Performance bank > to audition them, do you also get a checksum error? Please let me know. No. That seems to work fine. This seems to be a problem only with a single Performance editor. > Finally, while thinking about your crash problems last night and wondering why > you had them when we aren't getting calls from other people, I wondered whether > you are running any virus protection software. Is there a possibility that the > computer is infected and that this is the cause of some of your problems? I have constant virus protection with McAfee (perhaps I should shut this off and see if the crashes go away?) and periodically scan with F-Prot and Parsons Tech. virus scanner (whose name I can't remember right now). I doubt that viruses are the problem. -= From: "Stan (Sawyer) Stewart" Subject: RE: another crash Cc: Bcc: X-Attachments: In-Reply-To: References: At 11:25 AM 1/21/97 -0800, Stanley G. Stewart wrote: >On 21 Jan 1997, Michael Lambie wrote: >> 5. Your INT n problem. You shouldn't have any problems with displaying the >> actual names in the instrument BUT, you have to have a "Patch Bank 1/2/3" open >> for the names to display. If you load a single bank of 35 names, this will not >> display. I think that is what is causing you problems. Can you confirm? > >I'll check this out tonight. Where is this fact documented? Yes. Once I load the patches into a "Patch Bank 1/2/3", they display as names. I'd still like to see this documented more prominently as it is not an "intuitive" setup. -= To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: another crash Hello Stan, In fact, the information is not documented anywhere. We have added it to the Fast Tips files for the next driver release as per your suggestion. In most cases it doesn't seem to be an issue as most people are working with Groups where the appropriate bank is automatically loaded. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Tuesday, January 21, 1997 10:20 PM To: 76702,2205 Subject: RE: another crash Yes. Once I load the patches into a "Patch Bank 1/2/3", they display as names. I'd still like to see this documented more prominently as it is not an "intuitive" setup. -= Subject: crash when choosing not to save *again* Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, Michael: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) I'm really puzzled by the editor for the Roland M-OC1. I understand that you're sharing this editor with a host of other Roland products with similar characteristics, but some of the stuff does not show up in the editor correctly in my setup. If I load a "Performance" the pan, level and possibly other settings do not reflect what's in the instrument. For example, if I load Chamber Ensemble (performance 8), the parts are panned all over the place and the levels are set to various settings. However, the MQ6 editor shows everything at full volume and all panned center. Is this a bug, or am I missing something in the setup or editor? Next, the patch number is very confusing. I can look the patches up (on the instrument or in the manual or both) by number (1-226) or bank number (Bank 0, 1-128 and Bank 2, 1-98). But the editor displays the numbers as A nn, B nn, C nn and D nn. The A and C banks I can figure out easily because they are the first 64 of each Bank. The others take considerable figuring. (I'm a musician...not a mathemetician. ;-) Any chance of making the editor correspond to the instrument more on a 1:1 basis? Thanks. From: "Michael Lambie" To: Subject: Roland help Date: Sat, 25 Jan 1997 20:40:52 -0800 X-MSMail-Priority: Normal X-Mailer: Microsoft Internet Mail 4.70.1155 Hello Stan, First, we've modified the perform.sqt file for you and are including it in this email message. The patches will now be numbered from 1 - 238. Your other problem is more difficult. There is only one performance area in the instrument to load from, which is that data we are loading. Why this does not match what is in the instrument we do not know. There is either a bug in the firmware so the wrong data is being sent or more likely, when you choose a ROM performance it is not copied into the memory area that Midi Quest can access. Hence, the program can't load the settings. It wouldn't be the first time something strange like this has happened. Sincerely, Michael Lambie Sound Quest Inc. Attachment Converted: "D:\DL\Perform.sqt" To: "Michael Lambie" From: "Stan (Sawyer) Stewart" Subject: Re: Roland help Cc: Bcc: X-Attachments: In-Reply-To: References: Thanks for your quick reply. Do you prefer that I use this address (mlambie@squest.com) instead of the compu$erve one? At 08:40 PM 1/25/97 -0800, you wrote: >First, we've modified the perform.sqt file for you and are including it in >this email message. The patches will now be numbered from 1 - 238. Your OK. I'll try this out tomorrow. However, the numbers only go up to 226, so I'm already concerned. (Bank 0=128 and Bank 1=98. 128+98=226.) >other problem is more difficult. There is only one performance area in the >instrument to load from, which is that data we are loading. Why this does True. The only "user memory" in this box is the temporary area. >not match what is in the instrument we do not know. There is either a bug >in the firmware so the wrong data is being sent or more likely, when you >choose a ROM performance it is not copied into the memory area that Midi >Quest can access. Hence, the program can't load the settings. It wouldn't >be the first time something strange like this has happened. I don't understand. That's it? "There must be something wrong so we'll just leave it that way." That doesn't make any sense at all. If there's something wrong and you can show that it's Roland's fault, I'll talk with Roland. If there's something wrong with your driver, it needs to be fixed for the next release. Date: 26 Jan 97 14:04:59 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: Roland help Hello Stan, Thanks for the message. It doesn't matter which address you send to, I'll still get the message. To answer your questions: 1) The drivers are designed to work with all of the Sound Expansion modules. Each has a different number of voices so we just implemented to the maximum possible which is 255. I believe that if you were to select beyond that point, the instrument would just limit the number. 2) I guess I wasn't blunt enough. That is what the instrument is sending back and it sounds like it is incorrect. If you'd like to save a patch and email is to me I can look at the addressing and verify that it came from the correct instrument area but from your descriptrion I doubt that we could access the wrong memory area and get such a nice display. It also doesn't necessarily mean its wrong. The instrument may not place the ROM patch in the temporary area when it is using it. Hence, our software can't get access to the information. its a matter of how the internals of the instrument are programmed. Sincerely, Michael Lambie Sound Quest Inc. Thanks for your quick reply. Do you prefer that I use this address (mlambie@squest.com) instead of the compu$erve one? At 08:40 PM 1/25/97 -0800, you wrote: >First, we've modified the perform.sqt file for you and are including it in >this email message. The patches will now be numbered from 1 - 238. Your OK. I'll try this out tomorrow. However, the numbers only go up to 226, so I'm already concerned. (Bank 0=128 and Bank 1=98. 128+98=226.) >other problem is more difficult. There is only one performance area in the >instrument to load from, which is that data we are loading. Why this does True. The only "user memory" in this box is the temporary area. >not match what is in the instrument we do not know. There is either a bug >in the firmware so the wrong data is being sent or more likely, when you >choose a ROM performance it is not copied into the memory area that Midi >Quest can access. Hence, the program can't load the settings. It wouldn't >be the first time something strange like this has happened. I don't understand. That's it? "There must be something wrong so we'll just leave it that way." That doesn't make any sense at all. If there's something wrong and you can show that it's Roland's fault, I'll talk with Roland. If there's something wrong with your driver, it needs to be fixed for the next release. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: Roland help Cc: Bcc: X-Attachments: G:\Aps\MidiQuest\MQData\SoundExp\wrong.SYX; In-Reply-To: References: At 02:04 PM 1/26/97 EST, you wrote: >1) The drivers are designed to work with all of the Sound Expansion modules. >Each has a different number of voices so we just implemented to the maximum >possible which is 255. I believe that if you were to select beyond that point, >the instrument would just limit the number. FYI: 227-255 select patch 0! This appears to be patch 1 loaded with too much reverb. Beats me why this undocumented "feature" exists. >2) I guess I wasn't blunt enough. That is what the instrument is sending back >and it sounds like it is incorrect. If you'd like to save a patch and email is >to me I can look at the addressing and verify that it came from the correct >instrument area but from your descriptrion I doubt that we could access the >wrong memory area and get such a nice display. It also doesn't necessarily mean >its wrong. The instrument may not place the ROM patch in the temporary area when >it is using it. Hence, our software can't get access to the information. its a >matter of how the internals of the instrument are programmed. Here's what I tried: 1. Select Performance in the M-OC1 driver. Did an "Instrument to sysex view". Saved the information as a file. (See attached.) 2. Opened a Performance editor and saved as sysex. Since they were from the same temporary space in the M-OC1, the sizes/checksums of the files were the same. 3. Attempted to open the first sysex file via the Performance driver. Got this error message: "MidiX data is incompatible with Roland SoundExp Performance. The MidiX files is 438 bytes while the data files uses 426 bytes!" 4. Same results with the performance saved as sysex. It seems to me that I should be able to open both of these from the performance driver given that the instrument and driver match the expected data. Clearly, either the data or the driver is wrong, but it seems to me that the driver is suspect since even the sysex created from the driver (either via direct sysex or editor -> sysex) cannot be opened by the driver. I hope some of this is helpful in getting to the bottom of the problem. I assume that you have some sort of relationship with Roland and will talk with them if necessary? BTW: Subsequently, the SoundExp driver no longer functioned (i.e., it won't collect information from the M-OC1) until I rebooted the machine. (Other MIDI applications including a stand-alone editor for the Roland module still functioned normally at that point. Only MQ refused to talk with the M-OC1.) Good luck figuring out what the problem is. Date: 27 Jan 97 04:04:32 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: Roland help Hello Stan, Thanks for what you sent but it does us little good. It looks like what you did was receive a file and then export it to disk in MIDIX format instead of saving it in standard Sound Quest/Midi Quest format. Unfortunately, what this does is have the program "transmit" the data to disk instead of out MIDI and reformats the header information. It doesn't let us look at the untouched data that was received from the instrument. >From #4, no it is not clear that the driver or data is wrong. The MIDIX import function is an attempt to import the data and that is all. In some cases it will fail for certain and this is one of them. When saved in a Sound Quest format, the program only holds the data. When saved in MIDIX format the program first write a mode change command to switch into Performance mode. This creates a file of a different size which Midi Quest does not know how to import so you get the error. It would be possible to create a file conversion macro to accomate this easily but the program doesn't know how to do the import in an automated fashion. This is also the cause of the 12 byte discrepancy so it doesn't get us any further. However, it does give me a thought. It may be that when your instrument receives a mode switch command, it initializes the memory. You might want to try this and see if it makes a difference: 1) Make a copy of the Perform file in INSTR\SOUNDEXP but make all modifications to the original below, you can restore the original from the backup later if necessary 2) Choose "Utiliities/File Conversion window". 3) Click the RIGHT mouse button in the window to get the popup menus 4) Choose "Load Driver from Disk" (3rd from the bottom) 5) Use the file selector to enter the SOUNDEXP folder and choose the Perform driver 6) in the "Receive" macro select from the first character up to and including D 1000 (eg S 12 all the way to D1000) 7) Delete the selection 8) Choose "File/Save Driver" 9) Quit and rerun the program (you do not have to restart Windows) 10) Try your performance dump and see if there is any difference. 11) If you'd like me to look at the dump again, send me a file in Sound Quest format. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, January 26, 1997 10:07 PM To: 76702,2205 Subject: RE: Roland help Here's what I tried: 1. Select Performance in the M-OC1 driver. Did an "Instrument to sysex view". Saved the information as a file. (See attached.) 2. Opened a Performance editor and saved as sysex. Since they were from the same temporary space in the M-OC1, the sizes/checksums of the files were the same. 3. Attempted to open the first sysex file via the Performance driver. Got this error message: "MidiX data is incompatible with Roland SoundExp Performance. The MidiX files is 438 bytes while the data files uses 426 bytes!" 4. Same results with the performance saved as sysex. It seems to me that I should be able to open both of these from the performance driver given that the instrument and driver match the expected data. Clearly, either the data or the driver is wrong, but it seems to me that the driver is suspect since even the sysex created from the driver (either via direct sysex or editor -> sysex) cannot be opened by the driver. I hope some of this is helpful in getting to the bottom of the problem. I assume that you have some sort of relationship with Roland and will talk with them if necessary? BTW: Subsequently, the SoundExp driver no longer functioned (i.e., it won't collect information from the M-OC1) until I rebooted the machine. (Other MIDI applications including a stand-alone editor for the Roland module still functioned normally at that point. Only MQ refused to talk with the M-OC1.) Good luck figuring out what the problem is. --=====================_854372168==_ Content-Type: application/octet-stream; name="wrong.SYX" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="wrong.SYX" [content deleted] Content-Type: text/plain; charset="us-ascii" ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com --=====================_854372168==_-- Date: 27 Jan 97 04:05:01 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stanley G. Stewart\"'" Subject: RE: another crash Hello Stanley, Whoops, I didn't realize that this hadn't been answered for so long so about that. I'll try to cover as much as I can now. 1. We'll continue to puzzle over this one but you seem to be the only one having this problem. Our tech support people aren't hearing about it so we're really not sure what is going on. 4. See page 43 at the top. 5. Not documented but has been added to the Fast Tips files (I think I told you this before but I'll repeat just to make sure). 6. This is another "interesting" driver problem similar to #1. The code to send a Performance is identical to the code used to audition a patch in a bank. This would seem to imply that the macro itself has somehow been altered and again it seems to be a problem unique to yourself. 7. No it certainly doesn't seem like a virus problem with everything you have running. Something to try. In the Options menu there is a function call "Auto Update". Can you turn this OFF. Does it make any difference to your problems. Also, do you have more than one type of wavestation installed? Please keep me informed. Sincerely. Michael Lambie Sound Quest Inc. ---------- From: "Stanley G. Stewart" Sent: Tuesday, January 21, 1997 11:46 AM To: 76702,2205 Subject: RE: another crash Michael, Thank you for your thoughtful responses to my problems with MidiQuest. My answers and comments are embedded in your reply. On 21 Jan 1997, Michael Lambie wrote: > 1. We can't recreate the crash on creating a Performance Library. Does this > happen to you consistantly? Have you tried reloading the drivers? Did this make > any difference? I have not tried reloading the driver for the Wavestation. The reloaded TX81Z driver has also crashed when clicking on the N Lib button, so I don't think reloading the driver will necessarily help. > 2. Regarding crashes of the Wavestation Performance library after auditioning > then closing the library. Again, I'm afraid we are unable to duplicate this. Are > you using a library that was created under V6 or is the library older? If it is > older, try creating a new library and move all of the patches/performances from > the older to the newer library. This may take care of the problem. I have no old libraries. All were created with version 6. > 3. System 2 and 3 are additional global SysX parameters which were not in the Thanks for the info. > 4. One "feature" of MQ v6.0 is that if it receives patch change commands, and > bank windows are open then the bank will jump to that patch and send it. This > was to give some external control to the program and had been requested by a > user. I think that is what is going on here except I don't know what the program > should be doing anything with SysX changes. What we probably need to do is > provide an enable/disable function for it. Where is this documented? I think a toggle switch for this is a good idea. > 5. Your INT n problem. You shouldn't have any problems with displaying the > actual names in the instrument BUT, you have to have a "Patch Bank 1/2/3" open > for the names to display. If you load a single bank of 35 names, this will not > display. I think that is what is causing you problems. Can you confirm? I'll check this out tonight. Where is this fact documented? > 6. We can't see a problem with the Wavestation Performance and checksum as a > single send but let me ask, if you click on Performances in a Performance bank > to audition them, do you also get a checksum error? Please let me know. No. That seems to work fine. This seems to be a problem only with a single Performance editor. > Finally, while thinking about your crash problems last night and wondering why > you had them when we aren't getting calls from other people, I wondered whether > you are running any virus protection software. Is there a possibility that the > computer is infected and that this is the cause of some of your problems? I have constant virus protection with McAfee (perhaps I should shut this off and see if the crashes go away?) and periodically scan with F-Prot and Parsons Tech. virus scanner (whose name I can't remember right now). I doubt that viruses are the problem. -= From: "Stan (Sawyer) Stewart" Subject: RE: another crash Cc: Bcc: X-Attachments: In-Reply-To: References: At 04:05 AM 1/27/97 EST, you wrote: >4. See page 43 at the top. Passive voice is often difficult to understand. Instead of "If a patch change arrives at the port . . ." it would be easier to understand "If your instrument sends a patch change to the same MIDI channel . . ." >Something to try. In the Options menu there is a function call "Auto Update". >Can you turn this OFF. Does it make any difference to your problems. Also, do >you have more than one type of wavestation installed? I only have the SR. I'm thinking about getting a second SR. Will I have difficulty using 2 SR's with MQ (if I set the MIDI channel differently on each one)? >Please keep me informed. > >Sincerely. > > >Michael Lambie >Sound Quest Inc. > >---------- >From: "Stanley G. Stewart" >Sent: Tuesday, January 21, 1997 11:46 AM >To: 76702,2205 >Subject: RE: another crash > > >> 4. One "feature" of MQ v6.0 is that if it receives patch change commands, and >> bank windows are open then the bank will jump to that patch and send it. This >> was to give some external control to the program and had been requested by a >> user. I think that is what is going on here except I don't know what the >program >> should be doing anything with SysX changes. What we probably need to do is >> provide an enable/disable function for it. > >Where is this documented? I think a toggle switch for this is a good >idea. To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: Roland help Cc: Bcc: X-Attachments: G:\Aps\MidiQuest\MQData\SoundExp\still-wrong.Pfm;G:\Aps\MidiQuest\MQData\SoundExp\wrong.Pfm; In-Reply-To: References: Michael, Based on your respone, MidiX should not be included in the Open section of the driver menu. This is extremely misleading since it implies that sysex can be opened into the driver. I should have known I suppose, since I had to fuss with the sysex "file conversion" stuff enough. Here's the same thing in MQ format. I've also included the one that was created after I edited the Perform driver. By the way, you meant Driver Creator Window, not File Conversion Window. (I wasted all of my "music" time tonight figuring out that your instructions were pointing me to the wrong place!) -=1) Make a copy of the Perform file in INSTR\SOUNDEXP but make all modifications >to the original below, you can restore the original from the backup later if >necessary >2) Choose "Utiliities/File Conversion window". >3) Click the RIGHT mouse button in the window to get the popup menus >4) Choose "Load Driver from Disk" (3rd from the bottom) >5) Use the file selector to enter the SOUNDEXP folder and choose the Perform >driver >6) in the "Receive" macro select from the first character up to and including D >1000 (eg S 12 all the way to D1000) >7) Delete the selection >8) Choose "File/Save Driver" >9) Quit and rerun the program (you do not have to restart Windows) >10) Try your performance dump and see if there is any difference. >11) If you'd like me to look at the dump again, send me a file in Sound Quest >format. Received: from dub-mail-svc-1.compuserve.com (dub-mail-svc-1.compuserve.com [149.174.213.4]) by aimnet.com (8.8.4/8.7.1) with SMTP id AAA16975 for ; Tue, 28 Jan 1997 00:14:24 -0800 (PST) Received: from none.compuserve.com (hd63-017.compuserve.com [199.174.244.17]) by dub-mail-svc-1.compuserve.com (8.6.10/8.6.9) with ESMTP id DAA18118.; Tue, 28 Jan 1997 03:14:21 -0500 Message-Id: <199701280814.DAA18118@dub-mail-svc-1.compuserve.com> From: "Michael Lambie" To: Subject: modified driver Date: Tue, 28 Jan 1997 00:12:14 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC0CAF.EA491740" Here's the driver Attachment Converted: "D:\DL\Perform" Date: 28 Jan 97 03:12:39 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: Roland help Hello Stan, Thanks for the message. 1) I'm sorry I pointed you to the wrong window. I'd guess I was still thinking about the import option provided by the File Conversion Window and wrote that instead of the correct window name. 2) SysX can be opened into the driver, just not in all cases and Roland is particularly problematic in this area because the same instrument can frequently transmit the same SysX data in different ways depending on the ROM version and it may also not match the way that we are pulling out the SysX data. This function should work with about 75% of instruments. As to its placement in the Open menu, this function is not supposed to be "technical" so we didn't want to hide it in the File Conversion Window because we felt that people would not look there. Do you have a suggestions as to where we should place it? Seeing as you have asked for references and documentation in the past, I pulled this from the MQ help file in the Open MidiX section so you could have a read: Note1: this function will not work for all MidiX files. For the importation to work, the MidiX file must contain only the type of data you are trying to load. For example, if you are trying to import a Kawai K1 Patch Bank but the MidiX file contains data other than a Patch Bank or both a Patch Bank and a Multi Bank, the data is not imported correctly. In these situations, you will need to use the File Conversion Window to write a macro to perform the conversion. Note2: This direct MidiX importation will NOT work with most Roland MidiX data dumps because of the inconsistent way that Roland instruments dump SysX data. 3) Fix them. As you seem anxious to try and get this working we made a suggestion for you to try. We would not in any way be offended if you said "sorry I don't have time for this". And the reason we asked you to try it is that we have found over the years that there can be problems with specific ROM versions and this has been particularly prevelent with Roland instruments. There are many ROM versions of the D-10, D-5, D-50, D-70, D-110, MT-32, SC-55, etc where the SysX does not work properly on the instrument, period. We find this out by working with the customer because if we ask for an instrument from Roland we usually get a different ROM and different results from the person experiencing the problem. 4) Forget my suggestion of trying to remove part of the driver code. I'll do it and email it to you and give it a try, if that is too much to ask, please let me know. 5) Regarding the file conversion macro, SysX is to variable to be able to cover every possibility with automation and again Roland is the most difficult to deal with. The automated functions will successfully handle probably 80% of instrument data thrown at it but not this. That is why we created a macro drive system so that code could be written to take care of the situations that don't fit but it does require that you understand what you are doing. Based on the MIDIX file you generated and sent to us, I believe (untested) that the macro you would use is: DS 12 DR 426 0 This macro skips the first 12 bytes which you don't want and then reads in the next 426 which you do want to import this particular output MIDIX file into the program. 6) in response to your last comment, the macro that the File conversion window uses looks nothing like the macros that the Driver Creator uses. They're doing two different things and you can't compare them. Now, looking at what you sent - the data has a title of "Brs.Fanfare". Was this the perfornance you had selected when you did the dumps? For your info, that data that is being sent is addressed correctly. If you can manage the time, please try the modified driver I will send you. Just have it overwrite the original, select a performance on the instrument and try loading it with the software. If it loads, wonderful. If not, we'll go from there but it will probably come down to one of two different possibilities. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, January 27, 1997 9:19 PM To: 76702,2205 Subject: RE: Roland help Michael, Based on your respone, MidiX should not be included in the Open section of the driver menu. This is extremely misleading since it implies that sysex can be opened into the driver. I should have known I suppose, since I had to fuss with the sysex "file conversion" stuff enough. Here's the same thing in MQ format. I've also included the one that was created after I edited the Perform driver. By the way, you meant Driver Creator Window, not File Conversion Window. (I wasted all of my "music" time tonight figuring out that your instructions were pointing me to the wrong place!) -= From: "Stan (Sawyer) Stewart" Subject: RE: Roland help Cc: Bcc: X-Attachments: In-Reply-To: References: At 03:12 AM 1/28/97 EST, you wrote: >Thanks for the message. And thank you for your prompt reply. Your tech support level has improved significantly over the years. >1) I'm sorry I pointed you to the wrong window. I'd guess I was still thinking ... >2) SysX can be opened into the driver, just not in all cases and Roland is >particularly problematic in this area because the same instrument can frequently ... >Seeing as you have asked for references and documentation in the past, I pulled >this from the MQ help file in the Open MidiX section so you could have a read: ... >Note2: This direct MidiX importation will NOT work with most Roland MidiX data >dumps because of the inconsistent way that Roland instruments dump SysX data. I do vaguely remember seeing that note, but I did not recall it during my frustration last night. Why not detect that the driver is Roland and grey out the option on the menu. >3) Fix them. As you seem anxious to try and get this working we made a >suggestion for you to try. We would not in any way be offended if you said >"sorry I don't have time for this". And the reason we asked you to try it is >that we have found over the years that there can be problems with specific ROM >versions and this has been particularly prevelent with Roland instruments. There >are many ROM versions of the D-10, D-5, D-50, D-70, D-110, MT-32, SC-55, etc >where the SysX does not work properly on the instrument, period. We find this >out by working with the customer because if we ask for an instrument from Roland >we usually get a different ROM and different results from the person >experiencing the problem. > >4) Forget my suggestion of trying to remove part of the driver code. I'll do it >and email it to you and give it a try, if that is too much to ask, please let me >know. I already did this. I stripped the "S 12 . . . D 1000" out of the Recieve Macro and did a second dump of the same Performance. I attached both results to my previous message. i.e., I've already given it a try and sent you the results. I don't think they're going to be helpful to you, but if you like, I can attach them to another message. >5) Regarding the file conversion macro, SysX is to variable to be able to cover >every possibility with automation and again Roland is the most difficult to deal >with. The automated functions will successfully handle probably 80% of >instrument data thrown at it but not this. That is why we created a macro drive >system so that code could be written to take care of the situations that don't >fit but it does require that you understand what you are doing. > >Based on the MIDIX file you generated and sent to us, I believe (untested) that >the macro you would use is: > > DS 12 DR 426 0 > >This macro skips the first 12 bytes which you don't want and then reads in the >next 426 which you do want to import this particular output MIDIX file into the >program. Why are you telling me this? That whole section of my message was prefaced with ********************** Junked message (after I discovered that I'd wasted my whole evening) ********************** i.e., forget the following information because it no longer applies. >6) in response to your last comment, the macro that the File conversion window >uses looks nothing like the macros that the Driver Creator uses. They're doing >two different things and you can't compare them. I know. I explained to you that I had to go through this discovery process last night. Furthermore the File Conversion stuff was all below the line mentioned above. i.e., it was part of the stuff that you could ignore. I just wanted it included there for my own documentation of what I've been doing to assist you with working on your product. >Now, looking at what you sent - the data has a title of "Brs.Fanfare". Was this >the perfornance you had selected when you did the dumps? For your info, that Yes. >data that is being sent is addressed correctly. If you can manage the time, "addressed correctly"? I don't know what that means, but the output on the screen is not what's in the instrument!!! >please try the modified driver I will send you. Just have it overwrite the >original, select a performance on the instrument and try loading it with the >software. If it loads, wonderful. If not, we'll go from there but it will >probably come down to one of two different possibilities. Please verify if I still need to do this, since I already did it once. Date: 28 Jan 97 13:03:11 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: Roland help X-Status: Hello Stan, This numbering isn't related to your message's numbering. I'm just makeing the elements distinct. 1) The reason that we don't grey it out is that in some cases it works. If the MIDIX file didn't have the mode switch message at the from it would import fine. Its one of those no win scenarios, you're not happy because its not greyed out. Someone else won't be happy because they know they have a file which will validly import but the function is greyed out. 2) Yes, please retry the dump with the new driver I sent you. Both of the files that you emailed previously were created with the S 12 .... D 1000 intact. I checked the files. I'd suggest renaming the "Perform" file you have now and then copy in the one I emailed to you. 3) Sorry, I didn't realize that your intent was for me to discregard the rest of the message. It was late. 4) Sorry about the "addressed correctly" reference. Roland uses the concept of addresses in their instruments memory. To get the performance settings you request data from a certain "memory address". I just lapsed into using their terminology. 5) Finally, I'll confirm it when I see the Performance dump from #2 above but based on the fact that the Performance name is correct from the previous sample dumps, I expect that the instrument itself is not dumping the settings correctly. There may be a ROM update from Roland that will fix the problem. We'll find out later. Mike Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Tuesday, January 28, 1997 7:38 AM To: 76702,2205 Subject: RE: Roland help At 03:12 AM 1/28/97 EST, you wrote: >Thanks for the message. And thank you for your prompt reply. Your tech support level has improved significantly over the years. >1) I'm sorry I pointed you to the wrong window. I'd guess I was still thinking ... >2) SysX can be opened into the driver, just not in all cases and Roland is >particularly problematic in this area because the same instrument can frequently ... >Seeing as you have asked for references and documentation in the past, I pulled >this from the MQ help file in the Open MidiX section so you could have a read: ... >Note2: This direct MidiX importation will NOT work with most Roland MidiX data >dumps because of the inconsistent way that Roland instruments dump SysX data. I do vaguely remember seeing that note, but I did not recall it during my frustration last night. Why not detect that the driver is Roland and grey out the option on the menu. >3) Fix them. As you seem anxious to try and get this working we made a >suggestion for you to try. We would not in any way be offended if you said >"sorry I don't have time for this". And the reason we asked you to try it is >that we have found over the years that there can be problems with specific ROM >versions and this has been particularly prevelent with Roland instruments. There >are many ROM versions of the D-10, D-5, D-50, D-70, D-110, MT-32, SC-55, etc >where the SysX does not work properly on the instrument, period. We find this >out by working with the customer because if we ask for an instrument from Roland >we usually get a different ROM and different results from the person >experiencing the problem. > >4) Forget my suggestion of trying to remove part of the driver code. I'll do it >and email it to you and give it a try, if that is too much to ask, please let me >know. I already did this. I stripped the "S 12 . . . D 1000" out of the Recieve Macro and did a second dump of the same Performance. I attached both results to my previous message. i.e., I've already given it a try and sent you the results. I don't think they're going to be helpful to you, but if you like, I can attach them to another message. >5) Regarding the file conversion macro, SysX is to variable to be able to cover >every possibility with automation and again Roland is the most difficult to deal >with. The automated functions will successfully handle probably 80% of >instrument data thrown at it but not this. That is why we created a macro drive >system so that code could be written to take care of the situations that don't >fit but it does require that you understand what you are doing. > >Based on the MIDIX file you generated and sent to us, I believe (untested) that >the macro you would use is: > > DS 12 DR 426 0 > >This macro skips the first 12 bytes which you don't want and then reads in the >next 426 which you do want to import this particular output MIDIX file into the >program. Why are you telling me this? That whole section of my message was prefaced with ********************** Junked message (after I discovered that I'd wasted my whole evening) ********************** i.e., forget the following information because it no longer applies. >6) in response to your last comment, the macro that the File conversion window >uses looks nothing like the macros that the Driver Creator uses. They're doing >two different things and you can't compare them. I know. I explained to you that I had to go through this discovery process last night. Furthermore the File Conversion stuff was all below the line mentioned above. i.e., it was part of the stuff that you could ignore. I just wanted it included there for my own documentation of what I've been doing to assist you with working on your product. >Now, looking at what you sent - the data has a title of "Brs.Fanfare". Was this >the perfornance you had selected when you did the dumps? For your info, that Yes. >data that is being sent is addressed correctly. If you can manage the time, "addressed correctly"? I don't know what that means, but the output on the screen is not what's in the instrument!!! >please try the modified driver I will send you. Just have it overwrite the >original, select a performance on the instrument and try loading it with the >software. If it loads, wonderful. If not, we'll go from there but it will >probably come down to one of two different possibilities. Please verify if I still need to do this, since I already did it once. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: Roland help Cc: Bcc: X-Attachments: G:\Aps\MidiQuest\MQData\SoundExp\wrong3.Pfm; In-Reply-To: References: At 01:03 PM 1/28/97 EST, you wrote: >2) Yes, please retry the dump with the new driver I sent you. Both of the files >that you emailed previously were created with the S 12 .... D 1000 intact. I >checked the files. I'd suggest renaming the "Perform" file you have now and then >copy in the one I emailed to you. ... >5) Finally, I'll confirm it when I see the Performance dump from #2 above but >based on the fact that the Performance name is correct from the previous sample >dumps, I expect that the instrument itself is not dumping the settings >correctly. There may be a ROM update from Roland that will fix the problem. >We'll find out later. Attached is the new dump using the "Perform" you attached to a previous message. The checksum on the files is different, but they look the same in the editor. FYI, I have my workaround: edit the data in MQ and _then_ save the file. If I do it this way, the data is correct both when loaded fresh from the instrument and when saved/restored from disk. (i.e., the only time things don't work is when I select a new performance on the M-OC1 and then load it into MQ.) To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: UltraProteus Cc: Bcc: X-Attachments: In-Reply-To: References: Hello, SoundQuest (i.e., Michael Lambie): Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) I can't tell if this is a bug or what, but it sure is annoying... With a patch bank for the UltraProteus loaded (uses the Morpheus driver which seems to be _mostly_ compatible but has wrong names for some filters) when I select a patch it sends a patch change to the unit but apparently sends a bank change as well. i.e., it selects patch 000 from the CARD rather than from RAM. Since I have no card loaded this is useless and means that I must go to the unit each time and select RAM 000 where the patch has been successfully loaded. This one is definately a bug: I load the "Global" edit from the UltraProteus and attempt to select a new "Current Single Program" by sliding my mouse in the patch name and get a "This program has performed an illegal operation. Here's the output: MQ32 caused an invalid page fault in module MQBASI32.DLL at 0137:00610dec. Registers: EAX=00a94768 CS=0137 EIP=00610dec EFLGS=00010206 EBX=000469d2 SS=013f ESP=009febb4 EBP=009febc8 ECX=00a94768 DS=013f ESI=00a6e8cc FS=2c2f EDX=00000000 ES=013f EDI=000469d2 GS=0000 Bytes at CS:EIP: 0f b6 3c 1e 33 c0 8a 44 1e 01 c1 e0 07 66 0b f8 Stack dump: 00a6000c 009ff02c 00000000 009febd4 0055b8d4 009febec 006122a8 00000000 000469d2 00a6e8cc 00a94768 009ff02c 00a6e8cc 00a94768 009fec24 00611f63 When I close that error window, I get this: MQ32 caused an invalid page fault in module MQBASI32.DLL at 0137:00610dec. Registers: EAX=00a94768 CS=0137 EIP=00610dec EFLGS=00010206 EBX=000469d2 SS=013f ESP=009febb4 EBP=009febc8 ECX=00a94768 DS=013f ESI=00a6e8cc FS=2c2f EDX=00000000 ES=013f EDI=000469d2 GS=0000 Bytes at CS:EIP: 0f b6 3c 1e 33 c0 8a 44 1e 01 c1 e0 07 66 0b f8 Stack dump: 00a6000c 009ff02c 00000000 009febd4 0055b8d4 009febec 006122a8 00000000 000469d2 00a6e8cc 00a94768 009ff02c 00a6e8cc 00a94768 009fec24 00611f63 close that one and MQ kills KERNEL32.DLL and I must restart. -= Subject: more on the UP Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) UltraProteus. Even though MIDI MODE CHANGE is disabled on my UP, MQ continuously changes the mode back to OMNI. In doing this, the UP switches to the patch sent to the patch bay and everything is out of sync. -= To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: UltraProteus Hi Stan, Thanks for the message. Regarding the Ultra Proteus, Midi Quest never sends bank select messages so there must be something in your instrument. Is it possible that your patch change table has been programmed to switch to the CARD bank when patch change command for patch 0 is received? Regarding your crash, we couldn't get it to crash our system but I believe that we did find the problem. Please look for updated files on our web site shortly and please let us know if there is still a problem. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, February 09, 1997 8:28 PM To: 76702,2205 Subject: UltraProteus Hello, SoundQuest (i.e., Michael Lambie): Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) I can't tell if this is a bug or what, but it sure is annoying... With a patch bank for the UltraProteus loaded (uses the Morpheus driver which seems to be _mostly_ compatible but has wrong names for some filters) when I select a patch it sends a patch change to the unit but apparently sends a bank change as well. i.e., it selects patch 000 from the CARD rather than from RAM. Since I have no card loaded this is useless and means that I must go to the unit each time and select RAM 000 where the patch has been successfully loaded. This one is definately a bug: I load the "Global" edit from the UltraProteus and attempt to select a new "Current Single Program" by sliding my mouse in the patch name and get a "This program has performed an illegal operation. Here's the output: close that one and MQ kills KERNEL32.DLL and I must restart. -=; Mon, 10 Feb 1997 14:19:17 -0800 (PST) Received: by arl-img-2.compuserve.com (8.6.10/5.950515) id RAA15564; Mon, 10 Feb 1997 17:18:46 -0500 Date: 10 Feb 97 17:13:40 EST X-UIDL: 855614117.002 From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: more on the UP Message-ID: <970210221340_76702.2205_CHN78-2@CompuServe.COM> Content-Type: text Status: U Hi Stan, MQ never actually sends mode change messages anywhere in the program. We think that the instrument itself must be programmed to change modes when it receives some type of SysX message. We must be sending the messages it is looking for, probably a plain patch message. You'd have to talk to Emu to verify. (I assume you're talking about having the patch bay control functions active in Midi Quest here.) By the way, which patch bay are you using out of curiosity? Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, February 09, 1997 8:58 PM To: 76702,2205 Subject: more on the UP Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) UltraProteus. Even though MIDI MODE CHANGE is disabled on my UP, MQ continuously changes the mode back to OMNI. In doing this, the UP switches to the patch sent to the patch bay and everything is out of sync. -= From: "Stan (Sawyer) Stewart" Subject: RE: more on the UP Cc: Bcc: X-Attachments: In-Reply-To: References: At 05:13 PM 2/10/97 EST, you wrote: >MQ never actually sends mode change messages anywhere in the program. We think >that the instrument itself must be programmed to change modes when it receives >some type of SysX message. We must be sending the messages it is looking for, >probably a plain patch message. You'd have to talk to Emu to verify. (I assume >you're talking about having the patch bay control functions active in Midi >Quest here.) By the way, which patch bay are you using out of curiosity? I'm using a KMX Midi Central (also known as a Kawai KMX-16 in some circles) for the racks that include the UltraProteus. I also use an MX-8, but it gets output from a different MIDI out on my MQ32/M card (from my computer). After some experimentation, I discovered that the UP only gets switched to OMNI if it was in POLY or MONO modes. If in Multi, it stays there. Go figure. Thanks for your reply. -= From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus Cc: Bcc: X-Attachments: In-Reply-To: References: At 05:13 PM 2/10/97 EST, you wrote: >Thanks for the message. And for your reply. >Regarding the Ultra Proteus, Midi Quest never sends bank select messages so >there must be something in your instrument. Is it possible that your patch >change table has been programmed to switch to the CARD bank when patch change >command for patch 0 is received? No program table and set to bank 0 so I don't know what happened. However, after resetting everything three times and re-installing the driver for the fourth time, things finally work. (I still say I should not have to do this to make things work!) I also noticed that in the "Global" editor, the patches show up as outrageous numbers in the 400-600 range even though the instrument only numbers 0-127 in the four banks. i.e., next to the RAM patch 5, MQ would display 511. Strange. >Regarding your crash, we couldn't get it to crash our system but I believe that >we did find the problem. Please look for updated files on our web site shortly >and please let us know if there is still a problem. OK. I'll look forward to the update. To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: crash when choosing not to save *again* Cc: Bcc: X-Attachments: In-Reply-To: References: I said: >I'm using a KMX Midi Central (also known as a Kawai KMX-16 in some circles) Not Kawai. Ensoniq. -= Subject: Drv Auto Update Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) You've probably already noted this, but the sub-menu from Drv Auto Update should not read expect ... Instead, it should say except ... Date: 11 Feb 97 11:13:47 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: UltraProteus X-Status: Hi Stan, No, you shouldn't have to install files multiple times, I doubt that that is the problem. In future if something strange happens you could try deleting any file in the Midi Quest folder ending in .CFG. The program will rebuild them the next time it is run. I don't know why but in the past that has solved some strange ones. Regarding the numbering on the UP, the range ends up being 0 - 639 as that is how it is programmed internally (5 banks * 128 patches). The updated files, which are now posted, not only have a fix but have also been modified so that in a Group you will see the various patches by name. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, February 10, 1997 8:39 PM To: 76702,2205 Subject: RE: UltraProteus And for your reply. >Regarding the Ultra Proteus, Midi Quest never sends bank select messages so >there must be something in your instrument. Is it possible that your patch >change table has been programmed to switch to the CARD bank when patch change >command for patch 0 is received? No program table and set to bank 0 so I don't know what happened. However, after resetting everything three times and re-installing the driver for the fourth time, things finally work. (I still say I should not have to do this to make things work!) I also noticed that in the "Global" editor, the patches show up as outrageous numbers in the 400-600 range even though the instrument only numbers 0-127 in the four banks. i.e., next to the RAM patch 5, MQ would display 511. Strange. >Regarding your crash, we couldn't get it to crash our system but I believe that >we did find the problem. Please look for updated files on our web site shortly >and please let us know if there is still a problem. OK. I'll look forward to the update. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com Date: 11 Feb 97 11:13:51 EST From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: Drv Auto Update X-Status: Hi Stan, Thanks. Actually, we hadn't noticed and neither had anyone else and I was looking at that function just a couple of days ago. Mike Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, February 10, 1997 11:06 PM To: 76702,2205 Subject: Drv Auto Update Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) You've probably already noted this, but the sub-menu from Drv Auto Update should not read expect ... Instead, it should say except ... ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: References: Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) Michael, The UltraProteus drive changes the MIDI Mode to OMNI _every_ time that I request either a single program or a bank of programs. This is a repeatable bug to the point that when I leave the Master button set to the MIDI Mode page and request a program from Midiquest, I can _watch_ the mode change on the screen. Because MQ and the unit are out of sync (the patch change request sent to the patch bay means that it's on the wrong program #), I can't get MQ to edit patches. (Yes. I have disabled MIDI Mode Change on the UltraProteus.) Please fix this as it makes editing programs via MQ impossible. If you know of a work-around for this problem, please let me know what it is. Date: 28 Apr 97 02:04:26 EDT From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: UltraProteus MIDI Mode Hello Stan, Thanks for the message but sorry can't do. The instrument is changing the mode on its own. We're not doing it and we don't have any control over it. That said, there's a bit of this that I don't follow. From your comment can I assume you are using a patch bay and that you have you have PBay in the Driver List window set to the channel of the patch bay? If so what is the channel its using? If this is correct, is that patch bay changing its configuration properly? Also, is the Proteus receiving this patch change command as well? Now, what is the Midi Channel set to in Midi Quest for the UProteus? Does the Proteus jump to this patch? Is this the point at which it changes modes? What patch number do you request and what do you get? If you don't fight the mode change, what happens next time you make the request? What is the behavior like if you bypass the patch bay and go directly to the instrument? Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, April 27, 1997 8:30 PM To: 76702,2205 Subject: UltraProteus MIDI Mode Hi, again: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) Michael, The UltraProteus drive changes the MIDI Mode to OMNI _every_ time that I request either a single program or a bank of programs. This is a repeatable bug to the point that when I leave the Master button set to the MIDI Mode page and request a program from Midiquest, I can _watch_ the mode change on the screen. Because MQ and the unit are out of sync (the patch change request sent to the patch bay means that it's on the wrong program #), I can't get MQ to edit patches. (Yes. I have disabled MIDI Mode Change on the UltraProteus.) Please fix this as it makes editing programs via MQ impossible. If you know of a work-around for this problem, please let me know what it is. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970428060425_76702.2205_CHN44-1@CompuServe.COM> References: At 02:04 AM 4/28/97 EDT, you wrote: >Thanks for the message but sorry can't do. The instrument is changing the mode >on its own. We're not doing it and we don't have any control over it. I also use a dedicated UltraProteus (UP) editor. It changes the patch on the patch bay, too but does not change the MIDI mode on the UP. >That said, there's a bit of this that I don't follow. From your comment can I >assume you are using a patch bay and that you have you have PBay in the Driver >List window set to the channel of the patch bay? If so what is the channel its Yes. I have the PBay set to channel two for my patch bay. >using? If this is correct, is that patch bay changing its configuration >properly? Also, is the Proteus receiving this patch change command as well? Now, The patch bay changes to patch 5 as requested. The UP gets this patch change as well (because it is in OMNI mode now). >what is the Midi Channel set to in Midi Quest for the UProteus? Does the Proteus The UP is on channel nine (9). >jump to this patch? Is this the point at which it changes modes? What patch Yes. It jumps to this patch, but it could NOT do this until after it changes to OMNI mode. (Believe me. I've done enough experimentation trying to get MQ to work to know exactly what will and won't change patches on the UP.) >number do you request and what do you get? If you don't fight the mode change, I request different patches. Recent examples were 66 and 45. These patches come up in the editor (but they are not editable, since that's NOT what is displayed in the UP). >what happens next time you make the request? What is the behavior like if you The next time I make the request the same thing happens. The correct patch number loads into the editor, but the UP is switched back to patch 5 (via OMNI and settings sent to the patch bay). Once again, I am unable to adjust the patch because the settings are out of sync. One really bad thing is that patch 0 and patch 5 on the UP are totally wonky and unuseable since all the parameters I send from MQ seem to go to one of these two patches. >bypass the patch bay and go directly to the instrument? I don't know since this completely defeats the purpose of having a nice setup like mine. As I mentioned above, I have UP dedicated software that works great. I'd just prefer to use the integrated editor/ librarian in MQ. Unfortunately, this is impossible at this point. Please send a work around. Thank you. -=Michael Lambie >Sound Quest Inc. Date: 28 Apr 97 14:04:02 EDT From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: UltraProteus MIDI Mode X-Status: Hello Stan, Thanks for the message. I also use a dedicated UltraProteus (UP) editor. It changes the patch on the patch bay, too but does not change the MIDI mode on the UP. Obviously I don't know your precise configuration but I do know that we are not sending any commands to change the MIDI mode on the instrument. All we do is send out a patch change using the channel and patch number you select. If your patch bay is passing the patch change intended just for it through to the instrument, can you reconfigure the patch bay so that it filters out (doesn't pass on) the patch changes on channel 2? >That said, there's a bit of this that I don't follow. From your comment can I >assume you are using a patch bay and that you have you have PBay in the Driver >List window set to the channel of the patch bay? If so what is the channel its Yes. I have the PBay set to channel two for my patch bay. >using? If this is correct, is that patch bay changing its configuration >properly? Also, is the Proteus receiving this patch change command as well? Now, The patch bay changes to patch 5 as requested. The UP gets this patch change as well (because it is in OMNI mode now). >what is the Midi Channel set to in Midi Quest for the UProteus? Does the Proteus The UP is on channel nine (9). The UP's basic channel is 9? And the Midi channel set on Midi Quest is also 9? What ID number are you using on the UP? >jump to this patch? Is this the point at which it changes modes? What patch Yes. It jumps to this patch, but it could NOT do this until after it changes to OMNI mode. (Believe me. I've done enough experimentation trying to get MQ to work to know exactly what will and won't change patches on the UP.) >number do you request and what do you get? If you don't fight the mode change, I request different patches. Recent examples were 66 and 45. These patches come up in the editor (but they are not editable, since that's NOT what is displayed in the UP). >what happens next time you make the request? What is the behavior like if you The next time I make the request the same thing happens. The correct patch number loads into the editor, but the UP is switched back to patch 5 (via OMNI and settings sent to the patch bay). Once again, I am unable to adjust the patch because the settings are out of sync. One really bad thing is that patch 0 and patch 5 on the UP are totally wonky and unuseable since all the parameters I send from MQ seem to go to one of these two patches. FYI. There is no buffer in the UP to send to so we must transmit to a memory location. Patch 0 is used for auditioning from banks and whatever patch is selected in the PCH # is used when editing patches, either from a bank or individually. As a result, patch 0 is changed frequently. I don't know why patch 5 should be anything other than what you last sent to it. >bypass the patch bay and go directly to the instrument? I don't know since this completely defeats the purpose of having a nice setup like mine. As I mentioned above, I have UP dedicated software that works great. I'd just prefer to use the integrated editor/ librarian in MQ. Unfortunately, this is impossible at this point. This was not meant to be a permanent solution but was meant to be a test. If you bypass the patch bay, do you get the same behavior? The patch to change the patch bay is obviously being passed through to the UP. What I want to know is if the patch bay isn't there and you send the same set of commands, does the UP switch to omni mode? One last question, have you modified your Patch Map or is it still mapped 0 - 127 for patch changes 0 - 127? I know you're not going to like this last bit but I need to pass it along. I doubt the problem is in Midi Quest but is likely somewhere else in the system. Possibly, the UP but based on history, more likely the patch bay. We are forever seeing problems with them. Its extremely difficult to diagnose a problem with a patch bay in the system because in most cases, when you remove the patch bay the problem also disappears. This is why we need to know how the system behaves without the patch bay connected. I look forward to receiving your answers. Sincerely, Michael Lambie Sound Quest Inc. Date: Mon, 28 Apr 1997 13:10:13 -0700 (PDT) From: "Stanley G. Stewart" Reply-To: "Stanley G. Stewart" To: Michael Lambie <76702.2205@CompuServe.COM> Subject: RE: UltraProteus MIDI Mode X-Status: On 28 Apr 1997, Michael Lambie wrote: > Hello Stan, > > Thanks for the message. > > I also use a dedicated UltraProteus (UP) editor. It changes the patch on > the patch bay, too but does not change the MIDI mode on the UP. Let me explain why this part of my message was important, Michael. First, it shows that getting the software to do the right thing is possible. Second, it suggests that the problem IS with MQ since another piece of software doing the same task does not send the erroneous MIDI message. i.e., your request that I remove the patch bay from the setup is unnecessary. I've already shown that it is not the problem with another piece of software. > Obviously I don't know your precise configuration but I do know that we are not > sending any commands to change the MIDI mode on the instrument. All we do is > send out a patch change using the channel and patch number you select. If your > patch bay is passing the patch change intended just for it through to the > instrument, can you reconfigure the patch bay so that it filters out (doesn't > pass on) the patch changes on channel 2? This patch bay is the KMX-16. It does not do filtering. I'll see if there's anything I can do to filter this out via another device. Again, I have already shown that this is not the problem by using another piece of editing software that successfully changes to the correct configuration on the patch bay via a program change message without sending a MIDI mode change to the UP. Is it possible that MQ is sending a MIDI mode change with the patch bay program change? > >That said, there's a bit of this that I don't follow. From your comment can I > >assume you are using a patch bay and that you have you have PBay in the > Driver > >List window set to the channel of the patch bay? If so what is the channel > its > > Yes. I have the PBay set to channel two for my patch bay. > > >using? If this is correct, is that patch bay changing its configuration > >properly? Also, is the Proteus receiving this patch change command as > well? Now, > > The patch bay changes to patch 5 as requested. > > The UP gets this patch change as well (because it is in OMNI mode now). > > >what is the Midi Channel set to in Midi Quest for the UProteus? Does the > Proteus > > The UP is on channel nine (9). > > The UP's basic channel is 9? And the Midi channel set on Midi Quest is also 9? > What ID number are you using on the UP? Yes. MQ is set to channel 9 for the UP. The ID number is the basic one. I'm not in front of the setup, but I believe that it shows up as 0 on the UP and 1 in MQ. If this is critical to your ability to replicate the bug, let me know and I'll verify this information. > >jump to this patch? Is this the point at which it changes modes? What patch > > Yes. It jumps to this patch, but it could NOT do this until after it > changes to OMNI mode. (Believe me. I've done enough experimentation > trying to get MQ to work to know exactly what will and won't change patches > on the UP.) > > >number do you request and what do you get? If you don't fight the mode > change, > > I request different patches. Recent examples were 66 and 45. These > patches come up in the editor (but they are not editable, since that's NOT > what is displayed in the UP). > > >what happens next time you make the request? What is the behavior like if you > > The next time I make the request the same thing happens. The correct patch > number loads into the editor, but the UP is switched back to patch 5 (via > OMNI and settings sent to the patch bay). Once again, I am unable to > adjust the patch because the settings are out of sync. > > One really bad thing is that patch 0 and patch 5 on the UP are totally > wonky and unuseable since all the parameters I send from MQ seem to go to > one of these two patches. > > FYI. There is no buffer in the UP to send to so we must transmit to a memory > location. Patch 0 is used for auditioning from banks and whatever patch is > selected in the PCH # is used when editing patches, either from a bank or > individually. As a result, patch 0 is changed frequently. I don't know why patch > 5 should be anything other than what you last sent to it. I can't say for sure, but I suspect that having changed the unit to program 5, MQ mistakenly uses this patch to do real-time changes from the editor. > >bypass the patch bay and go directly to the instrument? > > I don't know since this completely defeats the purpose of having a nice > setup like mine. As I mentioned above, I have UP dedicated software that > works great. I'd just prefer to use the integrated editor/ librarian in > MQ. Unfortunately, this is impossible at this point. > > This was not meant to be a permanent solution but was meant to be a test. If you > bypass the patch bay, do you get the same behavior? The patch to change the > patch bay is obviously being passed through to the UP. What I want to know is if > the patch bay isn't there and you send the same set of commands, does the UP > switch to omni mode? Fine. I'll do this test. I'm not happy about it. > One last question, have you modified your Patch Map or is it still mapped 0 - > 127 for patch changes 0 - 127? I'll check on this. I can't see what relation to MIDI mode changes it has, but if it's mapped should I put it back to unmapped and test again? > I know you're not going to like this last bit but I need to pass it along. I > doubt the problem is in Midi Quest but is likely somewhere else in the system. > Possibly, the UP but based on history, more likely the patch bay. We are forever > seeing problems with them. Its extremely difficult to diagnose a problem with a > patch bay in the system because in most cases, when you remove the patch bay the > problem also disappears. This is why we need to know how the system behaves > without the patch bay connected. As I said before, this does not explain why the other software works. ------------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============------------ Q-source Stan (Sawyer) Stewart qsource@aimnet.com http://www.aimnet.com/~qsource/ Date: 28 Apr 97 20:04:27 EDT From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stanley G. Stewart\"'" Subject: RE: UltraProteus MIDI Mode Hi Stan, Thanks for the message back. I'm sorry I can't give you a straight out answer but the problem is that the program is not sending any mode change messages which I've just verified again before writing this. Also its not a problem that has been reported by anyone else so I expect that we are looking at something that relates very specifically to the timing and speed of the MIDI message in your system. Whatever the problem is, yes, the other program does not create it but its not something that we can replicate here. Whether the other program works or not, the only way we'll get Midi Quest working for you is to try isolating, as much as possible, the various components and testing them. If we can get something working, then its a matter of adding things in one at a time until the program breaks again. Then we know where the problem is. I can suggest a couple of things for you to try: 1) In "Utilities/Default Parms Window" there is a parameter "PBay Delay" which should be set to "4" unless you have changed it. Change this value to 50. This will then produce a sequence of: patch change on channel 2 for pbay delay transmission of sysx data transmission of patch change for UP The question is, does the mode change occur immediately, in other words right after the first patch change. Or does it happen 5 seconds later witht the SysX transmission. Or is it now working properly? 2) Assuming the program is still broken after step one. You can try loading in the driver and adding a delay between the SysX dump and the patch change afterwards. To do this: a) open the driver creator window (Utilties/Driver Creator Window) b) click the right mouse button in the window to get the popup menus c) choose 3rd from the bottom: "Load Driver from Disk" d) use the file selector to enter the morpheus dir and choose "Preset.Bnk" e) In the lower right you will see an "Audition" section. Then end of the macro will read: "T 566 S 2 { C0 0 } T 2". Change this to "T 566 D 100000 S 2 { C0 0 } T 2". f) choose "Files/Save Driver" to save the file g) Quit MQ, run MQ, try auditioning from a bank. Do you still have the same problem? We are now running a sequence like this: patch change on channel 2 for pbay delay transmission of sysx data delay transmission of patch change for UP Where does the instrument change modes? Hope this is useful. Mike Lambie Sound Quest Inc ---------- From: "Stanley G. Stewart" Sent: Monday, April 28, 1997 1:10 PM To: Michael Lambie Subject: RE: UltraProteus MIDI Mode To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970429000427_76702.2205_CHN55-1@CompuServe.COM> References: At 08:04 PM 4/28/97 EDT, you wrote: >I can suggest a couple of things for you to try: > >1) In "Utilities/Default Parms Window" there is a parameter "PBay Delay" which >should be set to "4" unless you have changed it. Change this value to 50. This >will then produce a sequence of: > >patch change on channel 2 for pbay >delay >transmission of sysx data >transmission of patch change for UP > >The question is, does the mode change occur immediately, in other words right >after the first patch change. Or does it happen 5 seconds later witht the SysX >transmission. Or is it now working properly? The change to OMNI happens with the sysex (not with the patch bay change). The patch on the UP still gets set to 5 as well. >2) Assuming the program is still broken after step one. You can try loading in >the driver and adding a delay between the SysX dump and the patch change >afterwards. To do this: [instructions deleted] It turns out that the bank load does not make the OMNI change. It only happens when requesting a single patch. Here's one way that seems to show that it's coming from MQ. Load the patch bank from the UP. (So far, everything is correct: the patch number and mode stay the way they were. The patch bay changes to the correct program.) Click on a patch in the bank. Click on the Edit button. Watch the mode change to OMNI on the UP and the patch change to the same as the patch bay program number. (The patch bay will change to the right number and then the UP _subsequently_ changes to OMNI and the patch bay program number.) The other annoying thing that happens at this point is that the patch I've selected from the bank is now copied to the # set in the "Patch" editor box under the UP/Morpheus driver. (Urgh! So now, I must restore my patches from a backup in addition to testing the software! I have co-workers down the hall from me during the day who get paid to test software.) Here's another one: I turn off the patch bay (not the switch on the hardware, but the one in the MQ software). I ask for a patch from UP. The MIDI mode changes to OMNI. Finally, I pulled apart my setup so that I could attach the UP directly to the MIDI ports of my computer. Guess what!? The symptoms are still the same. Requesting a single patch (I tested it directly from the patch driver and via the edit button in a bank) causes the UP to change to OMNI mode. Come on, Michael. Your software is doing something to make this happen. I guess my work around will be to (1) turn of the patch bay function when editing the UP and (2) walk over to the UP and reset the mode manually after completing any MQ sessions. From: "Michael Lambie" To: Subject: Ultra drivers Date: Tue, 29 Apr 1997 10:18:18 -0700 X-MSMail-Priority: Normal X-Mailer: Microsoft Internet Mail 4.70.1155 Here are the files I promised. Mike Lambie Sound Quest Inc. Attachment Converted: "D:\DL\ULTRA1.ZIP" Date: 29 Apr 97 13:30:54 EDT From: Michael Lambie <76702.2205@CompuServe.COM> To: "'\"Stan (Sawyer) Stewart\"'" Subject: RE: UltraProteus MIDI Mode Hello Stan, Thanks for your patience. A couple of the pieces of information and hopefully we'll be done. Also, expect a separate email that contains some updated files which will hopefully fix your problems. ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, April 28, 1997 10:32 PM To: Michael Lambie Subject: RE: UltraProteus MIDI Mode At 08:04 PM 4/28/97 EDT, you wrote: >I can suggest a couple of things for you to try: > >1) In "Utilities/Default Parms Window" there is a parameter "PBay Delay" which >should be set to "4" unless you have changed it. Change this value to 50. This >will then produce a sequence of: > >patch change on channel 2 for pbay >delay >transmission of sysx data >transmission of patch change for UP > >The question is, does the mode change occur immediately, in other words right >after the first patch change. Or does it happen 5 seconds later witht the SysX >transmission. Or is it now working properly? The change to OMNI happens with the sysex (not with the patch bay change). The patch on the UP still gets set to 5 as well. Thanks, is one of the things I was trying to find out. >2) Assuming the program is still broken after step one. You can try loading in >the driver and adding a delay between the SysX dump and the patch change >afterwards. To do this: [instructions deleted] It turns out that the bank load does not make the OMNI change. It only happens when requesting a single patch. Here's one way that seems to show that it's coming from MQ. Load the patch bank from the UP. (So far, everything is correct: the patch number and mode stay the way they were. The patch bay changes to the correct program.) Click on a patch in the bank. It this point can you please confirm that if you choose various patches that auditioning is fine. That is, without opening up a split editor window. Click on the Edit button. Watch the mode change to OMNI on the UP and the patch change to the same as the patch bay program number. (The patch bay will change to the right number and then the UP _subsequently_ changes to OMNI and the patch bay program number.) The other annoying thing that happens at this point is that the patch I've selected from the bank is now copied to the # set in the "Patch" editor box under the UP/Morpheus driver. (Urgh! So now, I must restore my patches from a backup in addition to testing the software! I have co-workers down the hall from me during the day who get paid to test software.) Here's another one: I turn off the patch bay (not the switch on the hardware, but the one in the MQ software). I ask for a patch from UP. The MIDI mode changes to OMNI. Finally, I pulled apart my setup so that I could attach the UP directly to the MIDI ports of my computer. Guess what!? The symptoms are still the same. Requesting a single patch (I tested it directly from the patch driver and via the edit button in a bank) causes the UP to change to OMNI mode. Come on, Michael. Your software is doing something to make this happen. Yes, it is. I think its in the timing. That is, the amount of time between the various MIDI messages being sent to the unit. If wasn't a problem on our systems or anyone else's but your so far. I guess my work around will be to (1) turn of the patch bay function when editing the UP and (2) walk over to the UP and reset the mode manually after completing any MQ sessions. Let's hope not when we're done. ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970429173054_76702.2205_CHN43-2@CompuServe.COM> References: At 01:30 PM 4/29/97 EDT, you wrote: >Here's one way that seems to show that it's coming from MQ. Load the patch >bank from the UP. (So far, everything is correct: the patch number and >mode stay the way they were. The patch bay changes to the correct >program.) Click on a patch in the bank. > >It this point can you please confirm that if you choose various patches that >auditioning is fine. That is, without opening up a split editor window. Do you want me to test the old driver or the new one. >Click on the Edit button. Watch >the mode change to OMNI on the UP and the patch change to the same as the >patch bay program number. (The patch bay will change to the right number >and then the UP _subsequently_ changes to OMNI and the patch bay program >number.) The other annoying thing that happens at this point is that the >patch I've selected from the bank is now copied to the # set in the "Patch" >editor box under the UP/Morpheus driver. [stuff deleted] >Here's another one: I turn off the patch bay (not the switch on the >hardware, but the one in the MQ software). I ask for a patch from UP. The >MIDI mode changes to OMNI. > >Finally, I pulled apart my setup so that I could attach the UP directly to >the MIDI ports of my computer. Guess what!? The symptoms are still the >same. Requesting a single patch (I tested it directly from the patch >driver and via the edit button in a bank) causes the UP to change to OMNI >mode. > >Come on, Michael. Your software is doing something to make this happen. > >Yes, it is. I think its in the timing. That is, the amount of time between the >various MIDI messages being sent to the unit. If wasn't a problem on our systems >or anyone else's but your so far. I'm not trying to be argumentative, but this makes no sense. The OMNI change is a MIDI parameter of some sort. There is no reason (that I'm aware of) that it should be sent to the UP at this point. Remember, the OMNI change gets sent even with the patch bay out of the picture, so it does not sound like a timing problem. Let me know if you want me to test auditioning with the old driver, the new one or both and I'll try to find time for it. -= From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970429173054_76702.2205_CHN43-2@CompuServe.COM> References: At 01:30 PM 4/29/97 EDT, you wrote: >It this point can you please confirm that if you choose various patches that >auditioning is fine. That is, without opening up a split editor window. The old driver works fine for this. (i.e., It "auditions" a chord and allows me to play the selected patch from my controller keyboard.) The new driver does the same for auditioning. (As you know, the UP is set to patch 00 at this point.) The new driver works for single patches. (The program matches the selection in the driver line; no OMNI mode selection and no wrong program number.) The Edit button in the Patch bank also works. (I suppose that it just calls the patch driver, anyway, so you'd expect this.) Thank you. To: Michael Lambie <76702.2205@CompuServe.COM> From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970430005212_76702.2205_CHN57-2@CompuServe.COM> References: At 08:52 PM 4/29/97 EDT, you wrote: >Hopefully you read both my messages before answering the first one. It sounds >like everything is working now, am I correct? Please let me know. The new driver works correctly. -= From: "Stan (Sawyer) Stewart" Subject: RE: UltraProteus MIDI Mode Cc: Bcc: X-Attachments: In-Reply-To: <970501044040_76702.2205_CHN61-3@CompuServe.COM> References: At 12:40 AM 5/1/97 EDT, you wrote: >Great! Now, I have one more question - you must be sick of this. I put in some >fairly healthy delays inbetween the messaging. Is there anything you are finding >bothersome that you would like me to pull back on? I adjusted your D 200,000 to D 200 and the OMNI mode change still does not appear. I assume this answers your question. -= Subject: Wavestation SR problems Cc: Bcc: X-Attachments: In-Reply-To: References: Michael: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) Once again, my work for two nights on editing patches is nearly worthless because I'm trying to figure out what's wrong with MIDI Quest. I've really tried to be patient with your software, but I'm about to give up on it. Here is my current crop of bugs. When I go into the Wavestation SR Performance edit, the wrong banks display in the performance. RAM3 shows up as ROM5. I just created a new bank (1/2/3) of patches. When I upload it to the SR, I get a checksum error (on the synth) and RAM2 and RAM3 are full of valid patches, but ones that I've never seen before. (Both of these two banks have the same set of patches beginning with Analog Bass and ending with Chug.) They are certainly not the patches I placed here. The 1/2/3 Bank editor shows the correct patches (not just the names...the data appears to be correct as well), but will not place them into the SR. I've tried placing these patches in individual RAM2 and RAM3 editors and restoring them to the SR. This also produces a checksum error on the SR. Apparently, I have no way to restore this information to my SR. To: 76702.2205@compuserve.com From: "Stan (Sawyer) Stewart" Subject: XD-5 editors Cc: Bcc: X-Attachments: In-Reply-To: References: Michael: [Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02)] I have started doing serious editing on my Kawai XD-5. The patch editing seems to go fine with MQ once I understood that the first patch is continuously overwritten with whatever I'm editing. However, when I open the Output bank editor and click on an output patch, MQ _always_ puts up a dialogue that says "Incompatible Voice Byte Sizes". I get this same message when I try to save the bank. Futhermore, when I go back to an edited patch, my edits are all gone. Any ideas? What other information do you need to figure out a fix? Date: Tue, 27 May 1997 02:31:03 -0400 From: Michael Lambie Subject: RE: XD-5 editors To: "'\"Stan (Sawyer) Stewart\"'" Hi Stan, Sorry about the problems. I'll email you one updated file and that should take care of everything. Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Saturday, May 24, 1997 8:28 PM To: 76702,2205] Subject: XD-5 editors Michael: [Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02)] I have started doing serious editing on my Kawai XD-5. The patch editing seems to go fine with MQ once I understood that the first patch is continuously overwritten with whatever I'm editing. However, when I open the Output bank editor and click on an output patch, MQ _always_ puts up a dialogue that says "Incompatible Voice Byte Sizes". I get this same message when I try to save the bank. Futhermore, when I go back to an edited patch, my edits are all gone. Any ideas? What other information do you need to figure out a fix? ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com Date: Tue, 27 May 1997 12:30:48 -0400 From: Michael Lambie Subject: RE: XD-5 editors To: "'\"Stan (Sawyer) Stewart\"'" X-Status: Hi Stan, Yes, I know what it was. When we went from v5 to v6 we started making use of a parameter that was previously not used for a function. We had to go through and update many of MQ's drivers to get this working. Somehow we either missed the XD-5 output or at somepoint had to recover from a backup and lost the change. The same change had to be made to two other XD-5 drivers and thye're both fine. The parameter, as you may have guessed, indicates the size of the data in the patch. It is now necessary to have this information stored in 2 places instead of just one (I can't remember why). Sincerely, Michael Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Tuesday, May 27, 1997 6:59 AM To: Michael Lambie Subject: RE: XD-5 editors I'll try out the "Output" replacement this evening. I guess you know what the problem was. If you have time, I'd be interested in knowing what it was. Thanks. -= Subject: D-110 Cc: Bcc: X-Attachments: In-Reply-To: References: Hi again, Michael: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) I have two Roland D-110's. One is set to the default Comm Channel of 17 and the other is set to 18. Most of the editor seems to work OK. However, when I change a tone or import a new one and Move To a current bank, MQ reports success. However, when I request the bank from the synth again, it has the old tone. The new tone is not being copied to the other D-110. If I restore the bank from disk, the saved bank has the correct tones in it. If I send this to the synth AGAIN, it still does not save to the unit properly. (I've tried to save tone #4 sixteen times without success.) While it does not take very many tries for me to reproduce this problem, it does not happen every time. i.e., infrequently, I can send the bank to the D-110 and it actually gets stored there. Am I missing something? Or is this a bug in the editor? Date: Mon, 30 Jun 1997 03:52:15 -0400 From: Michael Lambie Subject: RE: D-110 To: "'\"Stan (Sawyer) Stewart\"'" Hello Stan, Thanks for the message. I'll take a first shot at this with a simple answer. If this isn't it, please let me know. When you move a patch into a bank in MQ, the bank in you instrument is not updated until you specifically send the bank from MQ to your instrument. Is this it? Actually, I read you letter more closely and it sounds like it isn't. Question. In Midi Quest do you have "Options/Drv Auto Update/On - except channel, port, pch#"? If you don't, you should and this could be the cause of the problem. MQ tries to handle instrument settings "intelligently" but it can't when you have two instruments of the same type. If you haven't set this parameter, you should set it then go through each of your banks and press the "Settings" button to make sure that it has the UNIT ID (Comm Ch) that you expect it to. Question. What ROM version does your D-110 have? Do you have this problem only with tone #4 or does it happen with the other tones as well? Does it ever happen with tone #1? I just want to make sure that we are talking tones here and not parts in tones (I got confused here myself) When you have problems are you trying to communicate with the instrument on UNIT 18 or 17? Do you have the same problems with the other instrument? I'm not sure what the problem is right off but with Roland you sometimes find that the certain ROM versions of an instrument don't actually operate to spec. This may be what is happening here. Roland has a whole set of specs for communicating, which we follow and of course we test with instruments to make sure that everything is working however, we constantly find that as Roland updates their ROMs they tend to break their own rules and we have to update our drivers to accomodate this. (I know that the D-110 has been around for quite a while and this shouldn't be happening this late in the game but its always possible). Anyway, your answers should help to sort out what the problem is. Talk to you soon. Mike Lambie Sound Quest Inc. ---------- From: "Stan (Sawyer) Stewart" Sent: Sunday, June 29, 1997 9:13 PM To: 76702,2205] Subject: D-110 Hi again, Michael: Windows 95 (4.00.95.a) 486-66Mhz w/32Mb RAM MQ32/M midi interface with latest drivers (1.02) I have two Roland D-110's. One is set to the default Comm Channel of 17 and the other is set to 18. Most of the editor seems to work OK. However, when I change a tone or import a new one and Move To a current bank, MQ reports success. However, when I request the bank from the synth again, it has the old tone. The new tone is not being copied to the other D-110. If I restore the bank from disk, the saved bank has the correct tones in it. If I send this to the synth AGAIN, it still does not save to the unit properly. (I've tried to save tone #4 sixteen times without success.) While it does not take very many tries for me to reproduce this problem, it does not happen every time. i.e., infrequently, I can send the bank to the D-110 and it actually gets stored there. Am I missing something? Or is this a bug in the editor? ---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com To: Michael Lambie From: "Stan (Sawyer) Stewart" Subject: RE: D-110 Cc: Bcc: X-Attachments: In-Reply-To: <199706300352_MC2-197D-6BB6@compuserve.com> References: Thanks for your quick reply. My answers, etc. are embedded in your reply. At 03:52 AM 6/30/97 -0400, you wrote: >Thanks for the message. I'll take a first shot at this with a simple >answer. If this isn't it, please let me know. When you move a patch into a >bank in MQ, the bank in you instrument is not updated until you >specifically send the bank from MQ to your instrument. Is this it? >Actually, I read you letter more closely and it sounds like it isn't. Nope. That's not it. >Question. In Midi Quest do you have "Options/Drv Auto Update/On - except >channel, port, pch#"? If you don't, you should and this could be the cause >of the problem. MQ tries to handle instrument settings "intelligently" but >it can't when you have two instruments of the same type. If you haven't set >this parameter, you should set it then go through each of your banks and >press the "Settings" button to make sure that it has the UNIT ID (Comm Ch) >that you expect it to. No. Mine was set to "On" but not "On - expect channel, port..." Are you telling me that "expect" should say "except"? I had to move it to just "On" because of a problem with another driver. I guess I'll have to go back through my notes, figure out which driver that was and switch it back an forth depending on which synth I'm editing. So, for the D-110's, you want me to set Options/Drv Auto Update to "On - expect channel, port..." instead of "On". Then go to the setting of the banks (do you mean banks or drivers?) to check that the Comm Ch is the appropriate one. I'll try doing this tonight unless I hear to the contrary later today. >Question. What ROM version does your D-110 have? Do you have this problem >only with tone #4 or does it happen with the other tones as well? Does it >ever happen with tone #1? I just want to make sure that we are talking >tones here and not parts in tones (I got confused here myself) When you >have problems are you trying to communicate with the instrument on UNIT 18 >or 17? Do you have the same problems with the other instrument? It has done this with any number of different tone numbers. There is no pattern to which tone fails to update in the bank. I have had the problem with both units. >I'm not sure what the problem is right off but with Roland you sometimes >find that the certain ROM versions of an instrument don't actually operate >to spec. This may be what is happening here. Roland has a whole set of >specs for communicating, which we follow and of course we test with >instruments to make sure that everything is working however, we constantly >find that as Roland updates their ROMs they tend to break their own rules >and we have to update our drivers to accomodate this. (I know that the >D-110 has been around for quite a while and this shouldn't be happening >this late in the game but its always possible). Anyway, your answers should >help to sort out what the problem is. I can remember checking the ROM level on at least one of these units. Now I can't even recall how to do it. MQ fast tips say power on while holding down Data Transfer and Edit. The D-110 doesn't have a Data Transfer button so this must be for the D-10. If you know what this sequence is, let me know. Otherwise, I just search for it on the web and call Roland to ask... Later. -=Talk to you soon. > >Mike Lambie >Sound Quest Inc. > >---------- >From: "Stan (Sawyer) Stewart" >Sent: Sunday, June 29, 1997 9:13 PM >To: 76702,2205] >Subject: D-110 > > >Hi again, Michael: > >Windows 95 (4.00.95.a) >486-66Mhz w/32Mb RAM >MQ32/M midi interface with latest drivers (1.02) > >I have two Roland D-110's. One is set to the default Comm Channel of 17 >and the other is set to 18. Most of the editor seems to work OK. However, >when I change a tone or import a new one and Move To a current bank, MQ >reports success. However, when I request the bank from the synth again, it >has the old tone. > >The new tone is not being copied to the other D-110. If I restore the bank >from disk, the saved bank has the correct tones in it. If I send this to >the synth AGAIN, it still does not save to the unit properly. (I've tried >to save tone #4 sixteen times without success.) > >While it does not take very many tries for me to reproduce this problem, it >does not happen every time. i.e., infrequently, I can send the bank to the >D-110 and it actually gets stored there. > >Am I missing something? Or is this a bug in the editor? > > >---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- >Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com > > > > Date: Mon, 30 Jun 1997 14:44:00 -0400 From: Michael Lambie Subject: RE: D-110 To: "'\"Stan (Sawyer) Stewart\"'" Hi Stan, I thought about embedding but it just seemed like it would get too messy. 1) yes, "expect" should read "except" and you should have it set to that third option. I'm assuming here that you have installed 2 D-110s into the driver list and one is set to Unit #18. If you are not doing this then making this change isn't going to make any difference. 2) By Banks, yes, I mean each bank of data. Each bank actually holds its own unit # (Comm Ch), port in, and port out selection so if these are "confused" you will need to correct them for each bank. 3) For D-110 ROM version: hold down bottom 3 buttons right to left and turn instrument on. Talk to you later. Mike ---------- From: "Stan (Sawyer) Stewart" Sent: Monday, June 30, 1997 7:02 AM To: Michael Lambie Subject: RE: D-110 Thanks for your quick reply. My answers, etc. are embedded in your reply. At 03:52 AM 6/30/97 -0400, you wrote: >Thanks for the message. I'll take a first shot at this with a simple >answer. If this isn't it, please let me know. When you move a patch into a >bank in MQ, the bank in you instrument is not updated until you >specifically send the bank from MQ to your instrument. Is this it? >Actually, I read you letter more closely and it sounds like it isn't. Nope. That's not it. >Question. In Midi Quest do you have "Options/Drv Auto Update/On - except >channel, port, pch#"? If you don't, you should and this could be the cause >of the problem. MQ tries to handle instrument settings "intelligently" but >it can't when you have two instruments of the same type. If you haven't set >this parameter, you should set it then go through each of your banks and >press the "Settings" button to make sure that it has the UNIT ID (Comm Ch) >that you expect it to. No. Mine was set to "On" but not "On - expect channel, port..." Are you telling me that "expect" should say "except"? I had to move it to just "On" because of a problem with another driver. I guess I'll have to go back through my notes, figure out whi! ch driver that was and switch it back an forth depending on which synth I'm editing. So, for the D-110's, you want me to set Options/Drv Auto Update to "On - expect channel, port..." instead of "On". Then go to the setting of the banks (do you mean banks or drivers?) to check that the Comm Ch is the appropriate one. I'll try doing this tonight unless I hear to the contrary later today. >Question. What ROM version does your D-110 have? Do you have this problem >only with tone #4 or does it happen with the other tones as well? Does it >ever happen with tone #1? I just want to make sure that we are talking >tones here and not parts in tones (I got confused here myself) When you >have problems are you trying to communicate with the instrument on UNIT 18 >or 17? Do you have the same problems with the other instrument? It has done this with any number of different tone numbers. There is no pattern to which tone fails to update in the bank. I have had the problem with both units. >I'm not sure what the problem is right off but with Roland you sometimes >find that the certain ROM versions of an instrument don't actually operate >to spec. This may be what is happening here. Roland has a whole set of >specs for communicating, which we follow and of course we test with >instruments to make sure that everything is working however, we constantly >find that as Roland updates their ROMs they tend to break their own rules >and we have to update our drivers to accomodate this. (I know that the >D-110 has been around for quite a while and this shouldn't be happening >this late in the game but its always possible). Anyway, your answers should >help to sort out what the problem is. I can remember checking the ROM level on at least one of these units. Now I can't even recall how to do it. MQ fast tips say power on while holding down Data Transfer and Edit. The D-110 doesn't have a Data Transfer button so this must be for the D-10.! If you know what this sequence is, let me know. Otherwise, I just search for it on the web and call Roland to ask... Later. -=Talk to you soon. > >Mike Lambie >Sound Quest Inc. > >---------- >From: "Stan (Sawyer) Stewart" >Sent: Sunday, June 29, 1997 9:13 PM >To: 76702,2205] >Subject: D-110 > > >Hi again, Michael: > >Windows 95 (4.00.95.a) >486-66Mhz w/32Mb RAM >MQ32/M midi interface with latest drivers (1.02) > >I have two Roland D-110's. One is set to the default Comm Channel of 17 >and the other is set to 18. Most of the editor seems to work OK. However, >when I change a tone or import a new one and Move To a current bank, MQ >reports success. However, when I request the bank from the synth again, it >has the old tone. > >The new tone is not being copied to the other D-110. If I restore the bank >from disk, the saved bank has the correct tones in it. If I send this to >the synth AGAIN, it still does not save to the unit properly. (I've tried >to save tone #4 sixteen times without success.) > >While it does not take very many tries for me to reproduce this problem, it >does not happen every time. i.e., infrequently, I can send the bank to the >D-110 and it actually gets stored there. > >Am I missing something? Or is this a bug in the editor? > > >---------=============<<<<<<<<<<<<<>>>>>>>>>>>>>=============--------- >Stan Stewart http://www.aimnet.com/~qsource/ qsource@aimnet.com > > > > To: Michael Lambie From: "Stan (Sawyer) Stewart" Subject: RE: D-110 Cc: Bcc: X-Attachments: In-Reply-To: <199706301444_MC2-1986-470D@compuserve.com> References: Michael, 1. That doesn't help. Same problems as before. Sometimes the bank updates on the synth after a "Send to" and sometime it does not. Usually after 4-5 sends I'm finally successful. The unit on Comm Ch 17 seems to be more consistent (i.e., it works correctly with the bank send most of the time), but the problem has occurred on it recently, too. 2. I noticed this fact about the banks. Since I'm downloading them from the instrument and then immediately trying to copy them back to the synth after a few small changes (sometimes just changing the name of a patch), I assumed that I could trust that nothing would get messed up. The ones that I've checked have had the right settings. 3. I can't find any combination of three buttons together that works for getting the ROM version. I tried three bottom buttons on the right; on the left; on the top right; on the top left; and a few others. I was asked it I wanted to initialize the unit whenever I held down the Write key. Some other combination gave me the built-in sequences. Any other ideas? -=Hi Stan, > >I thought about embedding but it just seemed like it would get too messy. > >1) yes, "expect" should read "except" and you should have it set to that >third option. I'm assuming here that you have installed 2 D-110s into the >driver list and one is set to Unit #18. If you are not doing this then >making this change isn't going to make any difference. > >2) By Banks, yes, I mean each bank of data. Each bank actually holds its >own unit # (Comm Ch), port in, and port out selection so if these are >"confused" you will need to correct them for each bank. > >3) For D-110 ROM version: hold down bottom 3 buttons right to left and turn >instrument on. > >Talk to you later. > > >Mike > > >---------- >From: "Stan