Hi InSub,
Do you also experience audio getting "stuck" ?
I found a workaround, which is to always let, in the background, a media player (vlc, foobar, winamp) on pause (not stop)
Cheers.
Beiträge von Ace17
-
-
Hi Marc,
Where can we find the installer log files? -
+1000
-
Same problem here... (running Windows XP 64).
-
-
The TI's USB issues are not caused by MIDI itself.
We agree on this point. I wasn't even talking about the TI's USB issues here.
A lot of hardware MIDI sequencers/controllers don't suffer from jitter. I'm not saying MIDI is flawed.
I'm saying implementing accurate MIDI I/O on a PC running a non realtime operating system is very hard to get right ; and can never be guaranted to always work.First of all, it's from 2007
I know, but it applies to all of us who run Windows XP, and to some extent, Windows 7.however that has more to do with other hardware/host problems or midi interface issues
Exactly. FL devs didn't manage to get it right, for example. And I suspect that Access devs want the VC to also work inside FL studio.
By implementing sample accurate timing - i.e not doing real-time synchronous MIDI output - they avoid such issues. -
No offense, but this is pretty off-base. MIDI does not fluctuate by as much as 15 ms randomly, ever. I can't speak for FL, and I have heard that it kind of sucks for midi, but in logic pro and cubase MIDI is always dead-on.
Have a look here : http://www.soundonsound.com/so…icles/cubasetech_1207.htm
-
Hi,
Sample accuracy may be more important than it looks. Let's say you have an arpegiator-like pattern of 16th notes at 180 bpm, you have nearly 80ms per note. AFAIK, and from a lot testing, under Windows, it's very hard to get a real-time accuracy better than 15ms. If you're controlling a synth by MIDI, it means your synth will sometimes receive a note 15ms late. It's clearly audible, the pattern just doesn't sound right.
You can do this test with the FL studio MIDI output, other DAWs seems to cope better, but there's no completely reliable way to get hard-real time MIDI sending under Windows, especially if your CPU load increases. The best of the workarounds seems to trigger MIDI sending based on callback from the audio driver, because they're frequent and accurate (which means your timing accuracy now depends on your buffer size).
I'm not saying sample accuracy is needed, because 80ms is a lot of samples (a little more than 3K at 44100Hz), and clearly, the audio could be out off by a lot of samples before we would notice.
I'm saying good old real-time MIDI, under Windows, does not guarantee you a musically-acceptable timing accuracy.PS: I'm talking about Windows XP here (Windows 7 has been enhanced on this point).
-
-
I'm using Windows XP 64, and I'm not going to upgrade my Windows.
Discontinuing the support for Windows XP would mean for me to stick with last driver/plugin version. -
p.s. ok, please leave this thread now!!!
Seriously dude, what's wrong with you? -
ok u can ask the same question tape in 1000 BC why Microsoft did no bring Windows 7 already?
get it?!
p.s. if something is still not implemented already it does not meen that it is not a good feature....Bagpula - The Return
Coming soon -
Handy. I'm a programmer and I work primarily in functional languages, so this form of recursion is familiar to me.
OTOH, how in the hell do you mentally picture the result of this interaction? Is this something that's intellectually achievable, or is it only practical to suck it and see?
I may be wrong, but Isn't it simply a first order differential equation?
You're basically saying "slope = k * function", thus the result is an exponential. -
When you send MIDI notes to the Virus, does the little note sign show up at the bottom right corner of the LCD screen ?
-
Why want to keep in sync both menus? It would only offer less control!
-
Can I imagine Access removing all other clock rates in order to add one additional rate in the options of 88khz? Uh... no.
No, but you have to admit it might raise some new issues. Like having different max delay times depending on the current sample rate (which is currently not the case). Nothing impossible, at first sight.
Anyway, do you have an idea of why Access didn't already make these sampling rates available?
-
You mean like the modelling in a virtual analog synth called the Virus?
No, not at all! Maybe I wasn't clear ; I was talking about this. There are simpler methods to implement the building blocks of a VA synth (and yes, many of them will also benefit a lot from oversampling). These methods will try to match the behaviour of analog parts, but without simulating the inner workings of these parts.
Were you trying to imply that the Virus doesn't need what those other synths need and have?
No. I was saying that synths that do physical modelling are designed to benefit from oversampling. Because physical simulation requires you to discretize time anyway, and most of the time, a smaller timestep means a bigger accuracy.
But there are other methods, some of them called "bandlimited". For example, when summing sine waves to make a square wave you don't need to oversample (see here). Yes, you're simulating a VCO, but this is not physical modelling.For who? Snow users? Niether polyphony nor memory have ever been an issue with my Ti2. My PC has to handle an infinitely heavier load in comparison.
I wasn't necessarily talking about the Virus here. I was saying that oversampling a fixed time delay was non-desirable, because there would be no quality benefit and it would use more memory.
As for the memory on the Virus, you can hit the limits when playing with delay at low tempos. The max delay time for one part of the Virus is 693.6ms, which roughly corresponds to 30000 audio samples at 48kHz. Do the math, we're talking about allocating something like 100kbytes for one part, that's very small. Not the kind of choices you would make when designing something for a PC! I think polyphony is irrelevant here.
-
I hate to pick up on this here - but if that were absolutely true then audio sampling would also sound like shit
By audio sampling, do you mean what an ADC does? Correct me if I'm wrong, but isn't there a lowpass filter before the actual sampling in a ADC?Anyway, thanks for your answers!
-
There are a reasons why modern physical modelling VSTs allow you to use a huge upsampling and allow you to run
at 96khz rate. They did not put this staff just for fun, but there re is a benefit of using it. And even if you will down
sample the end result to 48khz there still will be benefit
Exactly.Processing your audio at a higher sampling rate than the output sampling rate is called "oversampling". As I said above, and as Marc also said, not all sound processing methods will benefit equally from oversampling.
For example, physical modelling greatly benefits from oversampling : that's why the VSTs you're talking about have such options.
But a delay unit will benefit a lot less from it. Worse: now, your delay needs more memory! And memory is a scarce resource on the Virus (not so much on PCs). So you don't improve sound quality, but you increase memory usage.The point is, blindly oversampling the whole synth is far from optimal. In terms of memory, in terms of polyphony, and in terms of quality.
As Marc said, some parts of the Virus already use oversampling. Why not let those who know, i.e the Access Team, make these choices for us?
-
If a higher sample rate can't happen would better filtering be a potential solution?
Once the higher frequencies have been reflected back to the audible range, it's too late : you can't filter them without also filtering "real" frequencies (the harmonics of your sound).A filtering that would work would need a higher sampling rate : you would then naively synthesize your "sharp" signal at 4x your final sampling rate, let's say 192kHz. Then, you would apply a low pass filter to remove everything above, let's say 20kHz : so now your 192kHz signal does not contain anymore frequencies that can't be represented by a 48kHz sampling rate. You can then peacefully downsample it to 48kHz, aliasing will not occur. So you see that to apply this method, you need to work internally at a higher sampling rate.
Please note that there are A LOT of other methods to simulate an oscillator, this one being the simplest! I don't know how the Virus works. For example, another method works by synthesizing all the harmonics (sines) and then summing them together. So basically, as you're summing sinusoids here, you don't have to worry about aliasing. This method, compared to the previous one, would benefit a lot less from a higher internal sampling rate.
