I’m a happy (registred) Renoise user and have used renoise for many of my vinyl releases.
I’ve just bought the new Virus TI Desktop, which is a great piece of technology as you al may already know.
I’ve just started testing the TI in Renoise yesterday and encountered some major problems when using the TI as VSTi plugin in Renoise:
problem1.
Rendering Ti’s output gives a distorted sound
problem2.
Latency!
problem3.
You can use the TI’s onboard audio interface for smooth integration, but normally, you should be able to use your own interface. When doing so, the output gives cracks and pops.
Maybe its the TI software that causes these problems, the VSTi plugin is not completely finished yet, but the flaws should be resulting in timing problems… not the problems i mentioned above…
Maybe Renoise just isnt compatible with the Virus TI… I sure hope not cause Renoise is definitly my most favorite seqeuncer!
So… Anyone here who owns a Virus TI and uses it in Renoise? Or maybe someeone knows a sollution for my problems? Maybe this topic can be used for all TI in Renoise problems…
I do not own a Virus TI but its probably the same thing as when I use the xtc mode of my Plusar....simply dont use it or send your TI to the Renoise developmet team for the implementation of this special support.
Latency is always a problem, but especially on the usb port (that`s why I shook my head in disbelief as I heard they want to route everything via usb…Firewire would have been a better option).
Theres currently no automatic plug-in latency compensation for renoise as far as I know.
Yes, automatic plugin delay compensation would fix problems 1 & 2. It’s also the reason DSP cards like the Powercore and Pulsar don’t work. Too bad and it’s not even on the voting list of to be implemented features. More and more “normal” plugins need this too now so hopefully the devs will implement it in the future. It isn’t even hard to implement if you build an audio engine from scratch, however since Renoise’s engine is already built from code of several years this can be a bit more problematic.
About problem 3, if the Virus TI has ASIO drivers it should be no problem, so perhaps Access can be partly blamed for this. The usb choice was a very bad one yes, since it doesn’t support hi-speed usb2.
Since Renoise’s dev time consists of free-time programmers, you’d have to join the dev team or send them a Virus TI to get these problems sorted any time soon.
Anyway…renoise is low budegt software…49 Bucks is a very reasonable price for what you get out of it and therefore some advanced features which aren´t implemented in pro software which is 10th the price are very hard to expect, because it´s a hard job fo the developpers especially when they have to built their lives from other jobs as well. And don´t blame me - if someone can afford hardware for about 2 thousand bucks, he `s certainly not the rule of a renoise customer (imho).
maybe it’s a similar issue like with the emu power fx?
try this:
open the file “cachedVsts.xml” under “c:/documents and settings/(your profile)/application data/renoise/v1.5.1”
search for something related to “virus” or “TI”
IF you find something try changing the attribute “mNeedsStaticProcessingBuffer” from “FALSE” to “TRUE” or vice-versa
So we should rename Renoise from ‘pro’ to ‘lowbudget’ tracker now? This guy made money using this software, buys hardware and suddenly it stops there? Does not make any sense to me… But that’s my opinion
i’m sure it has alot to do on the vsti end of the Ti, but you cant deny there is still alot to be desired with renoise.
truthfully i dont see anything distorted of the least bit in what escii wrote.
its just, “how it is” at the moment. i still believe renoise to be the best tracker out there, but seriously thinking renoise is among the top daw’s is just lying to yourself. the only way i could see something like that happening is if all the top tracker devs got together…
Sorry if I did disturb your peacefullness…but I´ve to point out, the developpers side…without getting the hardware it`s really a tricky thing to develop something what should support this or better: acces music or creamware or edirol make an sdk on how to develop something for that piece of hardware. Without opening the source for it, development is hard to be done if the hardware developers do not fit the common standards.
Little disturbance felt only in the lowbudget part I do understand your point towards the developers but Renoise as a tracker is so damn close to being perfect and do not want to get shoved away as an old skool / semi professional thing… sometimes and probably because of the original post, I can feel the frustration… nothing personal escii…
I found out that the TI does’nt work properly in older SX versions than Cubase SX 3, so i’m affraid it wil not work in Renoise…
My plan is to try and figure out Cubase SX 3 and use Renoise for some minor jobs like composing beats. Its going to be hard but i dont see any other options…
i had not even thought of the proposal of sending devices to the devs to work with. but the first thing that comes to mind is who pays the shipping&ins?
I think when you want support for it you have to pay for the transport… Maybe some companies will send a demo but Renoise is not yet a big brand so they will charge for it even…
I know that energyXT now supports PDC (so yes, you can use Creamware XTC in there for instance).
I don’t know if this is just the standalone app or the plugins as well, though. If the plugins support PDC you may be able to get PDC in Renoise - haven’t tried it though…
Thanks for everyone’s posts so far - this has been a good discussion. I use the powercore so I’m interested in the plugin delay compensation aspect here…
Couldn’t it be said that PDC is an essential part of a VST implementation? I’m not familiar with the VST spec myself, but it makes sense that plugin instruments and fx are going to need some cycles (time) to complete their processing. It seems fair to say that a VST implementation without PDC is incomplete.
Yes I completely agree with you, but the devs do not share this vision. The VST spec says that every VST has a delay function which reports to the host how many samples the audio is delayed to compensate for calculations. Of course, a lot of VSTs have a big enough “buffer” with the standard ASIO buffer size but look-ahead algorithms take more and DSP cards and things like that need to pump the audio data to the DSP over the PCI bus and back first.
Implementing PDC isn’t that hard, every time you insert a VST you calculate the delay of the channel. Then you take the channel with the most delay and for each channel delay enough samples so that the physical delay is equal on all channels so that they are all in sync. When a VST is put on a sendtrack, you have to take into account the number of samples from sends from other sendtracks. Luckily Renoise can only send from sendtrack to sendtrack from left to right so this isn’t that hard.
