the gui and sound will stop for a fraction of a second and then resume.
changing type rapidly makes it obvious. Renoise will stutter.
Doesn’t seem right that a built in DSP does this.
Using 2.7.2 on Mac OS X 10.7.2. Haven’t tried it on Windows yet.
I just attached an LFO to the cabinet type and modulated it as fast as possible. Even jacked up the BPM and LPB until my CPU couldn’t handle it anymore. But the Cabinet Simulator did not cause any crashes.
Could you please provide a small example song which clearly demonstrates the lock up?
Could you also gives a few more details about the lock up itself. Do you mean that it crashes Renoise? Does it completely kill the audio? Or do you simply get the CPU overload message appearing? Or something else?
Which operating system (and which exact version of the OS) are you experiencing the problem on? (Windows, OS X, both?)
Which version of Renoise are you using?
I can’t reproduce that.
Windows or OSX?
And laptop or desktop? Are there perhaps other effects in the chain that somehow influence stuff?
I have to admit I was happily surprised when I saw Cabinet Type was in the list of automatable parameters, as both this and Routing (which is also automatable) are the kind of thing where I wouldn’t be surprised to get a brief glitch when being changed, as they do quite severely affect the way the audio is being processed within the plugin when changed.
Saying that I have a few times had a LFO on Random changing Type (at a slot rate admittedly) and have never ran into any troubles. My audio source has usually been kicks or snares though, not a constant sound, so maybe a different source would show it more easily (depending on what the exact fault is.)
Is that all or is it a complete lock-up, as the thread title seems to imply?
sorry i didn’t explain it right. i’ll edit the title and post.
it doesn’t make renoise stop working and require a force quit or something. it just pauses for a fraction of a second.
I don’t get a cpu lockup message because i can’t click that fast.
If i make an LFO control it with the standard rate set it takes about 4 seconds before that cpu gauge races up to 90% and i get the cpu warning.
with the lfo off the song plays at 7% cpu.
with lfo set at 60000000 LPC it is making Renoise do the pause thing and uses around 25% cpu. not enough for the warning.
in all those cases the sound and gui is playing up just like when it’s clicked except faster depending on lfo rate.
I found it interesting that it does the behaviour even though the cabinet type isn’t actually changing because the LFO is so slow. Makes sense programming wise i suppose because it’s still being told change to this type every time the lfo ‘ticks’.
Changing cabinet type, which changes the mathematical function the audio is being treated by, or changing routing, which changes the order of the functions, are both things I would kinda expect to cause this… If Renoise can get these types of changes 100% glitch free it would be awesome though! Would prefer access remains and know we have to be careful than it’s removed to stop people from being able to cause audible glitches.
Do you get similar if changing Type of the Filter? Notice they block off Model from being automation for this reason (which is a much bigger difference than Type) so maybe it does cope with that one…
“Bug” replication confirmed. Well it’s not a bug exactly, it’s a crazy usage of the cabinet simulator.
After that it don’t see why anybody could switch the cabinet simulator mode that fast…
No stuttering here, just a really awful sound from abusing the device. CPU usage hovers quite comfortably below 10%.
I work with a 48.000Hz output sound definition.
When I put the audio output to 44.000Hz : no stutter.
And you’re right the sound is Awfull.
But if I raise it to 48.000Hz on my i5 core desktop + USB audio device it starts to “stutter”.
Frankly I don’t know why there’s such a big CPU flood difference between 44.000Hz and 48.000Hz.
Same to some extent.
44.1kHz always plays no problem. About 8% on opening, about 12% on playback.
48kHz and 82.1kHz also tested. Both always stutter and reach 100% CPU usage. Depending on which driver I am using it may be OK before hitting play or it may go intto CPU Overload warning messages on just loading the song and not doing anything.
If a song is bringing up the CPU warning message while not playing it becomes quite hard to close down Renoise 
Actually both ASIO and DirectSound bring it to 100% usage without even playing. Strangely it is DirectSound that takes longer to do so, with Echo’s own ASIO driver it does it almost instantly.
Ah! Well spotted. I just tested at 48kHz and it did indeed stutter like hell. Very strange! We’ll have to look into this.
Edit: Ok. Taktik just informed me it’s because the impulse responses used by the cabinet simulator were originally created at 44.1kHz. When using sample rates other than 44.1kHz the impulse responses must be resampled on the fly, which is a bit intensive, so this is where the extra overhead is coming from.
We’ll obviously see if we can improve this in the future, but is this really a deal breaker for now? Are there “normal” situations where this brief stutter is a big problem, or is it only during these pretty extreme test cases?
I’m using 48000 so that explains it.
I doubt it will be an issue realistically but I saw it as strange enough to worth mentioning and not ignoring.
I can confirm that using sample rates other than 44100hz will cause the cabinet to perform a on the fly resample of the impulse responses we use, which are sampled at 44100. this will cause a bit of overhead in the player when switching this so fast: Initially i leaved the cabinet type as parameter so one could swap it by using commands or automation, but obviously when this is abused the cpu will go on its knees.
One way to fix it would be to precalculate the IR for each sample rate, and this could lead to a big increase in the memory consumption… Avoiding the IR resample will means every sample rate will sound different!