|
Just what I was looking for Dave!
Thanks much!
|
|
|
|
|
One quick question, are you terminating the application by pressing a key or by the close button on the console window. If the latter, that could be why it's hanging.
Edit: Some research reveals this quote from MSDN:
"To stop recording, use midiInStop. Before closing the device by using the midiInClose function, mark any pending data blocks as being done by calling midiInReset".
So it appears that the procedure should be Stop, Reset, Unprepare and free the buffers, then Close. I haven't used the Stop as it appeared (possibly erroneously) that Reset did the same thing, and easy fix thankfully.
modified 11-Oct-12 17:54pm.
|
|
|
|
|
Well, in the begining, the first time I tried your first example, I closed it via the close button of the console, and quickly learned a leason. When I get this error now, it is only with Maple VMC. In my WPF app, I have a onclose function that closes the midi ports. I don't know of a way to do this with a console window however, and as it's just for simple testing, I'm not too worried about that... Just have to remember to close it properly with any keypress. 
I've got to reboot now, as I tried your simple Midi, and, guess what. I did it again! Not I've got an active service and it won't run because it's locked. lol.
I'm guessing that's just what I needed. Thanks once again! 
Jeff
|
|
|
|
|
BTW, I removed Maple VMC, and installed Midi-Yoke, and problem above appears resolved. I suspec you are right about Maples driver. I've heard others having problems with Maple also, so I'll put that down as accurate.
|
|
|
|
|
Thanks, good to know 
|
|
|
|
|
I've done some more investigation into this and have found others that have had this problem with different hardware.
The problem seems to be that some drivers block on the Reset call until all the MIDIHDRs are returned. This means that UnprepareHeader cannot be called on any buffer (during a reset only) until they have all been returned to windows, so can't be done in the callback!
I have managed to code around this by setting an IsResetting flag when Reset is called, having an IsReturned flag on each buffer that is set it is returned and when the last buffer is returned - launch a thread (so the callback returns!) that unprepares and frees the buffers. A bit of a pain but it appears to work and should do on all systems
|
|
|
|
|
That's good to know Dave!
I've been playing more with the Pure MIDI code, and determined his exit code also failed on closing the MIDI output. It's not closing the buffers either. Between your code and the Pure MIDI code, I've gotten the Short MIDI in figured out, and the outgoing Long & Short msgs figured out.
I thank you for all your efforts once again!
|
|
|
|
|
Got another query here...
When a SYSEX is sent out over MIDI, Should it not trigger a MIM_LONGDATA message in my app regardless of if I have code to do something with that message or not?
Or, Is there something I need to do to setup my callback to see these messages?
|
|
|
|
|
MIM_LONGDATA will be sent to your callback only if (some of these are obvious so I'm sure you can ignore them but I'll include them for completeness!):
- The MIDI Input is open (midiInOpen)
- The MIDI Input is started (midiInStart)
- There is at least one buffer available
- The buffer is prepared (midiInPrepareHeader)
- The buffer has been added (midiInAddBuffer)
- The buffer has been (re)initialized correctly (dwFlags cleared etc if reusing the buffer)
What caught me out the first time I ever tried it was that I hadn't done 4 and 5. I expected a buffer to just be given to me that the system created for the SysEx. Unfortunately, it will only fill buffers we create and add.
|
|
|
|
|
Interesting!
I assumed that because the port was open, that the message would be toggled regardless in the callback, and if it wasn't handled, it would then be ignored. That would explain why I don't see that occurring at all then. I need to create a buffer, prepare it, add it, and be sure I have the right flags then before it is even visible in the message cue.
Thanks again Dave!
|
|
|
|
|
Correct, and no problem.
dwBufferLength needs to be set to the size (in bytes) of the buffer.
lpData needs to be a valid memory location that unmanaged code can write to. I use Marshal.AllocHGlobal using the same value as dwBufferLength. Make sure you free this once it's returned with Marshal.FreeHGlobal.
dwBytesRecorded will tell you how many bytes have been received.
If the buffer isn't big enough, or more SysEx is received it will use the next buffer so you need to ensure you have at least two available.
You only need to clear the flags if you are reusing the buffer once you are done with a used one. Reusing can give better performance as there is no need to be constantly allocating and freeing memory. I just add new new ones and discard the old personally.
|
|
|
|
|
In a C# 2008 console application, I am getting the following error:
"Error 4 The type or namespace name 'eDataContext' could not be found (are you missing a using directive or an assembly reference?)".
I am getting this error on the following line of code:
eDataContext rptData = new eDataContext();
I have created the *.dbml file, I have dragged a table onto the designer surface, I have added the *.dbml file to the project folder that will be using the *.dbml file, and I have built the application.
The name 'eDataContext', in the name of the datacontext object that is located in the eD.designer.cs file.
The only thing that i can think to try is to add something in an app.config file, but I do not know what to add.
Thus can you tell me and/or point me to a reference on what i can do to solve this problem?
|
|
|
|
|
You must have missed importing the namespace. Find out what namespace eDataContext belongs to and import it in your code. For example, if eDataContext belongs to dcof.Entities namespace, you must write this line of code in the .cs file where you use the eDataContext class.
using dcof.Entities;
|
|
|
|
|
I have a piece of software that compiles and installs properly. It uses loosely coupled events to pass information to another application. All of the code works except for the other application actually receiving the event and processing it. It works on Windows XP perfectly but not on Windows 7.
Thanks
|
|
|
|
|
Without seeing any code, we can only offer guesses at best. It could be security related.
|
|
|
|
|
Due to company policy I can't post the code. If it were security related what would your best guess be. I have turned off UAC and ajusted permissions on many registry entries just to get it installed.
Thanks,
|
|
|
|
|
Well, for a start, I'd be using remote debugging on a debug version of the app installed on that machine and I'd check to see whether exceptions were being consumed. Also, is your LCE a COM event? If so, that can sometimes be a problem and you may have to adjust DCOM settings.
|
|
|
|
|
It is indeed a com event. I will have a look at DCOM settings. Thank you. If you have any specific suggestions let me know. Also if you can point me to a good remote debugging tutorial I would appreciate it. I am actually an Electrical Engineer with a a computer science degree and this is one of my first major coding projects and have never worked with com/com+/dcom before.
Thanks,
|
|
|
|
|
Good luck - this is pretty arcane stuff I'm afraid. Anyway, you should start here[^] for remote debugging.
|
|
|
|
|
I am beginning to realise this, have had so many issues over that last couple weeks just getting the majority of it working, now this last piece is taking forever.
Thanks for the help.
|
|
|
|
|
If it works on XP, but not on Windows 7, its most likely a security issue. Not necessarily a DCOM security issue, but one app being run under a different security context then the other. For example, one is running as a service and the other is a desktop app, or something like that.
|
|
|
|
|
One is running as a service and the other as a desktop type application, do you have suggestions on how to work around this?
Thanks,
|
|
|
|
|
Ha! Called it!
If you go into the service control panel, right click on your service & view the properties (Log On) tab... is it running as Local System? If so, you might need to turn on the interact w/ desktop checkbox. If that doesn't work, try run it as yourself (for testing).
|
|
|
|
|
That does not seem to have worked either. Both changing user and the desktop check box failed to succeed for me. It is a fairly complex program I am stuck with that uses MSMQ to talk across computers and then uses loosely coupled events to send the messages to another program which fires them out a serial port. Still hoping you have come more ideas.
Thanks,
|
|
|
|
|
Did you try tweak the security settings with dcomcnfg? Do you get any COM errors on the side that is sending the events?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
