Posts by AtonyB

    here's an update for you:
    we did not announce a release date on NAMM because OS5 at this time was a technology preview. we were planning on a release last month, the update is feature complete but we ran into two issues we wanted to address before shipping the update. those issues were old issues and also present in OS4.x. as it turns out, addressing those issues takes more time than we anticipated in the first place, that's why you're waiting for the update since a while.
    we'll do out best to ship before the holiday season starts. in our opinion it is better to test a little more and wait a little longer, so hopefully you share this notion and manage to stay patient for a little longer.
    best, marc


    Indeed - I'd rather a good update delayed for a little while than a bad one that is bad forever...

    If you read above:


    Quote

    NMS i don't think you get the difference between aliasing due to oscillator design - which remains in the virus due to backwards compatibility (I guess they want peoples' old presets to keep sounding the same) and aliasing as a function of sample rate - the two are independant. They also fixed/improved it using the wavetable oscillators if you even care.


    That oscillator design has been around for some time (not sure if it goes ALL the way back) - and they have superceded it.


    Also, if you are using the virus for traditional mainstream sounds, you will get oodles of polyphony out of it (maybe, it really depends on what you are using it for which makes discussions about how much polyphony is 'enough' moot) - but if you are using it to get true VA sounds you need the polyphony because of how much is left at the end of all the effects. By the time you are emulating 3 minimoogs, two polymoogs and an ARP Odyssey you really have to think about how many notes you are going to get out of it.


    For example, when we did this: http://youtu.be/gdjECAvwJFk?hd=1 - every sound beside vocals, bass guitar and drums (obv) is coming from the Virus. None of the presets, besides the claptrap, are lightweight and I've had to do a lot of fine tuning to get enough polyphony out of just one Virus for that. I'm working on a TI and the extra power from a TI 2 wouldn't go amiss, but I don't have £2000 to chuck around right now.


    Lets set aside the complete rewrite and jigging around of memory, etc. programming a higher sample rate might entail, the reduction in polyphony, even on a TI 2 would make this impossible.


    The best you could hope for is that they find a way of doing SRC right on the end of the signal chain to get you your exotic sample rate - but then if that's what they do, you can do that yourself - especially if you are recording it part by part with no FX - I'm assuming your wave file editor has a simple enough sample rate conversion...


    OR - you could just work at 96 kHz... just a thought...

    Incidentally, I do record my virus one part at a time for projects - but I do use the onboard FX (Duh! why would you rob yourself of the TIs fantastic FX section??) and, like I said before, most parts consist of more than a couple of notes, so some polyphony is appreciated, so I would be upset if Access came along and said hey we've quartered the polyphony on the virus just to satisfy a couple of nutters... can you imagine??


    And while we're at it.


    Quote

    It's about having enough bandwidth to keep the stuff just above your hearing limit from being reflected back down well into your hearing range... and not having to interfere with your audible range with the necessary filtering to prevent it. It's also about avoiding phase distortion. The further away your fitlers are, the less chance of phase distortion.


    That is what guard bands are for - 48 kHz gives you a more than generous guard band.

    NMS i don't think you get the difference between aliasing due to oscillator design - which remains in the virus due to backwards compatibility (I guess they want peoples' old presets to keep sounding the same) and aliasing as a function of sample rate - the two are independant. They also fixed/improved it using the wavetable oscillators if you even care. There is ALWAYS a trade-off between precision and performance and different products/organisations will be comfortable with different points. For VST programmers its easy because if it underperforms they can just blame your pc for not being powerful enough, regardless of how inefficient their code is.


    I don't care what deadmau5 recommends about the virus - he may have found a workflow that works for him but it's very arrogant for you to assume you know the working practice of the entire, lets say 'pro', virus user community or that you can suggest there is a right and wrong way to do it. Personally I need more than one or two notes at a time, I don't know if thats particularly unusual...


    Besides which, you will be completely oblivious to the varying usage of RAM on the Virus, it's not like it has a RAM usage meter (or maybe it does and thats what the load meter is...) - you just don't know... unless you have a debugger attached.



    Quote

    You mean like the modelling in a virtual analog synth called the Virus? Were you trying to imply that the Virus doesn't need what those other synths need and have?


    I don't know what you're talking about. The virus uses oversampling only when it needs to - I really don't get how this point seems to slip you by every time.

    Yes all codecs need AA filtering (although sigma-delta ADCs have very loose external filtering requirements). What I mean is that if sampling an oscillator (which is effectively what matching the waveform in the time domain does) were to sound crap, then any sampling would - which is clearly not true. It does lack the inter-cycle variation you may see on any oscillator, however.

    Here's my technical understanding, please correct me if I'm wrong :



    1- the output sampling rate and the internal processing sampling rate are two very different things.


    Absolutely - oversampling may be necessary for non-linear models.



    Quote

    2- an output sampling rate high enough to allow non-audible frequencies is a waste of space


    Correct - It contains no useful information, even if you plug it into an amp you are going to mic up, it is not conceivable that you could construct a situation where the non-audible frequencies have any impact on the audible ones, mainly because it would have to be a headroom issue and you wouldn't be using a signal biased in that way. Nonlinearities such as distortion tend to only create frequencies above individual input frequencies (note this is not true for AM or FM).


    Quote

    3- a wav file at 96kHz can be downsampled to 48kHz without any audible difference (for a human).


    Correct - a causal (ie zero latency) AA filter would be more than sufficient for this owing to the massive guard band available.



    Quote

    4- depending on how the internal audio processing is done, a processing sampling rate higher than the output sampling rate can be beneficial : this is what we call oversampling.


    Indeed - as is the case for the Virus.





    Quote

    5- Are there good reasons for wanting an output sampling rate higher than 48kHz?


    Bigger numbers sell better. Technically you are spreading bit quantisation noise over a broader spectrum (some of it in the inaudible part, which can be filtered), but its already at -96dB for 16-bit so the cost of extra bandwidth really isn't worth it.



    Quote

    6- Wouldn't running the virus at 96kHz (internally) enhance synthesis/processing quality?


    Only in certain parts, where they already oversample, elsewhere it makes no difference beyond increasing the buffer sizes required and the number of MACs for no real benefit.



    Quote

    7- What about processing latency? A lot of processing can't be done in parallel, so halving the polyphony may not suffice. I mean, if one of your processing units is sequential and can only process up to 60k samples every second, no matter what you do to polyphony, you can't achieve real-time performance in 96kHz.


    In general DSP algorithms can be very easily multi-threaded, if you have more MAC (multiply and accumulate) units you almost unconditionally get more usable MACs (this is what CUDA and OpenCL are all about), but the Virus has 2 DSPs in it (I don't know how many multipliers that makes but probably either 2 or 4).


    For traditional DSP systems it's all about clock speed vs sample clock - if you have a 120 MHz DSP with a dual MAC unit you get 240 MACs, so if you run at 48 kHz you get 5000 MACs per sample. This means if you run at 96 kHz you get 2500 MACs per sample, BUT for the same spectral resolution (ie an 'equivalent' filter) you also need twice as many filter terms which means an effective increase in load of 4x (so, very loosely, if you could manage a polyphony of 4 before, you can now only manage 1) - not only that, but your sample buffers need to be twice as long, which may result in you even running out of memory (making it impossible, so your polyphony may be reduced further). All the while you will not hear any difference in the output (in general, not specific to the virus).


    Looking at some of the other posts I don't think this is possible to overstate - this has nothing to do with oversampling which you may do on an individual effect because the model requires it... with a robust enough interpolation algorithm the benefit of already having the higher sample rate does not go anywhere towards offsetting the above disadvantage. Delay/Phaser/Chorus/Flanger, etc. effects all interpolate... for those high frequencies in phaser effects you need to do subsample delays and the quality of your interpolation really pays off in a great sound (interestingly this is why 'analogue' phaser effects sound great as they have a fixed number of samples delay and they modulate their 'sample clock' speed continuously; a luxury you cannot enjoy in a complex system like the Virus.



    Quote

    On the non-technical side, market adapts to what people will buy, not to what people will benefit from ; it's a fact that (for the same price) a 96kHz soundcard will sell better than a 48kHz one. Wether it makes an audible difference or not. Because, in everyone minds, bigger numbers are better. So I think arguments based on what recent gear do are irrelevant here.


    Amen - I mean the audio bandwidth on blu-ray is ridiculous 192 kHz with 24-bit - as if any consumer equipment is low noise enough to even achieve 24-bit resolution let alone them being able to tell if it could. The only reason they get away with it is because the demands of the video processing make the audio a peripheral issue so it makes no real difference cost-wise.



    Quote

    Ruari: it's very hard to estimate the quality of any oscillator only by looking at the waveform. At least, look at the spectrum, which is more important here.

    You do not want to generate a signal whose waveform looks close to the reference signal : you want to generate a signal whose frequency content is close to the reference signal frequency content. Because this is the only thing your ears will pay attention to.

    And guess what : in a digital world, the closest waveform generally sounds like shit.


    I hate to pick up on this here - but if that were absolutely true then audio sampling would also sound like shit. Looking at audio spectra is also a fuzzy art - you have to be very careful about what window size you use and what windowing technique you use as the results can vary profoundly - with windowing you have to trade off SNR performance with the ability to distinguish close peaks which merge due to spectral leakage (also a function of window length).


    Getting the frequency content just right is all well and good so long as you get the PHASE information right, too, otherwise your waveform won't be the right shape - and if you put your signal through a non-linear effect you CAN hear a difference. Phase information is an all to often ignored part of signal processing despite the fact that if you don't look after it you can get unpredicted drops in frequency response and trash your SNR performance. Just look at what happens if you apply a Hilbert transform to a square wave (which sort of gives you the 'loudest' sound for a given headroom).

    I'm sorry NMS, I didn't realise you were an expert on ADCs and DACs - here was me thinking that with a basic interpolation filter on a 44.1kHz DAC you could comfortably represent all audible frequencies with near-zero attenuation and phase distortion - but obviously you know better despite most likely not having any experience in DSP system design. The example you produced - the prevalence of which we don't yet know - cannot be explained simply by looking at the sample rate and MUST be due to a feature of the software on the Virus - be it the resampling algorithm to generate the waveforms at different frequencies, or downsampling after oversampling stages in the signal chain (ie an intermediate AA filter). It could also be differing rounding error in the coefficients used for any of the signal processing going on in there.


    If you have audible aliasing at 44.1 kHz you are doing something wrong (which I would doubt) or you've had to make a compromise to squeeze more performance out of the system (probably) - at 48 kHz you have no excuse as the guard band is massive. Beyond that you are full of shit. But like I said - believe what you want. The more people believe this nonsense the more room there will be for competitiveness. The memory and processing power requirements of increasing the sample rate are devastating which is why you would only upsample for physical modelling if you have some awkward difference equations to implement (like the virus does, of course), but an interpolation algorithm, rather than upsampling the signal wholesale, can (and has been, for me) very effective.


    Also, I never said the 'added brightness at 48 kHz' is due to added aliasing - but I might have said the difference was down to an anti-aliasing or interpolation filter, depending on whether its a downsampling stage or the DAC stage, the latter being irrelevant for USB or S/PDIF audio.


    At any rate I don't appreciate the offensive language and it's not in the spirit of this place - I'd spend more time demonstrating why you are wrong and how ignorant and foolish you look by being so rude, but I have a signal processing platform to finish developing before I finish my PhD in DSP so I'll leave it where it is. You can troll more if you want, and I'm sure you will, but no amount of boasing about how plugging something into a spectral analyser is easy for you (as if it would be difficult for anyone ?( ) will change the fact that a lot of very qualified people (not slow people who like being corrected as you so eloquently put it) chose 44.1 kHz as a sample rate for CD audio with very good reason and that 48 kHz is enough of a concession to relax the requirements of SRC by having a huge guard band (4 kHz!) whilst keeping the bandwidth low.


    All the while forgetting that almost nobody can hear 18 kHz, let alone 20kHz anyway!

    Incidentally - there is a discrepancy in the behaviour in some circumstances between 44.1 kHz and 48 kHz - which I would put down to being a feature of the Virus... It's by no means a physical limitation. Also, the difficulty in reproducing it also demonstrates what a fringe issue it is.

    They have made some important steps recently - the next version which is now in beta will have even more midi support (directly linking midi imputs to FL 'ports', but I've had a VST that did that for me for years) - but I agree that they can randomly dig their heels in on random things. Bottom line is, though - and I don't know if im alone in this (maybe I am ??) but the Virus works smoothly, bug free and low latency on my system - always AT LEAST as good as any external hardware, except with the TI bit.

    Maybe its possible to help him to avoid wasting a lot of time and effort into trying to get something he has been fooled into thinking he needs.


    Also, by 'got it right' I clearly meant that their decision to not compromise performance by including an option for higher sample rates (I'm assuming the devices are fundamentally capable). It's not as simple as sacrificing voices, either, as they will need twice as much memory in certain stages (or half the maximum delay time for FX, etc.), possibly exceeding the amount of RAM available on the system. That is, unless they do a SRC stage at the front end which renders it utterly redundant.


    I would pick more voices, longer delays on FX and more USB channels every time (although presumably a successor will probably be USB 2.0+, so that may be moot). You can get good standalone sample rate converters if you truly are desperate, even ones that are integrated into an audio device.


    Incidentally, ACE17 - that would probably yield interesting results, although I think maybe not everything can be appropriately scaled down by a factor of 2 (maybe some non-linear/non-adjustable behaviour in distortions and analogue filter, etc.)

    I get on well with my M-Audio EX-P as you can actually calibrate it depending on what you are putting it into (it has a pot on the side). It also has a switch on the back, which seems to do nothing - or fixes something that doesn't matter on my gear...

    Well, since we are succumbing to trolling.


    Actually I conceded the point about the interpolation filter (or perhaps earlier stages in the system) behaving differently at 48k - to an extent I was surprised about.


    Polyphony is a scarce resource, though - and im sure people prefer more voices (especially those that play live), and are happy to put up with a 'measley' 48kHz. The fact that there are only one or two people bitching here about it means they probably got it right.


    $30k sounds like a lot of money for a bit of extra precision in a frequency band nobody cares about - I really hope that investment remunerates itself. To think people have the timerity to believe they can release worldwide success records using equipment that cost less than $5000...


    Anyway - I have no time for audio snobbery - especially today.

    Actually hardware does have latency - but it's usually pretty small.


    Using hardware with FL is a breeze - and has been for at least the last 3 years.


    FLStudio does have latency compensation, and fixed compensation is fine since your input latency shouldn't be varying.


    What's the difference between real-time export and recording? Especially on the virus which only supports real-time operation. OK so its a macro, but it's no faster to activate a macro than it is to arm the relevant audio channel and press record...

    I've read a lot of incorrect information in this thread LfmC seems to be very anti FLStudio. I will point out that I use my Virus TI Desktop (it makes no difference whether it is a desktop or a keyboard or whatever) in FL Studio just fine with no latency problems beyond what you have when you record from external hardware. What is more, I work with it with absolutely no stress or hassle - as I have been for most of the many years I have owned it (although It has improved over the years). Incidentally I usually use 10ms latency (i.e. 480 samples), a power of two buffer doesn't seem to make much difference to me anyway.


    Generally its not a problem, anyway, but when I'm using precisely timed arps I use live mode to preview stuff and get it all set up - then, as you should do, I take it out of live mode to record (as the delay in live mode is variable, wheras out of live mode it is fixed). As with any recording from hardware I then nudge the wave file on the play list if it is slightly out of time (fastest way to fix it, I find, even with automatic latency compensation).



    "My intent is to add the Virus channel similar to any other channel, and have it play back in my playlist. I certainly don't want to record any sequence just so I'm able to insert it as a sample, I want the Virus channel to play back normally like any other channel. "


    I'm confused by this comment, as you will have to record it eventually as you can't do offline rendering with the Virus.



    "P.S.: Can I get around the latency by using MIDI In/Out rather than USB? "


    This will put you in the situation you are with any other external hardware - all you end up with is the input latency of your soundcard + FL Studio.



    Also, you haven't said whether you are using analogue inputs, S/PDIF or the USB channels... I generally use S/PDIF as my main monitoring input, but lately the USB inputs have been just as seamless for me....