Hello!
First of all, renoise 1.2 looks great. But… Yesterday I’ve measured the performance of playing one of my XM’s and compared it to some other trackers’ performance. Here is the result: in renoise playing takes about 60-70% (!!!) of cpu time, in skale - 30-40%, in modplug tracker - 5-10%. I used Primary sound driver, sampling rate 44100Hz, 16 bit, 100ms latency in all trackers. Tested on PII-233Mhz (oh, yes, I know this is sux).
Am I doing something wrong with renoise? Or just new generation of coders (hi, taktik! 
) forgot about code optimizations?
lo’
You have a very old machine now. Coders can’t write software thinking it won’t work on a 486 DX2.
You may use older software with your CFG, I’m sorry but it’s sad but true…
PS : Look at the features; I think you can understand why renoise need more than a PII 233.
no, because renoise needs to “translate” the song while playing it … it’s simply not an xm-player but a program which can “import” xms. If you want to play XMs use something else.
renoise doesn’t “translate” anything while playing, it import xm data to own’s on load. the problem performance is in the feature bypassing i guess. if you know programming a bit, you should know commands like “if” or “cmp” in asm, all these thing takes cpu’s time. renoise have to check all the time if there one more note column, if there one more command column, if there one more dsp effect and etc. of course i still think renoise could be much more faster after deep code optimization with asm, but it’s pretty dangerous and takes a lot of time. a couple of years i was doing some graphic editor for my Speccy, and i’ve created many new algorithms for linear rescaling, filling and other. for example speed of fill was about 50000 pixels per second, and it was on 3.5Mhz cpu, it means one pixels took only 70 tacts, but to get that result i had to remove a lot of loops and stuff, and all fill routine is sometime like few thousands of lines pure asm.
As a programmer myself I can say that in most cases the better code is organized the faster it works (hey, Zed, speccy’s code optimization rules such as put many LDI’s instead of one LDIR etc. does not work on PC). And such incredible overhead in renoise’s player speaks a lot about its developers’ programming style. I understand where the bugs came from and why they are removing for so long period of time. I don’t want to insult developers, I want to say that it can be done much better.
But, on the other hand, for most users it doesn’t matter. They are the ones who buy renoise 
Zed that’s what I mean by Renoise not being optimized for the XM format. RNS is probably a whole different format and not a superset of XM, with a lot more features and flexibility. Because of the translation (Your XM is an RNS as soon as it’s loaded) there is no way Renoise can take advantage of XM-specific characteristics to speed up things.
However, OP was comparing it to other trackers that play XM’s significantly faster. Maybe their internal format is closer to XM (I am sure Sk@le’s is, as it is more or less FT3), or they go into an ‘XM mode’.
Looza I don’t think OP was attacking Renoise for being slow, but playing a cross-tracker format tune like an XM could well be used as a benchmark, all things considering. I don’t believe Renoise translates the XM on-the-fly as it is playing, I give Renoise’s coders much more credit than that
well, it’s not just about LDI instead LDIR… pc’s code is still a code that can be optimized. the main principle of Speccy’s optimization is faster algorithm. even without much of simple code optimization my algorithm still most fastest, that’s the point. i’ve seen many new russian demos on Speccy, and i can’t understand how that works on 3.5Mhz machine, sometimes i see demos where all the screen is animated with 50 fps. btw, most fastest data moving in z80’s code is PUSH/POP via stack. that gives 11/10 tacts to move 2 bytes at once. usually, all optimization is based on new algorithm, table value calculating, loop removing, also using self-modification code (doesn’t work on pc because of cpu’s cashe). but anyway i don’t want to insult anyone if he doesn’t use asm. i still think c++ is communist exorcism, and asm could be much more easy if big soft developers pay more attention to it. but now, asm coders is somekind of underground… anyway pc’s asm sucks… and with ugly mnemonics…
come on, no one would do a tracker with ASM.
and benchmarking music programs is a total bull idea if you ask me, I want to know what its capable of, not how fast it can play an XM. You benchmark PCs and not software (except for sort-algorithms or something like that).
Also, Renoise does not have a “set” amount of features, and at the point you want to keep your program open for changes and additions you loose some perfomance, so what. You can only fully optimize code which will never change again, if you want to avoid the problem of rewriting everything when something changes.
If you want to play an XM, you have a defined set of rules, there will never come anything new to consider. In a editing software like renoise there might always something come up which needs to be changed and therefor you have to keep all options open.
You see that with the tick/speed/dsp-latency problem : its okay if you write a player for XMs which only thinks in ticks, which is very coarse. Right now with renoise there are wishes popping up which require a change of the way renoise handles “time” …
actually I have to say I am only a “theoretical coder”, I stopped coding years ago after I switched from C64 to PC, with C64 ASM being the last language I coded in, but still I care for coding problems and often help friends I know with problems they have when coding in a theoretical way.
maybe lets open a coding thread where taktik tells how he does his stuff and people with enough knowledge give tips. Only if he wants though 
I just don’t believe that keeping your program open for changes decrease its performance so much 
Renoise plays 6-7 times slower. Looks like it coded in visual basic.
yeah. we coded it using perl and visual basic and added some c++ lines with malloc to make it look big.
ok. seriously now.
we know there are big issues with the gui-performance. furthermore the audioengine eats a lot of cpu-cycles. just keep in mind how many channels we have to handle (note polyphony, track-note-rows, 64 track max)
there have been made a lot of optimizations, but we arent still finished with that issue, but dont expect any miracles. renoise is programmed in c++ and uses a lot of classes / interfaces. if we would have programmed it using pure c, the performance would be much better, but we would be put into a lunatic asylum due unreadable code and bugs we could not explain
anyway. features and stability first, then lets see what we can do about improving performance… Todays computers are fast enough to be that arrogant, so we cant take comments like “it wont run on my 486dx” seriously. renoise has been designed to be a productive and featurerich tracker for newer machines (like pii500 and higher).
Firstly, it depends were you compare modplugs, ft2 and Renoises performance. Renoise uses many floatingpoint operations and will therefore be much slower on older pc’s compared to ft2 or modplug. Newer computers are even faster in floatingpoint operations than in integer operations, so you could say its optimized for new pc’s
Second, I will never optimize against quality. Of course you can use no interpolation and calc always in 22050 kHz but this will sound ugly, and will never do this just to be 2% faster.
Further, the samplemixer’s performance itself is no longer that important as it was some years ago. What do you gain if your sampleengine plays 10 tracks of samples with 2% and you play a sinlge note on your FM7 and you have again 20% of cpu gain
Optimizing makes code ugly and unflexible as mentioned above, so my golden rule is : only optimize the important and critical tasks. You gain much more when the gui doesnt use 100% of your cpu but only 5 percent. so my main concern was till now to have a top quality but not slow mixer and a fast, highly optimized gui.
taktik & pulsar:
Your completely right… I’m on your side There’s no point optimizing everything. The right way is to measure what parts are critical/takes the most time and see what you can do about it. Putting much time and effort (and introcuding new bugs) into optimizing if-statements which will reduce CPU by 0.01% has no meaning. Besides, this is not what users want to pay for.
Still it’s a major issue that Renoise takes double the CPU as Skale, which is a new tracker. But I’m not that familiar with Skale… maybe they can’t be compared at all?
well, renoise 1.1’s sampleplayer was faster than skales but used much memory. So I disabled the optimization for in the 1.2 release.
I guess that explains where my crackling noises came from
[http://www.dachiphop.com/~renoise/index.ph...3fc613e659d84e3](http:// this-link-is-no-more-valid?act=ST&f=7&t=1173)
Loolarge
my 2 cents:
i prefer to see good effects for music production and stable program on P4 / 3GHz than super fast program with no effects and no possibilities that runs great on P233.
My CPU is quite obsolete (costs so little that it is not worth mentioning) Duron 800 where Renoise runs great. I think you can’t even buy this CPU today.
Okay, okay…
When I’ll buy better computer, I register renoise. I like its look-and-feel (but not speed ). Now I continue using cakewalk sonar + modplug. For me, music programs are just instruments. Anyway I compose my tunes playing directly on piano, violin and guitar. So… it doesn’t that matter which software I use to get the desired sound. With renoise it will be just faster.
I hope you won’t stop to improve renoise.
Thanks.
try doing the vice versa:
let Fast Tracker play a .rns file and we will see 
I have a overclocked AMD-K6 800@950 and I did not run into any problems yet … highest CPU usage was 60% and there were really alot of effects … I am very satisfied. (Cubase 5 for example can play 4 stereotracks on my PC, then it starts to drop … so what.)
lets renoise play *.xm on 486 66Mhz and we’ll see