Author |
Topic: COM server + dense midi data = CPU hog (Read 2227 times) |
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
 |
COM server + dense midi data = CPU hog
« on: Dec 9th, 2004, 5:35am » |
 Quote  Modify
|
Ok, I made some progress with my VBS script (Thanks, Jamie).. However it seems to me that COM server cannot handle 10 expression pedals (realtime controller messages). Is there any way around this? Is WSH the bottleneck? I am using a VBS script, that is being interpreted by "wscript.exe" version 5.6.0.6626 that I found in my "winnt\system32" folder (installed with windows).
Or is it possible for some particular messages to bypass the com interface and go directly to the MOX output ports? Can DivertMidiInput be set only for note on/off mesages or something similar?
This is my setup:
P4 Northwood @ 2.4 (HT disabled)
1G DDR 2700 Samsung Ram (dual channel)
Mb: QDI 865pea
Win2Ksp4, midi-OX7
Any ideas?
... please =)
|
|
 IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #1 on: Feb 26th, 2005, 12:58pm » |
Quote Modify
|
I did optimize my code a little bit, but the problem persists. The task manager shows heavy cpu usage for the MidiOX, and not for the cscript.exe, so I guess that the COM server is the bottleneck here... just guessing, anyone
I intend to rewrite my script in C++ language, but I am afraid this will not solve my problem... Should I write my own "virtual midi drivers" in order to avoid COM interface
Please, all ideas are more than welcome!
Thanks, ml
|
|
IP Logged |
|
|
|
dayton
Member
MIDI-OX Rules!
Posts: 15
|
|
Re: COM server + dense midi data = CPU hog
« Reply #2 on: Feb 28th, 2005, 3:28pm » |
Quote Modify
|
I just might be able to help a bit, but only if you specify what it is you need to do. I use up to 16 continuous controllers sometimes, but only change them two or three at a time. However, I have successfully used a setup with ldrs which continuously send CC-data, at one time with 6 at the same time, as well as playing a midi-piano at the same time. The scipt was straightforward VBS being interpreted by the WSH.
Don't underestimate the bottleneck which may occur in your MIDI-adaptor.
So, the question is: how many CC-messages will be being sent at the same time, and at what rate (time between messages)?
|
|
IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #3 on: Mar 1st, 2005, 5:26pm » |
Quote Modify
|
Thanks for help!
I use midi keyboard which is sending poliphonic aftertouch messages. Aftertouch messages contain information about aftertouch pressure (range: 0-127). Example: If I press one key and apply aftertouch to it, it generates approximately 100 messages in a second... so therefore if I play few heavy chords, it generates cca. 500 messages/s... And besides that I also use two expression pedals (range: 0-127) - which gets me to something like 700 messages/s.
Simply running all this data through the script (without code) takes about 40% of the CPU, adding any code to it gets me to the 100% quite easily. I would really like to know what is the bottleneck here, because 2.4G processor should be up to the task here, shouldnt it.. (Well, I am just guessing - I am NOT a programmer, and this "COM interface" is a totaly scary thing if you ask me ;)??
Thanks again!
(I can post my code, if anyone interested...)
|
|
IP Logged |
|
|
|
mbncp
New Member
MIDI-OX Rules!
Posts: 2
|
|
Re: COM server + dense midi data = CPU hog
« Reply #4 on: Mar 2nd, 2005, 1:51pm » |
Quote Modify
|
CPU seems a little hi.
I have an app (html) that uses vbscript (~2000 lines of code) and it does a lot of processing(ez-ag midi guitar).
I have 2 midi pedals (fcb1010) moving continues, the ez sending note on/off + sysex (I actually only use the sysex) and the time code as well, strumming wild and the script playing a heavy midi file, all at the same time, and I don't 'hear' any latency.
On my PIV 3.4 I get something like 5-13% cpu usage (global).
Actually I rename the html hta, so windows doesn't do checking and doen't send each function to the Anti-virus program.
Also, I'm not using MIDI-OX, as I wasn't able to use it with html (I needed a GUI), so I made my own ocx. But I do then send the output to different midi-yoke ports.
|
|
IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #5 on: Mar 3rd, 2005, 12:00pm » |
Quote Modify
|
Hmmm, I started writing code in VB6 (Visual Studio 6) and I will post my results as soon as i make any usefull A/B comparisons.
However, the more I am exploring this field, i get the feeling that I will need to write app completely of my own (not using COM and midiYoke).. but I need to learn a A LOT before I'll be able to do it.. ;(
|
|
IP Logged |
|
|
|
dayton
Member
MIDI-OX Rules!
Posts: 15
|
|
Re: COM server + dense midi data = CPU hog
« Reply #6 on: Mar 4th, 2005, 12:23pm » |
Quote Modify
|
I just read your mail about VB. It is certainly true that a compiled language can do it's thing much faster than an interpreted language, but that doesn't mean that VBS can't do what you described. I use a Doepfer LMK-4 with aftertouch; I'll test some 10-key translation stuff tomorrow and see what I come up with for problems.
|
|
IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #7 on: Mar 4th, 2005, 5:34pm » |
Quote Modify
|
Thanks for help! Does this Keyboard (LMK4) have poliphonic aftertouch?? I use 'GEM S2' keyboard and I use poliphonic aftertouch to trigger new instruments with different level of aftertouch pressure. I generate note-on and note-off messages on different aftertouch levels for every key - it's very fun to play with ;)
|
|
IP Logged |
|
|
|
dayton
Member
MIDI-OX Rules!
Posts: 15
|
|
Re: COM server + dense midi data = CPU hog
« Reply #8 on: Mar 22nd, 2005, 1:44pm » |
Quote Modify
|
ok, finally have time to write something (I'm on tour, and had no time to look for an internet café)
So: no, the LMK4 doesn't have polyphonic AT, which I discoverered as a result of your query, because I had never used AT before. Nonetheless, I connected up all the LDR's I have and switched on the AT on the keyboard to see what kind of bottlenecks I could get.
Setup: AT, six CControllers and very fast playing while running Reason. My Laptop has a 3ghz Pentium4, 512MB RAM. All of the messages coming in through MIDIYoke are being translated into other, similar messages. All six CC messages and the AT are constantly sending information.
(Now I have to rely on my memory, because this was about two weeks ago.) Reason was taking up 13% of CPU capacity, and MIDIOX between 15% and 30%. In any case, I could play as fast as I possibly can, which is very fast, but not notice any pauses in the flow of notes (this is always my most important test for the usefulness of a setup.)
One question: are you using a polling scheme in your program, or sink? My experiences have been satisfactory with sink, but in some sequencing loops I wrote with the polling option, there were little pauses. Also, the polling option made the CPU work all of the time at something like 98%, as one would expect with a loop.
The program structure I use most of the time has to check through a good 10 to 15 cases for each MIDI-note coming in, so if I can get by so well with this amount of data coming in, the speed of the script can't be much of an issue.
As for the amount of data running through the CPU, don't even think about it. My 3Ghz represents a baud-rate roughly 1500 times that of the MIDI-Standard. In order to know where the real bottle-necks are, I'll have to do some more research.
Other info: Using MAX/MSP, I put together some applications doing much more complex things than a few MIDI-Translations, and couldn't come close to overloading the machine, even with six CC's controlling a large group of samples and two live audio inputs.
Last Saturday was the premier of the first performance I've given using MIDIOX a VBScript as the sole translation instances in my setup, and both the performance and the weeks leading up to it showed this solution to be very reliable. The only thing which I need to improve is foriegn interruptions in the scripts function; there must be some standard applications (or a virus...) occasionally doing something which pauses the script for enough time to be noticeable. Instead of searching for this myself, I wish someone could give me a list of tasks running in Windows XP which I should simply disable, as well as a list of tasks which should be expected in XP.
Good luck in all endeavors,
Dayton
|
|
IP Logged |
|
|
|
Peter L Jones
Expert
Hit it
Gender: 
Posts: 978
|
|
Re: COM server + dense midi data = CPU hog
« Reply #9 on: Mar 23rd, 2005, 6:16am » |
Quote Modify
|
Hope this helps...
In my processes list in task manager, removing all the bits I "shouldn't" have running on my "music PC"... I get:
csrss.exe
dcfssvc.exe
explorer.exe (of which one you can't get rid of)
launch.exe (actually maybe this shouldn't be here)
lsass.exe
midiox.exe
ScsiAccess.exe (I've a SATA RAID controller?)
services.exe
smss.exe
svchost.exe six times (I think I can trim two off that)
System
System Idle Process
winlogon.exe
I can break software installation by disabling two of the svchost entries (they come from system services automatically started that aren't used most of the time)... But I know how to fix it  .
|
| « Last Edit: Mar 23rd, 2005, 6:17am by Peter L Jones » |
IP Logged |
"...Playing fast around the drums is one thing. But to play with people for others, to listen to, that's something else. That's a whole other world." -- Tony Williams
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #10 on: Mar 23rd, 2005, 6:58pm » |
Quote Modify
|
For services and processes monitoring I suggest using processExplorer(www.sysinternals.com).. It has many great features and works great in conjunction with Dependency Walker (Active Debugger and profiler)... Anyway, much better than Windows Task Manager.
http://www.sysinternals.com/
http://www.dependencywalker.com/
Both these are small, free, opensource and non-setup utilities.
ml
|
|
IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #11 on: Mar 23rd, 2005, 7:59pm » |
Quote Modify
|
I use Connection Point sinks. I never tried the polling method, as I believe that Connection point sinks are appropriate for this kind of use (event-driven programming).
However, there are situations where I would like my code to execute while none of the events are generated (for example: when I stop playing, I want the code to slowly close the 'release' parameter on the gain envelope of the instruments)... I didnt know how to solve it, so I simply activated 'active sensing' messages on my keyboard, which is countinuosly sending midi messages, therefore continuosly executing my code (it is not cpu intensing).
..still searching for better solution, though
ml
|
|
IP Logged |
|
|
|
dayton
Member
MIDI-OX Rules!
Posts: 15
|
|
Re: COM server + dense midi data = CPU hog
« Reply #12 on: Jun 12th, 2005, 2:50pm » |
Quote Modify
|
I know the solution: Max/MSP. I hesitated to say this before because Midiox got me started on this road and has served me admirably. Also, Max costs a bundle. However, there is a program called PureData which is basically the same as Max and costs nothing. I recommend it for almost anything you want to do; certainly for anything MIDI-related.
To get the low latency times you will need, you'll have to fiddle with the Audio-Setup dialog; it affects the MIDI too. You will also want to install MIDIYoke.
Believe me, if you like doing strange things with MIDI, this is the program for you.
|
|
IP Logged |
|
|
|
ml
Member
MIDI-OX Rules!
Posts: 13
|
|
Re: COM server + dense midi data = CPU hog
« Reply #13 on: Jun 12th, 2005, 4:21pm » |
Quote Modify
|
Yes, the MAX and the PureData has been on my "to-learn" list for quite some time now.. I will get to it soon. And, yes, I DO want to make the weird things with midi =)
Hey people, feel free to visit my webpage about interactive midi software:
http://freeweb.siol.net/muzzzika/ims/
|
|
IP Logged |
|
|
|
|
User Forum ::
Powered by YaBB
Home 
Help 
Search 
Members 
Login 
Register
Reply
Notify of replies
Send Topic
Print