Author |
Topic: Latency added by MIDI-OX / Yoke with scripts ? (Read 3447 times) |
|
chkk
New Member
MIDI-OX rules
 
Gender: 
Posts: 10
|
 |
Latency added by MIDI-OX / Yoke with scripts ?
« on: Aug 23rd, 2001, 3:08am » |
 Quote  Modify
|
Hi,
has anyone ever measured the latency added by using the scripting engine (with no processing, simply echoing the midi data) ?
Scenarion 1 (no MIDI-OX)
Masterkeyboard (local off)
to PC midi interface
to recording software
back to synth modules.
Scenario 2 (with MIDI-OX / Yoke)
Masterkeyboard (local off)
to PC PC midi interface
to MIDI-OX
to the scripting engine
to an event handler (VB/C++ any speed difference ?)
echoed back by the scripting engine to a MIDI Yoke port
to recording software
back to synth modules
Scenario 1 should give me about twice the "normal" midi latency (one roundtrip) plus a small overhead from the recording software.
Is there a measurable difference between Scenario 1 and 2 ?
As the MIDI-OX COM component is an out pf process server, there should be some overhead and task switches for each midi event receive and sent.
Greetings,
Christian
|
|
 IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
 |
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #1 on: Aug 24th, 2001, 8:22am » |
Quote Modify
|
I haven't measured it, but it seems to me you could get a quantitative measurement by using a sequencer along with MIDI Yoke. You could record the output of an existing MIDI Track (routed back to the input - via MIDI Yoke) onto a new track and then examine the time differences.
If you do this, be careful to first turn off MIDI thru, to avoid feedback.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
Lynn
Member
Gender:
Posts: 16
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #2 on: Sep 7th, 2001, 5:20pm » |
Quote Modify
|
Although I have not actually measured the delay introduced by a script, it is actually quite substantial. For most human playing of notes this is not too noticeable. However, playing handfuls of chords rapidly can result in
a fairly long stream of "stacked up" midi messages that result in a detectable delay.
Also, the use of other controllers (volume, expression) which can generate very long streams of midi messages very rapidly, there is more noticeable delay.
Pitch Bend controllers are even worse. Use of a pitch bend controller is totally unsatisfactory when routed through a mox script.
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #3 on: Sep 7th, 2001, 6:10pm » |
Quote Modify
|
An interpreted script is always going to suffer some latency, but this should decrease as machines get faster.
It's still valuable to be able to make quick sweeping changes in a script. Anything that actually needs a production environment can be coded and compiled by VB or C++ (yes, you can use the MIDI-OX COM interface in C++, or any other language that supports COM).
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
tiny_elvis
New Member
Posts: 5
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #4 on: Oct 15th, 2001, 8:16am » |
Quote Modify
|
I am suffering from this too. I have written a script to edit continuous controller data (to convert a Tascam TM-D1000 for use as a pro-tools mixing console) but it actually hangs vbscript when too many faders are scrubbed.  It works when they are filtered only through the midi-ox program, but that is not an option. I'm compiling a VB version now...I'll let you know if it clears up the latency problem. ..... BTW... great program Jamie!
Chris
http://chriskline.com
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #5 on: Oct 15th, 2001, 11:07am » |
Quote Modify
|
Another option would be to try using the polling method of data retrieval (as opposed to the Connection point sink). I haven't measured the difference, but it's worth a try.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
tiny_elvis
New Member
Posts: 5
|
 |
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #6 on: Oct 16th, 2001, 1:38am » |
Quote Modify
|
It helped a little - It no longer hangs wscript from the flood of data, but the faders are still a second or 2 behind. And this is a PIII-800. I will definately use that technique on the VB version I'm making (currently held up because I can't figure out how to build a private assembly in .net) Of course, there is no problem without the script. The trick is: The input to PT is through controller data...no big deal for MIDI-OX. But PT outputs 8 byte chunks of sysex data (with the same information). It's easy enough to translate the sysex back to controller messages...just not through the main MIDI-OX program. I &H8 .net
Chris
http://chriskline.com
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #7 on: Oct 16th, 2001, 2:05am » |
Quote Modify
|
I haven't played with .NET (yet). What is a private assembly?
I have thought of supporting SysEx back to MIDI mapping a few times, but the complexities and difficulty have outweighed the usefulness, so far.
If you want an alternative to the VB/.NET route, you might look at Python -- it's HEX handling is a lot cleaner than using VB. Of course there are downsides to that too: it's interpreted (not compiled), learning curve, limited UI support. The best bet for what you're doing might be to use MIDI-OX and C++ via COM.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
tiny_elvis
New Member
Posts: 5
|
 |
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #8 on: Oct 16th, 2001, 5:50am » |
Quote Modify
|
Welllllll.....I finally gave up on .net - too packaged and web-oriented. Although I think the real problem was that the beta 2 is not set up to compile non-.net applications. A private assembly is microsoft's term for a build that includes it's dlls and other resources in one directory so it doesn't need to be installed.
Anyway, I grabbed a copy of Visual Basic 4 off the net and compiled the exe without all that .net crap.....and it's just as slow! Perhaps I'm not interfacing the type library correctly....it seems to work the same as moxarp (i was worried about the message calling it a wscript when you close it - but moxarp does that too). I think you said something in another post about COM being limited in speed also... I'm just an ASP programmer so I'm over my head here. Should I just start work on a stand-alone app that changes the raw midi data? How does MIDI-OX work so much faster when the filters are set internally? Thanks for your help,
Chris
http://chriskline.com
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #9 on: Oct 16th, 2001, 12:00pm » |
Quote Modify
|
Unfortunately, it's difficult to pinpoint what is causing the latency, and it may be a combination of things. COM in a single apartment (our SysEx view uses a RichEdit control that requires this) is somewhat slow. SysEx must be transferred in buffers, regardless of the message size, and this will be slower than MIDI short messages. VB4 and WSH are interpreted not compiled (VB4 can make an exe, but it's just the VB code: it's still interpreted). When you have a lot of data passing through, things can get clogged up.
The MIDI-OX internal mapping is highly optimized, and is just performing transforms on a 4 byte MIDI message (DWORD) in place. Only the NRPN and SysEx handling is more involved. Again, SysEx will be slow by its nature: it was never intended to be a Realtime communication protocol.
If you do want to create an app independent of MIDI-OX, I recommend getting a copy of Maximum MIDI (available from the MIDI-OX store). It has some good libraries and demonstrates how to thunk down to the Multimedia 16 bit DLL's.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
tiny_elvis
New Member
Posts: 5
|
 |
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #10 on: Oct 17th, 2001, 7:56am » |
Quote Modify
|
OK...I have it solved...unfortunately I could not do it through MIDI-OX scripting. I got hold of a copy of VB6 (dont ask where i get all these VB's from  ) and rebuilt my little tranlation program one more time thinking maybe it was the interpreted language thing, but it was still too slow. So I finally stumbled on to a reference to a program called Bome's MIDI Translator mentioned on the digidesign web board.
It did the trick...it's a programmers sort of application...it just takes incoming midi data and converts it to new data based on "variables" you set. It worked at first, but it was not fast enough either... Pro Tools would crash after about 2 minutes from some kind of buildup of sysex data....I would run out of memory! ... He had a beta version posted that was more optimized though and it works perfectly!
So I'm a happy guy now with a fully automated Pro Tools console I got for $300! Thanks for helping me solve this Jaime... I learned a lot about MIDI and VB in the last 2 days and you have been very helpful. The world needs more good people who aren't afraid to share their knowledge and time.
Chris
http://chriskline.com
|
|
IP Logged |
|
|
|
Jamie OConnell
Administrator
Gender:
Posts: 2027
|
|
Re: Latency added by MIDI-OX / Yoke with scripts
« Reply #11 on: Oct 17th, 2001, 9:10am » |
Quote Modify
|
I'm glad you found a solution. When I get a little time, I will check out this bome tool for ideas.
|
|
IP Logged |
--Jamie
Music is its own reward.
|
|
|
|
User Forum ::
Powered by YaBB
Home 
Help 
Search 
Members 
Login 
Register
Reply
Notify of replies
Send Topic
Print