Sorry i don't want to became obsessive but jst a couple of things.
"I fear, also SCOPE is addicted to some mobo/OS clocks too,- the PCI cards as well as the PCIe card of a XITE box or a XITE-PCIexpress card connected to a Windows laptop,- they all use computer reference clocks."
That is not the case. Scope uses it's internal oscillators. It is a completely separated system from the computer you are running the software on. 95% are algo's calculated on the dsp's.
"The SCOPE card may behave different when you use it´s physical MIDI I/Os in standalone "
The "may" is not needed. Scope physical midi output is hardware midi, calculated on the dsp's. Running an RTOS.
The sequencer midi is different as it communicates with windows.
The worst thing a man strangles against is his assumptions...
Mixing in Scope - Device latencies/phase problems
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
Lets recap:
I am running cubase (5.52, XP) on a computer with SCOPE cards (PCI).
I am trying to get the MIDI from what is programmed in the cubase piano roll - to the scope synths running (on the same pc) - with no large timing offsets (MIDI jitters..?)
these jitters which I am experiencing result in the scope synths playing "off time" - In an inconsitant manner - i.e. - i am ignoring the fixed latency.
Since Im pretty sure there is an audio buffer - (from the PC to Scope) I thought there would also be a MIDI buffer - and MIDI events that were stamped by cubase on the way out would be received by scope and "triggered" at the correct timing ....
So , either
1) there never was a MIDI buffer - it just goes in and triggered as soon as it "arrives" to the SCOPE environment
2) there is a buffer - but there is a mismatch / non-use of the timestamps ....
Am I correct so far ?
I am running cubase (5.52, XP) on a computer with SCOPE cards (PCI).
I am trying to get the MIDI from what is programmed in the cubase piano roll - to the scope synths running (on the same pc) - with no large timing offsets (MIDI jitters..?)
these jitters which I am experiencing result in the scope synths playing "off time" - In an inconsitant manner - i.e. - i am ignoring the fixed latency.
Since Im pretty sure there is an audio buffer - (from the PC to Scope) I thought there would also be a MIDI buffer - and MIDI events that were stamped by cubase on the way out would be received by scope and "triggered" at the correct timing ....
So , either
1) there never was a MIDI buffer - it just goes in and triggered as soon as it "arrives" to the SCOPE environment
2) there is a buffer - but there is a mismatch / non-use of the timestamps ....
Am I correct so far ?
Re: Mixing in Scope - Device latencies/phase problems
there is nothing to be done if windows is involved.
windows is not realtime and midi is not a huge priority for windows.
use a hardware sequencer and your midi timing will improve by leaps and bounds, or be a careful engineer and keep everything aligned however you can, including adjusting events manually. most music won't be affected in any way by these issues, maybe a simplification of certain techniques might make a better end-product, even if individual elements aren't as awesome.
windows is not realtime and midi is not a huge priority for windows.
use a hardware sequencer and your midi timing will improve by leaps and bounds, or be a careful engineer and keep everything aligned however you can, including adjusting events manually. most music won't be affected in any way by these issues, maybe a simplification of certain techniques might make a better end-product, even if individual elements aren't as awesome.
Re: Mixing in Scope - Device latencies/phase problems
There is a buffer inside "midi sequencer dest".
That is fulled with "when possible" windows (or any other non-rtos) midi messages. Timestamps are disregarded.
Scope reads that buffer and use it. End of story.
If you are able to fill a "midi buffer" with unmistakeable events scope will reproduce it unmistakeably.
As most hardware devices.
Audio is sample accurate (most of the time, not to speak about buffer overruns, under-runs, glitches, hips and pops)
because everyone would hear it. Midi is a technology of the past.
In general just sample your stuff and move on. Other ways are a lot sophisticated.
That is fulled with "when possible" windows (or any other non-rtos) midi messages. Timestamps are disregarded.
Scope reads that buffer and use it. End of story.
If you are able to fill a "midi buffer" with unmistakeable events scope will reproduce it unmistakeably.
As most hardware devices.
Audio is sample accurate (most of the time, not to speak about buffer overruns, under-runs, glitches, hips and pops)
because everyone would hear it. Midi is a technology of the past.
In general just sample your stuff and move on. Other ways are a lot sophisticated.
Re: Mixing in Scope - Device latencies/phase problems
Yogi you could post your MIDI file here I and others could run it in Cubase to a Scope synth and see what happens.
Re: Mixing in Scope - Device latencies/phase problems
I can't resist. 
It's like anything else.
"We have the best stuff".
"The computer can now replace the whole studio".
"Everyone can be a musician, nor to say a rocket engineer"
One process can make your coffee, and another can make you rich.
Surf the internet, do your automatic updates on the
background, and at the same time do a surgical operation.
I believe midi jitter is the revenge of the developers to the piracy matter... And what a revenge!
It's like anything else. "We have the best stuff".
"The computer can now replace the whole studio".
"Everyone can be a musician, nor to say a rocket engineer"
One process can make your coffee, and another can make you rich.
Surf the internet, do your automatic updates on the
background, and at the same time do a surgical operation.
I believe midi jitter is the revenge of the developers to the piracy matter... And what a revenge!
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
dante wrote:Yogi you could post your MIDI file here I and others could run it in Cubase to a Scope synth and see what happens.
Just program 2 bars of 16 notes and trigger an drum osc or something - record the audio ouput back to the sequncer (as audio) and see where the transients land ...
(Or loopback and rerecord the midi .... But I didnt do that)
@fra77x - my cubase is legit
And P.S. - I heard that a legit cubase tranfers alot of data thru the dongle when operating ... So ... Maybe its a vice versa thing ...
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
Yogimeister wrote:
2) there is a buffer - but there is a mismatch / non-use of the timestamps ....
fra77x wrote:There is a buffer inside "midi sequencer dest".
That is fulled with "when possible" windows (or any other non-rtos) midi messages. Timestamps are disregarded.
Scope reads that buffer and use it. End of story.
If you are able to fill a "midi buffer" with unmistakeable events scope will reproduce it unmistakeably.
1) Is there anyway scope can "regard" the time stamps ?
2) Is there any way to time stamp them via an external clock (when using only cubase and scope)?
Re: Mixing in Scope - Device latencies/phase problems
"@fra77x - my cubase is legit"
I didn't spoke about cracked/normal versions. I talked about regulating the amount of work and the quality of results according to real income...
Cracked versions work fine by the way, or like the legitimate ones...
"I heard that a legit cubase tranfers alot of data thru the dongle when operating"
Don't believe what you hear. What an unbelievable myth!! Through the dongle!
"Is there anyway scope can "regard" the time stamps ?"
Scope 7.
"(Is there any way to time stamp them via an external clock"
Only Rolex or omega with usb time stamp capability
Am I correct so far ?
Yes
Nor professional studio's have better midi timing. The difference (the whole difference) is that a studio is a business and it tries to make a result. It will use whatever equipment available, it will try to use it in the best possible and practical way. But will focus on the results. It is very common in professional companies to have very silly, unpredictable problems. Problems that seem non professional or counter productive. The professionals know how to address these problems, hide these from the final product and most important to get a product at the end.
It is believed that the trip is worth more than the destination. The reason is that during the trip (in that case, a particular problem and the endeavor to surpass that problem) benefits us with knowledge and experience that we haven't thought at the beginning.
p.s. If you are desperate to achieve sample accurate results with midi, take my sdk class. I will tell you it's pretty simple
sorry for the adv
I didn't spoke about cracked/normal versions. I talked about regulating the amount of work and the quality of results according to real income...
Cracked versions work fine by the way, or like the legitimate ones...
"I heard that a legit cubase tranfers alot of data thru the dongle when operating"
Don't believe what you hear. What an unbelievable myth!! Through the dongle!
"Is there anyway scope can "regard" the time stamps ?"
Scope 7.
"(Is there any way to time stamp them via an external clock"
Only Rolex or omega with usb time stamp capability
Am I correct so far ?
Yes
Nor professional studio's have better midi timing. The difference (the whole difference) is that a studio is a business and it tries to make a result. It will use whatever equipment available, it will try to use it in the best possible and practical way. But will focus on the results. It is very common in professional companies to have very silly, unpredictable problems. Problems that seem non professional or counter productive. The professionals know how to address these problems, hide these from the final product and most important to get a product at the end.
It is believed that the trip is worth more than the destination. The reason is that during the trip (in that case, a particular problem and the endeavor to surpass that problem) benefits us with knowledge and experience that we haven't thought at the beginning.
p.s. If you are desperate to achieve sample accurate results with midi, take my sdk class. I will tell you it's pretty simple
sorry for the adv
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
fra77x wrote:
p.s. If you are desperate to achieve sample accurate results with midi, take my sdk class. I will tell you it's pretty simple
sorry for the adv
You can see I'm digging up a sand storm. can't you ....
But instead od sharing your knowledge on how to get this Scope system running well - you offer to sell it via your "SDK class" and then turn to troll this thread by dissing and saying that it's "not professional" to care about these problems . and it's not professional to not want to spend money - and then, turning all the way around - claiming "Tight MIDI" is "Your sound" .... common ... either help or not ... but stop pissing all over the thread ... thanxz.
Re: Mixing in Scope - Device latencies/phase problems
what are you talking about ?
ok i won't help! there is a cracked version of my sdk class by the way
ok i won't help! there is a cracked version of my sdk class by the way
Re: Mixing in Scope - Device latencies/phase problems
midi is midi and windows is windows.
if you need tighter midi, use a hardware sequencer or an Atari.
if you need tighter midi, use a hardware sequencer or an Atari.
-
jksuperstar
- Posts: 1638
- Joined: Mon Nov 15, 2010 12:57 pm
Re: Mixing in Scope - Device latencies/phase problems
This post is about tuning your PC for possible lower latency and more reliable timing. It addresses mostly windows, and doesn't change the way SCOPE works, or how it deals with MIDI. It can *potentially* have a positive result on how Windows and your DAW handles MIDI.
If you use Win XP sp2 or earlier, the TGT/QPC timer is an especially odd issue as Bud noted. WinXP SP3, Vista, Win7, and Win8 all support the newer HPET timer that is built in to all southbridge chips since 2005. HPET is a 64bit timer that runs around 15MHz, compared to the other timers that run at various frequencies about 1khz-3.5MHz. So it has better resolution, and newer southbridge chips (especially newer than core2 era), have consistent and fast access to this register and its IRQ.
There is a way to force windows to use ONLY the HPET timer, and this can be the best way, but needs to be manually done. However, it's still not universally used by all drivers or software, especially older drivers that happen to work in Vista, Win7 or Win8, but were really written in WinXP days. So of course, some systems or combination of drivers means default use or even disabling HPET may be better. Research on the issue would probably make one insane, since some kids think that their system boots slower or games don't respond as fast with HPET ON, and translate that into slower performance. Our case is different, we want everything to STAY IN SYNC. There are four timers or so available in a PC, and from a properly coded drivers and OS point of view, this keeps them all in sync. Again, no guarantees. Trying it will cost just a couple of reboots and testing time. Only try 1 of the options below at a time.
1. enable HPET (should be already enabled in any modern BIOS first, type & run this command in CMD.EXE, then reboot): *MUST BE ADMIN IN CMD.EXE*
bcdedit /set useplatformclock true
2. disable HPET (also disable this in BIOS first, type in CMD.EXE, and then reboot afterward):
bcdedit /set useplatformclock false
3. default HPET setting:
bcdedit /deletevalue useplatformclock
You can run "bcdedit" on the command line with no switches, and it will report "Windows Boot Loader" settings, so you can see if "useplatformclock" shows up or not. It's best to check your DPC Latency (using DPCLat or Latency Mon), change settings, and after reboot check again. Or do real tests with MIDI and Audio, and if it helps, great. If it hurts, you can go delete the value and return things to the way they were.
Further, you may find differences using ASIO vs. ASIO2 with different drivers. I can't predict what works or doesn't work for your system, and this info is all I have on the subject. I can say it's worth experimenting with the three settings if you are having issues getting to lower ULLI settings, or seeing unexplained MIDI jitter.
If you use Win XP sp2 or earlier, the TGT/QPC timer is an especially odd issue as Bud noted. WinXP SP3, Vista, Win7, and Win8 all support the newer HPET timer that is built in to all southbridge chips since 2005. HPET is a 64bit timer that runs around 15MHz, compared to the other timers that run at various frequencies about 1khz-3.5MHz. So it has better resolution, and newer southbridge chips (especially newer than core2 era), have consistent and fast access to this register and its IRQ.
There is a way to force windows to use ONLY the HPET timer, and this can be the best way, but needs to be manually done. However, it's still not universally used by all drivers or software, especially older drivers that happen to work in Vista, Win7 or Win8, but were really written in WinXP days. So of course, some systems or combination of drivers means default use or even disabling HPET may be better. Research on the issue would probably make one insane, since some kids think that their system boots slower or games don't respond as fast with HPET ON, and translate that into slower performance. Our case is different, we want everything to STAY IN SYNC. There are four timers or so available in a PC, and from a properly coded drivers and OS point of view, this keeps them all in sync. Again, no guarantees. Trying it will cost just a couple of reboots and testing time. Only try 1 of the options below at a time.
1. enable HPET (should be already enabled in any modern BIOS first, type & run this command in CMD.EXE, then reboot): *MUST BE ADMIN IN CMD.EXE*
bcdedit /set useplatformclock true
2. disable HPET (also disable this in BIOS first, type in CMD.EXE, and then reboot afterward):
bcdedit /set useplatformclock false
3. default HPET setting:
bcdedit /deletevalue useplatformclock
You can run "bcdedit" on the command line with no switches, and it will report "Windows Boot Loader" settings, so you can see if "useplatformclock" shows up or not. It's best to check your DPC Latency (using DPCLat or Latency Mon), change settings, and after reboot check again. Or do real tests with MIDI and Audio, and if it helps, great. If it hurts, you can go delete the value and return things to the way they were.
Further, you may find differences using ASIO vs. ASIO2 with different drivers. I can't predict what works or doesn't work for your system, and this info is all I have on the subject. I can say it's worth experimenting with the three settings if you are having issues getting to lower ULLI settings, or seeing unexplained MIDI jitter.
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
Thanks,
I have already tried both ASIO1 and ASIO2 IOs in scope ... behavior seems unaffected ... (Not sure if I should connect something to the ASIO2 DEST clk input ...)
I will try the clock thing tomorrow ...
I am running WinXP SP~2 (I ran an offline SP3 update - but I am not sure if it completed properly ... my computer properties show SP2 ...).
My CPU is Intel Core2 6600@2.04
BTW- as far as actual latency - I think it's pretty tight ....
(and Thanx for the help ...
I have already tried both ASIO1 and ASIO2 IOs in scope ... behavior seems unaffected ... (Not sure if I should connect something to the ASIO2 DEST clk input ...)
I will try the clock thing tomorrow ...
I am running WinXP SP~2 (I ran an offline SP3 update - but I am not sure if it completed properly ... my computer properties show SP2 ...).
My CPU is Intel Core2 6600@2.04
BTW- as far as actual latency - I think it's pretty tight ....
(and Thanx for the help ...
Re: Mixing in Scope - Device latencies/phase problems
Thats not a test where MIDI latency alone is involved - you then have the additional latency of recording back into DAW.Yogimeister wrote:Just program 2 bars of 16 notes and trigger an drum osc or something - record the audio ouput back to the sequncer (as audio) and see where the transients land.dante wrote:Yogi you could post your MIDI file here I and others could run it in Cubase to a Scope synth and see what happens.
If you have to do that (rather than mix the entire arrangement to a stereo master in realtime) then the resulting track will most likely need adjusting in my experience.
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
Of course ....
But latency would be CONSTANT throughout the whole part ...
In the test I mentioned , EACH HIT has a different offset ...
(Otherwise I would just qunatize the first hit and the rest would also be quantized ....
THATS my problem (not fixed latency ...)
But latency would be CONSTANT throughout the whole part ...
In the test I mentioned , EACH HIT has a different offset ...
(Otherwise I would just qunatize the first hit and the rest would also be quantized ....
THATS my problem (not fixed latency ...)
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
@JK - i think HPET is called ACPI2 by intel (or so ive googled...)
This is my bios screen (last image is the ACPI page)
(There are actually a few other pages that might matter so I'm posting them as well ...
Your help would be appreciated in regards to optimization ...
(This was a custom build done by a shop that is supposed to be optimized for scope - but Im not really sure it was a great job ...)
This is my bios screen (last image is the ACPI page)
(There are actually a few other pages that might matter so I'm posting them as well ...
Your help would be appreciated in regards to optimization ...
(This was a custom build done by a shop that is supposed to be optimized for scope - but Im not really sure it was a great job ...)
- Attachments
-
- image.jpg (163.55 KiB) Viewed 5504 times
-
- image.jpg (230.31 KiB) Viewed 5504 times
-
- ACPI2 page
- image.jpg (156.13 KiB) Viewed 5504 times
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
And the southbridge :
(I actually dont think I am using any PCIE .... Can I check if I am and if not - disable it ?
(I actually dont think I am using any PCIE .... Can I check if I am and if not - disable it ?
- Attachments
-
- image.jpg (166.37 KiB) Viewed 5504 times
-
Yogimeister
- Posts: 323
- Joined: Sat Jan 12, 2008 10:12 am
Re: Mixing in Scope - Device latencies/phase problems
I cant find bcdedit on my system (WinXP) .... Any advice ?jksuperstar wrote: You can run "bcdedit" on the command line with no switches, and it will report "Windows Boot Loader" settings, so you can see if "useplatformclock" shows up or not. It's best to check your DPC Latency (using DPCLat or Latency Mon), change settings, and after reboot check again. Or do real tests with MIDI and Audio, and if it helps, great. If it hurts, you can go delete the value and return things to the way they were.
(Would "/usepmtimer" in my boot.ini work the same ? )
-----
(I checked my DPC and it is usually less than 100us - with an absolute maximum of 496us (with scope running but not cubase - yet)
(It actually seems to be higher when the pc is idle .... I left it and came back and the latency was near a constant 496 ... Or is that normal ?)
Re: Mixing in Scope - Device latencies/phase problems
bcedit is for windows vista and later, in xp you can edit the boot.ini file with notepad.Yogimeister wrote: I cant find bcdedit on my system (WinXP) .... Any advice ?
(Would "/usepmtimer" in my boot.ini work the same ? )
here an explanation of the useruptimer option:
http://blogs.technet.com/b/perfguru/arc ... t-ini.aspx