I am really glad that these OCX finally are publicly available. It would help if there were some bare bones examplew. Especially, I would need an example of how to create a stream of notes and controller events with the minimal amout of code needed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the examples on Mike Levoi's site is written by me ;-). The one with Excel. In fact, I want to use your OCX libraries to improve the functionality of the Excel stuff.
And therefore I asked for simple example. It would be extremely helpful to have an introductory example in VB which would just play a simple scale and thereby show what the basic skeleton of a program using the OCX has to be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Heh, that's great. So your Erich. That excel file was really amazing. I noticed it used midi API directly and no OCX? I assume you would like to see the VB source and trace it back to the VC source which can show if the midi API are handled any better. Sounds good to me.
>> ... introductory example in VB
Any and all examples you have ever seen since 1998 could work with the ocx. It is backward compatible with just a different file name that you add into vb. I am sorry more comprehensive step-by-step instructions were not made available for easy review and research.
>> ... play a simple scale
For your specific example of playing a scale, try this,
Dim mIterationStart As Integer
Dim mIterationEnd As Integer
Dim i As Integer
MIDIOutput1.Action = MIDIOUT_CLOSE
MIDIOutput1.DeviceID = 0 ' or whatever port
MIDIOutput1.Action = MIDIOUT_OPEN
' Put message data in control
MIDIOutput1.Message = 0
MIDIOutput1.Data1 = 0
MIDIOutput1.Data2 = 0
MIDIOutput1.MessageTag = 0
MIDIOutput1.Time = 0
MIDIOutput1.Action = MIDIOUT_QUEUE
mIterationStart = 60
mIterationEnd = mIterationStart + 12 ' scale 13 notes starting from c4
For i = mIterationStart To mIterationEnd
' Note-On
MIDIOutput1.Message = NOTE_ON
MIDIOutput1.Data1 = i
MIDIOutput1.Data2 = 127
MIDIOutput1.Time = 250 * (i - mIterationStart) ' every 250 msec
MIDIOutput1.MessageTag = 0
MIDIOutput1.Buffer = ""
MIDIOutput1.Action = MIDIOUT_QUEUE
' Note-Off
MIDIOutput1.Data2 = 0
MIDIOutput1.Time = MIDIOutput1.Time + 1000 ' hold note 1000msec
MIDIOutput1.MessageTag = 0
MIDIOutput1.Action = MIDIOUT_QUEUE
Next i
MIDIOutput1.Action = MIDIOUT_START
>> ... skeleton of a program using the OCX has to be
Other barebone examples like above can be seen in the help file under "examples" and other pages of properties and methods. Various demos combine features which can later be dissected for pieces you are interested in. More advanced demos introduce extra code that keep the programs and controls more versatile, reliable, blah, blah, blah, under any possible situation at all times.
Have fun.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks very much, that is exactly what I needed to be able to
get an easy start.
The main problem with my old code is that it did not do any time buffering, it just sent the messaged directly.
I always wanted to be able to do timequeued MIDI in Excel,
and the new kit will allow me to do this.
I used the old Excel MIDI stuff to compute tuninngs and send them
to the synth which then would be played in ral time.
No, for some more advanced projects, I need timequeues.
I found MIDIOX, which you also probably now.
It also works as OCX, but it does not do queueing.
So I really was happy when i found your project.
BTW: have you ever seen my realtime Fourier sound synthesis
Excel sheet?
sunsite.univie.ac.at/Spreadsite/
it might interest you if you like Excel stuff.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I put the example in Excel, and with tiny modifications it worked.
There is one problem: it only plays every second time it is called. Do you see a reason for that? The problem is completely reproducible.
Another question: Do you plan to define the system constants within the OCX later on? that would make sense, and it would be more self documenting in the object browser.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is another question.
Is it possible to change the unit time interval while a
sequence is already playing? I wopuld like to have a slider which allows to speed up or slow down the currently playing sequence. And is it possible to send
"intervening" real time messages while a midi queue is being played? I would like to set tha pan position with a real time slider while a stream is being played.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the old mabry controls on Mike's site do everything that you have asked me so far. The upgrade would not be needed at this time.
>> ... any time buffering ... sent the messaged directly
I see you used mcistring in your excel to play a midi file. Sure it would be nice to play a sequence of messages and not a midi file. If you are able to use OCX in excel, than try that.
>> ... plays every second time
Thats strange. Close does not really close and restart the queue. Until I check it more thoroughly, you can use this at beginning,
No. Mabry did not do it before because the OCX might be used in java, c+ or other compilers and can not assume they all have intellisense popups to help fill in the values as you type. System constants for each language may be different. Also using those constants can slow down the program because it uses OLE comunication to get the data all the time as its running. There are some other reasons that I documented in the source code.
>> ... change the unit time
You can use the PlaybackRate property.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please verify which component is added to your project. Looks like you might still be using the old mabry MIDIIO32 OCX version 1.10.007 which does not close and reset the queue properly. In this case, remember to use MIDIOUT_STOP or MIDIOUT_RESET before restarting a queue.
MIDIOutput1.Action = MIDIOUT_STOP ' only if using version 1.10.007
MIDIOutput1.Action = MIDIOUT_RESET ' alternative, same as stop
MIDIOutput1.Action = MIDIOUT_CLOSE
The new MIDIIO2K version would not have that bug (as far as my tests show right now).
Hope that helps clear things up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using MIDIO 2.10.027, that seems to be the latest version on sourceforge. Should I send it to you as attachement in a seperate message?
AND: Could you also give me the minimal example for writing a MIDI file? What I want to do is use a "shared" VBA codebase for both doing realtime and file IO by just using another object (Midifile instead of MIDIOut) with as many equal methods as possible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Constants: Having them defined in the OCX would still allow them to be defined in one's own code.
So in environments witout the popups, one could use one's own definitions, but in popup environments one would have the added comfort.
And with regad to my last message I meant:
should I send you the Excel sheet using the OCX and demonstrating the problem as an attachment?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi. You may use email, jtbalogh at aol.com, to send attachments at your convenience. Thanks for checking and testing the capabilities of the controls. Hope it works out for you :}
>> ... plays every second time
Wow, thats interesting. It would nice to see how OCX is attached to excel 2000 because I could not test that. I was able to test in regular visual basic 6.0 compiler. In the regular vb compiler, I was only able to duplicate the problem if the old controls were used. With the new controls and it seemed fine. Lets see what up ...
>> ... minimal example for writing a MIDI file
You may refer to the following for ideas *.
- midifile help file, Open method.
- midifile help file, Example Action Property.
- old mabry file demo, file-save menu
- old mlevoi lyric demo, MIDIcon() function
- miditest demo, midi recorder tab and record
- miditest demo, midi player tab and create file
* Demos may not represent the most accurate use of the controls but help show variations due to backward compabitility. Only the Miditest demo is considered the primary demo.
> ... Constants
May I suggest that maintaining backward compatibility with the old versions which did not have it is more a priority. A decision was also made to emphasize optimizing VB by using local variables wherever possible, and not endorse slowing it down with the dreaded windows OLE/COM communication.
So far there are more cons than benefits. Maintaining the automatic constants is difficult in future upgrades. Its updated in multiple places in the source. The help files and demos would have to show two sets of ways of using the controls. Using it incorrectly slows down the speed of a property or method by 10%, affecting real-time music applications.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your help. The Excel file is under way.
The pointers about where to look are very helpful. For me the problem is that MidiTest is very large, and it is not so easy to find the piece of information one needs. I will learn to read it.
I will also try to create a good Excel demo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the attachment. That is amazing. You could write an entire application with it like that.
After reviewing it, I noticed the midi controls you are using are version 1.10.007. You can tell by looking at the version property, MIDIOutput1.Version. I wonder if you tried Stop instead of Reset. This worked for me in excel.
MIDIOutput1.Action = MIDIOUT_STOP ' need in version 1.10.007
MIDIOutput1.Action = MIDIOUT_CLOSE
Forget about using reset in version 1.10.007, it has too many bugs anyway, which is whats happening here.
MIDIOutput1.Action = MIDIOUT_RESET ' bad
Also I noticed you declared the object with a variant variable. In general, you may access the object in its original data type. Using variants to access the control in OLE/COM communication is not always reliable.
Dim MidiOutput1 As MIDIOutput
Set MidiOutput1 = MIDI.MIDIOut
>> ... MidiTest is very large
Sorry about that. MidiTest was created to be like an active-x container to test the controls for any possible bug or feature when all the properties and methods interact with each other. Without that, than I could never prove the controls worked reliably under any situation.
You are right to suggest extracting the 40 different little programs in MidiTest into separate barebone samples. But I never had time. If I ever did, then the added concern about updating 40 different little programs with duplicate information in future upgrades seemed daunting. When I tried before, I could only simplify it by sharing code between little projects in external modules. However the external modules slowed down the program a lot in real-time music applications which was annoying. Most of the code ran better in one form and not in external modules (another limitation of VB, argh!).
I took the suggestion from Mike Levoi to at least extract 3 big features from MidiTest, called MidiIn, MidiPlayer, MidiPlayerStream, since those were crucial to test separately. In future upgrades of the control, that would mean I have to update those 4 demos at a minimum. Handling 4 compared to 40 was okay at the time.
Hope that helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I look at it, it is big. But I could not imagine any other way to prove the controls can do midi thru, regular midi out, midi out queue, midi out streams, midi record, etc, all at the exact same time the fastest possible without crashing.
Maybe someday, I could add one more demo that changes Miditest more modular (40 little external modules) and streamlined (one feature per module), without the extra code to optimize or fix limitations of VB program.
Let me know if you need anything else.
Have fun.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are right, I had the old controls installed.
The reason is that I am using Mike Levoi's XG-GS utilities,
and they need them and therefore seem to install them.
I had not remembered that, and forgotten to look for
MIDIIO32.OCX and MIDIFL32.OCX.
So I removed them, installed your controls once again,
and thereby created 2 problems.
1. Mike's utilities do not run any more.
2. The Excel stuff also does not work any more.
First, in \windows\system32 I used
regsvr32 midiio2k.ocx
regsvr32 midifl2k.ocx
to register the controls.
Then I opened an Excel sheet, went into the VBA IDE,
created a form, right clicked on the toolbox, and added the three controls MIDI In Control, MIDI Out Control, and MIDI File Control to the toolbox. The graphical symbols appeared on the toolbox, but the little popup window that appears when one puts the cursor on top of the control displays Unknown. With the old controls, it displayed the name of the control.
Trying to put a control on a form results in an error message, Element not found.
Now I have questions.
Did I do something wrong when installing the ocx?
Is there something more I need to do for the installation?
How can I get Mike's programs to work with the new controls?
Can the old and the new versions coexist?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>> ... Element not found (error message in excel VBA)
I see. Thats strange. I guess the Excel VBA IDE compiler is not the same as the regular VB 5.0 IDE compiler for some reason. Hand it to microsoft for that crazy problem. I will check on it and get back to you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lets not remove any controls. You could leave all registered in the windows sytem folder so your old programs are not affected. New programs can continue to use the old controls if you want.
>> ... old and the new versions coexist?
They can exist on the hard drive. They can all be registered. They can not be added in the same VB project at the same time.
>> ... Mike's utilities do not run
I am sorry I do not understand. Is there a particular utility you could show me that has trouble? On his website, he has the Mabry MIDI Examples, and Mike and I were able to add the new controls okay. The other utilites on the website, like XG/GS SYSEX Decoder, XG/GS MIDI Jukebox, etc. do not seem to need controls. They use VB5 runtime modules and regular windows API or MCI.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I had the problems with the controls, I uninstalled the old ones, and then Mike's XG-GS Reset stopped working. It seems to use the controls.
Meanwhile, I reinstalled them and the reset works again.
I am happy to hear the old and the new controls can coexist.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I reinstalled everything. Now Mike's stuff works, and my Excel files can use the old controls, and MidiTest uses the new controls. So peaceul coexistence is possible. Now I am waiting for the new controls to work with Excel also.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thread is continued in support request called, "Errors adding controls in Excel VBA".
Before we close this particular thread, I am glad the old controls still work for you, and hopefully MIDIOUT_STOP and declaring objects as MIDIOutput can keep you chugging along building more new and wonderful things. Have a nice day.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am really glad that these OCX finally are publicly available. It would help if there were some bare bones examplew. Especially, I would need an example of how to create a stream of notes and controller events with the minimal amout of code needed.
You may see the help file or download the demos for some examples or ideas.
Well established and popular experts on the subject of midi processing and code can also be found at:
GS - XG - GM MIDI Software
http://www.modemss.brisnet.org.au/~mlevoi/midi.html
MIDI Specification by jglatt
http://www.borg.com/~jglatt/tech/midispec.htm
Music Practical, by Martin Paton
http://pkl.net/~toasty/Project/FYP.doc
And, me? ;)
Have fun.
Joseph Balogh (jtbalogh)
One of the examples on Mike Levoi's site is written by me ;-). The one with Excel. In fact, I want to use your OCX libraries to improve the functionality of the Excel stuff.
And therefore I asked for simple example. It would be extremely helpful to have an introductory example in VB which would just play a simple scale and thereby show what the basic skeleton of a program using the OCX has to be.
>> ... The one with Excel
Heh, that's great. So your Erich. That excel file was really amazing. I noticed it used midi API directly and no OCX? I assume you would like to see the VB source and trace it back to the VC source which can show if the midi API are handled any better. Sounds good to me.
>> ... introductory example in VB
Any and all examples you have ever seen since 1998 could work with the ocx. It is backward compatible with just a different file name that you add into vb. I am sorry more comprehensive step-by-step instructions were not made available for easy review and research.
>> ... play a simple scale
For your specific example of playing a scale, try this,
Dim mIterationStart As Integer
Dim mIterationEnd As Integer
Dim i As Integer
MIDIOutput1.Action = MIDIOUT_CLOSE
MIDIOutput1.DeviceID = 0 ' or whatever port
MIDIOutput1.Action = MIDIOUT_OPEN
' Put message data in control
MIDIOutput1.Message = 0
MIDIOutput1.Data1 = 0
MIDIOutput1.Data2 = 0
MIDIOutput1.MessageTag = 0
MIDIOutput1.Time = 0
MIDIOutput1.Action = MIDIOUT_QUEUE
mIterationStart = 60
mIterationEnd = mIterationStart + 12 ' scale 13 notes starting from c4
For i = mIterationStart To mIterationEnd
' Note-On
MIDIOutput1.Message = NOTE_ON
MIDIOutput1.Data1 = i
MIDIOutput1.Data2 = 127
MIDIOutput1.Time = 250 * (i - mIterationStart) ' every 250 msec
MIDIOutput1.MessageTag = 0
MIDIOutput1.Buffer = ""
MIDIOutput1.Action = MIDIOUT_QUEUE
' Note-Off
MIDIOutput1.Data2 = 0
MIDIOutput1.Time = MIDIOutput1.Time + 1000 ' hold note 1000msec
MIDIOutput1.MessageTag = 0
MIDIOutput1.Action = MIDIOUT_QUEUE
Next i
MIDIOutput1.Action = MIDIOUT_START
>> ... skeleton of a program using the OCX has to be
Other barebone examples like above can be seen in the help file under "examples" and other pages of properties and methods. Various demos combine features which can later be dissected for pieces you are interested in. More advanced demos introduce extra code that keep the programs and controls more versatile, reliable, blah, blah, blah, under any possible situation at all times.
Have fun.
Thanks very much, that is exactly what I needed to be able to
get an easy start.
The main problem with my old code is that it did not do any time buffering, it just sent the messaged directly.
I always wanted to be able to do timequeued MIDI in Excel,
and the new kit will allow me to do this.
I used the old Excel MIDI stuff to compute tuninngs and send them
to the synth which then would be played in ral time.
No, for some more advanced projects, I need timequeues.
I found MIDIOX, which you also probably now.
It also works as OCX, but it does not do queueing.
So I really was happy when i found your project.
BTW: have you ever seen my realtime Fourier sound synthesis
Excel sheet?
sunsite.univie.ac.at/Spreadsite/
it might interest you if you like Excel stuff.
I put the example in Excel, and with tiny modifications it worked.
There is one problem: it only plays every second time it is called. Do you see a reason for that? The problem is completely reproducible.
Another question: Do you plan to define the system constants within the OCX later on? that would make sense, and it would be more self documenting in the object browser.
Here is another question.
Is it possible to change the unit time interval while a
sequence is already playing? I wopuld like to have a slider which allows to speed up or slow down the currently playing sequence. And is it possible to send
"intervening" real time messages while a midi queue is being played? I would like to set tha pan position with a real time slider while a stream is being played.
I will get back to you. (Wierd, the messages in this thread are not sorting and going all over the place. Whats thats about?)
Im back.
>> ... old code
Well, the old mabry controls on Mike's site do everything that you have asked me so far. The upgrade would not be needed at this time.
>> ... any time buffering ... sent the messaged directly
I see you used mcistring in your excel to play a midi file. Sure it would be nice to play a sequence of messages and not a midi file. If you are able to use OCX in excel, than try that.
>> ... plays every second time
Thats strange. Close does not really close and restart the queue. Until I check it more thoroughly, you can use this at beginning,
MIDIOutput1.Action = MIDIOUT_STOP
MIDIOutput1.Action = MIDIOUT_CLOSE
>> ... system constants
No. Mabry did not do it before because the OCX might be used in java, c+ or other compilers and can not assume they all have intellisense popups to help fill in the values as you type. System constants for each language may be different. Also using those constants can slow down the program because it uses OLE comunication to get the data all the time as its running. There are some other reasons that I documented in the source code.
>> ... change the unit time
You can use the PlaybackRate property.
>> ... plays every second time
Please verify which component is added to your project. Looks like you might still be using the old mabry MIDIIO32 OCX version 1.10.007 which does not close and reset the queue properly. In this case, remember to use MIDIOUT_STOP or MIDIOUT_RESET before restarting a queue.
MIDIOutput1.Action = MIDIOUT_STOP ' only if using version 1.10.007
MIDIOutput1.Action = MIDIOUT_RESET ' alternative, same as stop
MIDIOutput1.Action = MIDIOUT_CLOSE
The new MIDIIO2K version would not have that bug (as far as my tests show right now).
Hope that helps clear things up.
I am using MIDIO 2.10.027, that seems to be the latest version on sourceforge. Should I send it to you as attachement in a seperate message?
AND: Could you also give me the minimal example for writing a MIDI file? What I want to do is use a "shared" VBA codebase for both doing realtime and file IO by just using another object (Midifile instead of MIDIOut) with as many equal methods as possible.
Constants: Having them defined in the OCX would still allow them to be defined in one's own code.
So in environments witout the popups, one could use one's own definitions, but in popup environments one would have the added comfort.
And with regad to my last message I meant:
should I send you the Excel sheet using the OCX and demonstrating the problem as an attachment?
Hi. You may use email, jtbalogh at aol.com, to send attachments at your convenience. Thanks for checking and testing the capabilities of the controls. Hope it works out for you :}
>> ... plays every second time
Wow, thats interesting. It would nice to see how OCX is attached to excel 2000 because I could not test that. I was able to test in regular visual basic 6.0 compiler. In the regular vb compiler, I was only able to duplicate the problem if the old controls were used. With the new controls and it seemed fine. Lets see what up ...
>> ... minimal example for writing a MIDI file
You may refer to the following for ideas *.
- midifile help file, Open method.
- midifile help file, Example Action Property.
- old mabry file demo, file-save menu
- old mlevoi lyric demo, MIDIcon() function
- miditest demo, midi recorder tab and record
- miditest demo, midi player tab and create file
* Demos may not represent the most accurate use of the controls but help show variations due to backward compabitility. Only the Miditest demo is considered the primary demo.
> ... Constants
May I suggest that maintaining backward compatibility with the old versions which did not have it is more a priority. A decision was also made to emphasize optimizing VB by using local variables wherever possible, and not endorse slowing it down with the dreaded windows OLE/COM communication.
So far there are more cons than benefits. Maintaining the automatic constants is difficult in future upgrades. Its updated in multiple places in the source. The help files and demos would have to show two sets of ways of using the controls. Using it incorrectly slows down the speed of a property or method by 10%, affecting real-time music applications.
Thanks for your help. The Excel file is under way.
The pointers about where to look are very helpful. For me the problem is that MidiTest is very large, and it is not so easy to find the piece of information one needs. I will learn to read it.
I will also try to create a good Excel demo.
Thanks for the attachment. That is amazing. You could write an entire application with it like that.
After reviewing it, I noticed the midi controls you are using are version 1.10.007. You can tell by looking at the version property, MIDIOutput1.Version. I wonder if you tried Stop instead of Reset. This worked for me in excel.
MIDIOutput1.Action = MIDIOUT_STOP ' need in version 1.10.007
MIDIOutput1.Action = MIDIOUT_CLOSE
Forget about using reset in version 1.10.007, it has too many bugs anyway, which is whats happening here.
MIDIOutput1.Action = MIDIOUT_RESET ' bad
Also I noticed you declared the object with a variant variable. In general, you may access the object in its original data type. Using variants to access the control in OLE/COM communication is not always reliable.
Dim MidiOutput1 As MIDIOutput
Set MidiOutput1 = MIDI.MIDIOut
>> ... MidiTest is very large
Sorry about that. MidiTest was created to be like an active-x container to test the controls for any possible bug or feature when all the properties and methods interact with each other. Without that, than I could never prove the controls worked reliably under any situation.
You are right to suggest extracting the 40 different little programs in MidiTest into separate barebone samples. But I never had time. If I ever did, then the added concern about updating 40 different little programs with duplicate information in future upgrades seemed daunting. When I tried before, I could only simplify it by sharing code between little projects in external modules. However the external modules slowed down the program a lot in real-time music applications which was annoying. Most of the code ran better in one form and not in external modules (another limitation of VB, argh!).
I took the suggestion from Mike Levoi to at least extract 3 big features from MidiTest, called MidiIn, MidiPlayer, MidiPlayerStream, since those were crucial to test separately. In future upgrades of the control, that would mean I have to update those 4 demos at a minimum. Handling 4 compared to 40 was okay at the time.
Hope that helps.
>> ... MidiTest is very large
Now that I look at it, it is big. But I could not imagine any other way to prove the controls can do midi thru, regular midi out, midi out queue, midi out streams, midi record, etc, all at the exact same time the fastest possible without crashing.
Maybe someday, I could add one more demo that changes Miditest more modular (40 little external modules) and streamlined (one feature per module), without the extra code to optimize or fix limitations of VB program.
Let me know if you need anything else.
Have fun.
You are right, I had the old controls installed.
The reason is that I am using Mike Levoi's XG-GS utilities,
and they need them and therefore seem to install them.
I had not remembered that, and forgotten to look for
MIDIIO32.OCX and MIDIFL32.OCX.
So I removed them, installed your controls once again,
and thereby created 2 problems.
1. Mike's utilities do not run any more.
2. The Excel stuff also does not work any more.
First, in \windows\system32 I used
regsvr32 midiio2k.ocx
regsvr32 midifl2k.ocx
to register the controls.
Then I opened an Excel sheet, went into the VBA IDE,
created a form, right clicked on the toolbox, and added the three controls MIDI In Control, MIDI Out Control, and MIDI File Control to the toolbox. The graphical symbols appeared on the toolbox, but the little popup window that appears when one puts the cursor on top of the control displays Unknown. With the old controls, it displayed the name of the control.
Trying to put a control on a form results in an error message, Element not found.
Now I have questions.
Did I do something wrong when installing the ocx?
Is there something more I need to do for the installation?
How can I get Mike's programs to work with the new controls?
Can the old and the new versions coexist?
>> ... Element not found (error message in excel VBA)
I see. Thats strange. I guess the Excel VBA IDE compiler is not the same as the regular VB 5.0 IDE compiler for some reason. Hand it to microsoft for that crazy problem. I will check on it and get back to you.
>> ... removed them
Lets not remove any controls. You could leave all registered in the windows sytem folder so your old programs are not affected. New programs can continue to use the old controls if you want.
>> ... old and the new versions coexist?
They can exist on the hard drive. They can all be registered. They can not be added in the same VB project at the same time.
>> ... Mike's utilities do not run
I am sorry I do not understand. Is there a particular utility you could show me that has trouble? On his website, he has the Mabry MIDI Examples, and Mike and I were able to add the new controls okay. The other utilites on the website, like XG/GS SYSEX Decoder, XG/GS MIDI Jukebox, etc. do not seem to need controls. They use VB5 runtime modules and regular windows API or MCI.
When I had the problems with the controls, I uninstalled the old ones, and then Mike's XG-GS Reset stopped working. It seems to use the controls.
Meanwhile, I reinstalled them and the reset works again.
I am happy to hear the old and the new controls can coexist.
I reinstalled everything. Now Mike's stuff works, and my Excel files can use the old controls, and MidiTest uses the new controls. So peaceul coexistence is possible. Now I am waiting for the new controls to work with Excel also.
Thread is continued in support request called, "Errors adding controls in Excel VBA".
Before we close this particular thread, I am glad the old controls still work for you, and hopefully MIDIOUT_STOP and declaring objects as MIDIOutput can keep you chugging along building more new and wonderful things. Have a nice day.
Bug fixed.
See support request called, "Errors adding controls in Excel VBA".
Things work! So now my old Excel MIDI sheet is not needed any more, avarthing can be done much nicer with your controls.