Hello,
All my midi programming experience so far (over 20 years or so) has revolved around my Roland LAPC-I card and it's midi interface. I've used, and written, various progs/utilities for this interface, and things connected via the Roland card.
However, I've just recently obtained an old PC, previously owned by someone else, and this machine has a sound card installed. My understanding it is a Sound Blaster 'clone', and may be a 'no-name' variety, although it uses OPTi chips and there's a Yamaha synth/fm chip on the board.
I'm trying to see what I can do with the board, just midi, just via DOS.
There is a setup utility for the card, this seems to work OK, and it does make some test sounds.
I've used a standard midi PLAY utility to play a couple of midi files, installed for SB/fm card, and this does 'play' the music, BUT it seems NOT to be recognising note off and ends up with a really horrid NOISE with seemingly everything still playing.
I've tried to create an All_Notes_Off util, as per the Roland card, but this does not work. I've got a doc from the internet which gives some info about programming SB cards, using UART mode and the (supposed) MPU-401 interface, and this should be pretty similar to code which would work with the Roland card, but it does NOT work.
Does anyone have any experience of programming SB (or clone) cards? Or any suggestions of how I might proceed. As I can so much easier get MUCH NICER sounds from the Roland card, should I bother??
Geoff
All my midi programming experience so far (over 20 years or so) has revolved around my Roland LAPC-I card and it's midi interface. I've used, and written, various progs/utilities for this interface, and things connected via the Roland card.
However, I've just recently obtained an old PC, previously owned by someone else, and this machine has a sound card installed. My understanding it is a Sound Blaster 'clone', and may be a 'no-name' variety, although it uses OPTi chips and there's a Yamaha synth/fm chip on the board.
I'm trying to see what I can do with the board, just midi, just via DOS.
There is a setup utility for the card, this seems to work OK, and it does make some test sounds.
I've used a standard midi PLAY utility to play a couple of midi files, installed for SB/fm card, and this does 'play' the music, BUT it seems NOT to be recognising note off and ends up with a really horrid NOISE with seemingly everything still playing.
I've tried to create an All_Notes_Off util, as per the Roland card, but this does not work. I've got a doc from the internet which gives some info about programming SB cards, using UART mode and the (supposed) MPU-401 interface, and this should be pretty similar to code which would work with the Roland card, but it does NOT work.
Does anyone have any experience of programming SB (or clone) cards? Or any suggestions of how I might proceed. As I can so much easier get MUCH NICER sounds from the Roland card, should I bother??
Geoff
Right!
I really OUGHT to check up regarding things I've barely looked at for 20+ years.
I've now checked both versions of the Dr T MT32 editor. An older DOS/Text version, and a later DOS/Graphics version. Both will TRY to get the data from the card. Both fail to do so. Clearly, my memory that I had done this is WRONG. My apologies.
The older system, where I have 23 patch banks obtained from various places, does NOT seem to have any original/preset patch data. The newer prog, however, DOES have two banks labelled preset1 and preset2 which appear to have all the original patches in. How they were obtained, I don't know, although I could assume that the MT-32 (the REAL machine) WILL recognise the data request command? Unfortunately, the format of the later files seems to be slightly different from the format of the earlier set, so the file systems are NOT compatible. No doubt, I could investigate this further and convert between the two formats, they're not THAT different.
Regarding my programs for Sysex, more detailed study suggests that LONG ago I got the original prog for the MT32, which included send and receive sections. Maybe way back I found that the receive parts did NOT work with the LAPC, so I extracted the send parts and got them working in various forms for my own purposes.
Hmm, such fun!
geoff
I really OUGHT to check up regarding things I've barely looked at for 20+ years.
I've now checked both versions of the Dr T MT32 editor. An older DOS/Text version, and a later DOS/Graphics version. Both will TRY to get the data from the card. Both fail to do so. Clearly, my memory that I had done this is WRONG. My apologies.
The older system, where I have 23 patch banks obtained from various places, does NOT seem to have any original/preset patch data. The newer prog, however, DOES have two banks labelled preset1 and preset2 which appear to have all the original patches in. How they were obtained, I don't know, although I could assume that the MT-32 (the REAL machine) WILL recognise the data request command? Unfortunately, the format of the later files seems to be slightly different from the format of the earlier set, so the file systems are NOT compatible. No doubt, I could investigate this further and convert between the two formats, they're not THAT different.
Regarding my programs for Sysex, more detailed study suggests that LONG ago I got the original prog for the MT32, which included send and receive sections. Maybe way back I found that the receive parts did NOT work with the LAPC, so I extracted the send parts and got them working in various forms for my own purposes.
Hmm, such fun!
geoff
0
Undo
Votes
Hi Geoff
Yes, we're in complete agreement. I think the block diagram on page 24 makes it clear. The MPU-401 section of the LAPC-I has both MIDI In and MIDI Out, but the LA Sound Section only has a MIDI In. It is not possible to read data from the LA Sound Section.
The default state of the LAPC-I is documented, so I suspect the software you are using assumes the LAPC-I is in the default state and then simply keeps track of whatever changes you make through the software. It cannot read the actual state of the LA Sound Section.
The LAPC-I ignores Request Data messages and does not respond.
The Quest Studios site is just an example of a site that has some patches for downloading. There are others out there. There may be better ones for sharing patches. Let us know if you do share your patches, it would be greatly appreciated.
Cheers
Eddie
As for the implementation chart, YES, the LAPC does NOT 'send' Sysex, as in it does NOT originate any Sysex, but clearly any Sysex that comes in is passed through, so in effect it DOES send sysex.
Yes, we're in complete agreement. I think the block diagram on page 24 makes it clear. The MPU-401 section of the LAPC-I has both MIDI In and MIDI Out, but the LA Sound Section only has a MIDI In. It is not possible to read data from the LA Sound Section.
Or might it be doing it some other way?
The default state of the LAPC-I is documented, so I suspect the software you are using assumes the LAPC-I is in the default state and then simply keeps track of whatever changes you make through the software. It cannot read the actual state of the LA Sound Section.
When you've tried a Request Data operation, what happened?
The LAPC-I ignores Request Data messages and does not respond.
The Quest Studios site is just an example of a site that has some patches for downloading. There are others out there. There may be better ones for sharing patches. Let us know if you do share your patches, it would be greatly appreciated.
Cheers
Eddie
Hello Eddie,
When I read the same bits of the manual, I note that the 'Request Data' refers to 'attached device', just as it does in the 'Transmit data' section. No indication that it will NOT send data if requested.
As for the implementation chart, YES, the LAPC does NOT 'send' Sysex, as in it does NOT originate any Sysex, but clearly any Sysex that comes in is passed through, so in effect it DOES send sysex.
Also, I have two versions of the DOS package, Dr T's, editor for the MT-32 (and also for the LAPC). When this prog is run, all the parameter details for the card appear for editing etc. My understanding is that this data is read from the card at that point. So the Dr T's prog must be sending a 'Request Data' and must be getting an answer. Or might it be doing it some other way?
If there's something wrong with the connection to the card, then the prog reports there is a problem, and does not have any data.
I know I've used Sysex to SEND banks of data to the Roland. Many of the patches I have were obtained as complete banks. I have a couple of varieties of the sending prog. I'll have to unearth all my bits of that type (from 20+ years ago) and check if there was a 'Receive' variant too. Certainly, I have a bank, which I assume was obtained via Sysex, of the standard settings of the card.
When you've tried a Request Data operation, what happened?
I'll check out the Quest Studios site, but I think I've been there a few times, got some midi files for certain games, and some of those files include new patches. I was very interested to read somewhere that Jan Hammer had done the music for (I think) Police Quest 4, and I got the midi files for that, and yes, there's Sysex embedded in the files including a number of new patches, some for sound effects, but others for definite instruments.
Geoff
PS - After some checking - I've tried the Dr T's prog just now, and when I try to load parameters from MT-32 it seems it cannot. So you may be right, or the prog uses a specific ID which needs to be changed? I do have various Sysex progs, which I think I have used, and some of those refer to 'Request Data' as well. I'll need to check them.
Does the MT-32 say differently on it's Implementation Chart?
When I read the same bits of the manual, I note that the 'Request Data' refers to 'attached device', just as it does in the 'Transmit data' section. No indication that it will NOT send data if requested.
As for the implementation chart, YES, the LAPC does NOT 'send' Sysex, as in it does NOT originate any Sysex, but clearly any Sysex that comes in is passed through, so in effect it DOES send sysex.
Also, I have two versions of the DOS package, Dr T's, editor for the MT-32 (and also for the LAPC). When this prog is run, all the parameter details for the card appear for editing etc. My understanding is that this data is read from the card at that point. So the Dr T's prog must be sending a 'Request Data' and must be getting an answer. Or might it be doing it some other way?
If there's something wrong with the connection to the card, then the prog reports there is a problem, and does not have any data.
I know I've used Sysex to SEND banks of data to the Roland. Many of the patches I have were obtained as complete banks. I have a couple of varieties of the sending prog. I'll have to unearth all my bits of that type (from 20+ years ago) and check if there was a 'Receive' variant too. Certainly, I have a bank, which I assume was obtained via Sysex, of the standard settings of the card.
When you've tried a Request Data operation, what happened?
I'll check out the Quest Studios site, but I think I've been there a few times, got some midi files for certain games, and some of those files include new patches. I was very interested to read somewhere that Jan Hammer had done the music for (I think) Police Quest 4, and I got the midi files for that, and yes, there's Sysex embedded in the files including a number of new patches, some for sound effects, but others for definite instruments.
Geoff
PS - After some checking - I've tried the Dr T's prog just now, and when I try to load parameters from MT-32 it seems it cannot. So you may be right, or the prog uses a specific ID which needs to be changed? I do have various Sysex progs, which I think I have used, and some of those refer to 'Request Data' as well. I'll need to check them.
Does the MT-32 say differently on it's Implementation Chart?
0
Undo
Votes
Mystified about your comments that the LAPC-I is 'write only'.
Sorry I wasn't clear. You can read data from external devices connected to the LAPC-I, but you cannot read data from the internal parameters.
My LAPC-I manual's MIDI implementation chart shows that System Exclusive messages are recognized but not transmitted. It only responds to "Data set 1" (DT1) messages and ignores "Request data 1" (RQ1) messages.
I have several hundred patches, but not nearly as many as you. It would be nice if you shared your patches on a Web site like Quest Studios so others can also enjoy them.
Cheers
Eddie
Thanks for the note.
Just found an article on the web about programming the Yamaha FM chip, but the facilities seem fairly basic, and there don't seem to be any sounds (patches) built-in. Or is that info somewhere else?
Mystified about your comments that the LAPC-I is 'write only'. There ARE the usual SYSEX facilities to request any of the data on the card to come back to the PC, so the card CAN be 'read' in that regard. Also, using the card as an interface with other devices, I can certainly get data coming back (say from external keyboard) although I agree that's just the MPU interface and not the card as such. Were you thinking of something else?
In case you're interested, I've got a collection of over 1000 extra patches for the card, and a prog to load and test indiv ones. DOS only mind you.
Geoff
Just found an article on the web about programming the Yamaha FM chip, but the facilities seem fairly basic, and there don't seem to be any sounds (patches) built-in. Or is that info somewhere else?
Mystified about your comments that the LAPC-I is 'write only'. There ARE the usual SYSEX facilities to request any of the data on the card to come back to the PC, so the card CAN be 'read' in that regard. Also, using the card as an interface with other devices, I can certainly get data coming back (say from external keyboard) although I agree that's just the MPU interface and not the card as such. Were you thinking of something else?
In case you're interested, I've got a collection of over 1000 extra patches for the card, and a prog to load and test indiv ones. DOS only mind you.
Geoff
0
Undo
Votes
My advice would be "Don't bother." As you said, the Roland has much better sound quality.
I also still have my trusty old Roland LAPC-I, but I picked up a Roland CM-32L for cheap on E-Bay. The advantage of the CM-32L is two-way communication, where as the LAPC-I can only be written to, not read from. Still, they are fun to program and I have had years of fun with them.
Cheers
Eddie
I also still have my trusty old Roland LAPC-I, but I picked up a Roland CM-32L for cheap on E-Bay. The advantage of the CM-32L is two-way communication, where as the LAPC-I can only be written to, not read from. Still, they are fun to program and I have had years of fun with them.
Cheers
Eddie
- Page :
- 1
There are no replies made for this post yet.
