KVR :: Camel Audio » CamelSpace Causes 130% CPU spike! [beta update available] [View Original Topic]
There are 38 posts in this topic.
craftycurate - Sat Dec 10, 2011 2:22 pm
I am roadtesting the Camelspace 1.5 demo with a view to a possible purchase.
I was trying it in a Live 8.2.5 set yesterday, and CamelSpace had been running fine, but I couldn't remember if the demo timed out or not, so I deleted it from the master channel rack, and reinserted it immediately.
CPU had been running about 70% (20 tracks in this set), but as soon as I clicked OK in the "demo limitations" dialog, CPU jumped to 130%, audio ground along as it would, and it remained this way until I deleted the instance of Camel Space.
I'm running XP Pro Sp3, Core 2 Duo, 2 GB RAM.
Thanks
Richard
ZenPunkHippy - Sat Dec 10, 2011 2:36 pm
Hi,
Apologies for the problem, it's not something that we've noticed during beta testing. There *might* be a bug with similar symptoms but it's been very difficult track down as it only happened once to me in the last 6 months (I use CamelSpace almost every day), and could not reproduce it.
Are you able to reproduce the bug after restarting Live? I'm sure that re-creating the demo version in Live has never caused this problem here, but will check on XP today.
Also I would recommend updating the Live 8.2.7, as there have been a lot of bug fixes since 8.2.5.
Peace,
Andy.
craftycurate - Sat Dec 10, 2011 5:48 pm
Hi
It's something to do with the default patch 4BarFilter. On my setup,the extra CPU usage added by CamelSpace (CS) ranges from 5-40% with this patch, whereas with most other presets I just tried, it adds on only 3-7%.
UPDATE: Demo Patches which cause a wide variance in CPU usage are:
4BarFilter
Dubby
Easypad
Gate Two
The others all behave normally, only adding about 5% CPU.
It seems they all use the LP2 Fat Filter - I turned off the individual patch effects one at a time and it came down to that Filter each time.
UPDATE2: If I load up a problem patch, and change the filter type, the problem disappears, and it reappears if I revert to LP2 Fat.
UPDATE3: Applying LP2 Fat at very low cutoff freq avoids the problem, but once the cutoff rises above about 5% the CPU surge seems to happen.
If I change preset the high CPU disappears, so it looks like it's just something to do with presets that require high CPU usage. There is no instability introduced by the reported issue that is not instantly remedied by removing the VST or changing patch to one with lower CPU footprint.
Thanks
Richard
PS. I love the sound of this VST
PPS. maybe the new filter code patched in from Alchemy has brought in an instability?
ZenPunkHippy - Sat Dec 10, 2011 10:05 pm
Thanks for all the additional info. The LP-2 Fat filter is not one of the new filters. For that you need to select LP-2 SVF HQ or greater. Because this is happening with the default patch. we would expect to receive loads of email about it but we aren't. I've tested the same preset and the filter on Mac and Win XP using the demo in Live and cannot reproduce the problem.
Try this:
1. Open Live's preferences
2. Click the Files/Folders tab
3. Hold down Alt
4. Click the "Rescan" button
This will reset the Live VST list and might fix the problem. Let us know if it helps. If not, what else is running in the project? Are you using CamelSpace to process an audio file or a synth/sampler?
Peace,
Andy.
D.H. Miltz - Sat Dec 10, 2011 10:32 pm
Just in case it's helpful to know: loading the new CamelSpace overloads/freezes MU.LAB for me (WinXP SP3, Pentium 4, 1.25GB RAM) and a few other patches do the same thing. (This is just sitting there, not processing anything, and it is consistent.) Problem goes away when I change patches. Other than the default one I don't remember the exact patches I had trouble with, but if it'll help I can check tomorrow.
losan - Sun Dec 11, 2011 2:49 am
Hi Andy,
I can confirm the behavour craftycurate described,
in my case on Win Vista x64 SP2, with both versions x86 and x64
in Cubase 5.5.3 x86 and x64 accordingly.
Soundcard RME Fireface 400 - 256 samples set.
By just loading Camelspace (with the default patch) as an insert on a track (even without playing it back) the ASIO meter goes wild for around 15 seconds, then it calms down.
Playing back a track then with that preset the asio meter in Cubase goes wild again, stoping the track it takes some seconds to calm down again.
As craftycurate said, it seems to be related to the LP2 Fat Filter.
Cheers
ZenPunkHippy - Sun Dec 11, 2011 1:18 pm
Thanks for the feedback ... seems like there must be a problem. Maybe it's related to Intel CPU's (mine is AMD), although this is the first we've heard of it after months of testing. I'll check out MU.LAB too.
Peace,
Andy.
ezelkow1 - Sun Dec 11, 2011 1:52 pm
Im also seeing something similar, on i7-2600k win7x64 ableton 8.whatevers the latest
Just tested throwing a loop out there and then camelspace on top. I see the cpu meter jump from 0-20% and sometimes as high as 30, it does jump around alot but like others said, its when the cutoff is moving. So I dont see it spiking very high I do hear audio artifacts and crackling which make it seem like it is doing something it shouldn't be for a very short time, and maybe abletons cpu meter just isnt catching it
Also tried it with 8bar comb gate replacing the comb with lp2 fat and could see a spike up to 40% at times
mabian - Sun Dec 11, 2011 1:55 pm
Try putting an effect like DigitalFishPhones normalizer or GVST Normal before CamelSpace in the fx chain. If the problems vanish it's definitely a denormal issue.
- Mario
ZenPunkHippy - Sun Dec 11, 2011 3:47 pm
D.H. Miltz wrote:
Just in case it's helpful to know: loading the new CamelSpace overloads/freezes MU.LAB for me (WinXP SP3, Pentium 4, 1.25GB RAM) and a few other patches do the same thing. (This is just sitting there, not processing anything, and it is consistent.) Problem goes away when I change patches. Other than the default one I don't remember the exact patches I had trouble with, but if it'll help I can check tomorrow.
I can't reproduce this problem using MU.LAB free version. Default patch and others seem to be working fine, multiple instances also OK.
Not sure what to suggestion, perhaps try rescanning your VST folder. Of course it could be the same problem the other users are seeing, but I can't think what it would be other than CPU at this stage.
We did have one user write in about a blank GUI, which required an update to his graphics driver (I think the latest versions of our plugins all use GDI+ now) ... so thats something to try.
Peace,
Andy.
craftycurate - Sun Dec 11, 2011 5:58 pm
OK this is weird ... I first noticed this problem with Camelspace (CS) inside a standard Dry\Wet effects Rack I use all the time in Live 8.
When I have CS inside this DryWet rack with a problem preset like 4BarFilter, the problem appears. If I drag CS outsite the WetDry rack so it is the root level of the effects rack, the problem vanishes.
I've attached the Effects Rack preset it here as a preset so others can try it (http://db.tt/tZtnHHof).
UPDATE: New observations:
a. Now working with full version just purchased, and problems same as with demo.
b. When CS exists in the Wet chain of the attached DryWet rack, with DryWet knob set to 0 (i.e. 100% dry) the CPU surges and remains at a consistent 140-144% in my set). If I turn the knob to any other value the problem is much less pronounced, peaking at perhaps 110% but only momentarily, normally only peaking to about 90%.
In other words, when CS is in an effect chain, but receiving no signal, it seems to make the problem a lot worse.
If CS is outside an effect chain, in the root level of the effects area, the CPU figures are in the same range as when CS is inside the DryWet Rack with DryWet at a non-zero value as described above.
Thanks
Richard[/img]
papatomany - Sun Dec 11, 2011 9:10 pm
This happens to me in Sonar X1. (Dual Core AMD, Windows xp) It maxes out my audio engine with a pop sound any time I insert it. I can occasionally change presets, then get the audio engine to reset, and the new preset will play; but switching back to the 4barfilter preset causes the spike again.
carrieres - Wed Dec 14, 2011 1:52 pm
same thing in orion running intel cpu
lp2 fat is buggy
Itron - Wed Dec 14, 2011 3:17 pm
Just to add +1 to this behaviour. This is using XP Pro SP3 and Studio One 2 with a Cakewalk UA-25 EX sound card. Again using the CS default patch and IL Harmor. I also notice in the Performance monitor that the CPU will hit 100% after you have stopped playing a note. (So you can't hear anything, but the CPU monitor jumps about like crazy for a good 15 seconds after the last midi input.) If you change the MM Filter to something else, the cpu useage drops to a few %. Sometimes when you change it back to BP2 Fat the CPU useage will actually stay down, but more often start averaging at 40+% with spikes and crackles to 100%. When it stays down it will be less than 10%. This is on an Intel Quad2core, with 4GB RAM using the 3GB switch in XP. Hope this helps, otherwise love my recent purchase of Space and Phat!!
Edit: Just tried the same setup in FL Studio 10, and receive the same high CPU useage after the midi input has stopped for a good 15-20 seconds (no sound). CPU useage during use is still high but doesn't have the 100% peaks, probably around 80% peaks. Again change filter and the cpu useage drops (even if you switch mm filter after last midi input, when no sound is being output.) Cubase 6.02 has a lot of activity between 5-50%, but not the 100% peaks. However, activity again persists after you have stopped playing for a good few seconds or until you change the MM filter. Reaper 4 shows less than 4% whilst playing, but jumps up to 15% when you stop playing/midi input!! If you start playing CPU useage drops to less than 4% (It never actually hit 4% it was normally around 1.2-2.5%!!) Hope this helps!!
ZenPunkHippy - Wed Dec 14, 2011 3:26 pm
I can reproduce a minor CPU blip under similar circumstances - definitely not "right", but no where near the 100% CPU you are reporting.
Anyway, it's definitely something we need to fix with so many of you reporting it. I'll pass the info on to our developers to look at ASAP. Thanks.
Peace,
Andy.
mabian - Thu Dec 15, 2011 12:15 am
mabian wrote:
Try putting an effect like DigitalFishPhones normalizer or GVST Normal before CamelSpace in the fx chain. If the problems vanish it's definitely a denormal issue.
- Mario
Just trying to help... has anybody experimenting the problem tried this trick?
- Mario
carrieres - Thu Dec 15, 2011 1:05 am
the problem is not about 100% but about the cpu using more cpu rythmicaly when you use the filter LP2 fat
as a workaround, which filter is the closest ?
Itron - Thu Dec 15, 2011 1:22 am
Tried the nromaliser (from digitalfishphones) , but no effect, that I could discern. Still getting crackles, with that filter. Hope that helps!
e@rs - Fri Dec 16, 2011 7:01 am
I also have CPU spikes with CamelSpace 1.50.0.570 and in a lesser extent with CamelPhat 3.50.0.591.
After half a day of messing with them (in Studio One and Live) here are the facts, step by step:
A) CamelSpace LP2 Fat in S1
1. load Impact with 4 outputs (CPU 5% playing);
2. insert CamelSpace on an Fx Channel; choose an empty patch (CPU 7% playing);
3. activate MMFilter with LP2 Fat type with everything in default position (CPU 7% playing);
4. hit Stop (CPU jumps and stays at 37%; in S1 Performance Monitor with Show Devices activated it's clear that CamelSpace is the reason).
B) CamelSpace LP2 Fat and TranceGate in S1
1. load Impact with 4 outputs (CPU 5% playing);
2. insert CamelSpace on an Fx Channel; choose an empty patch (CPU 7% playing);
3. activate MMFilter with LP2 Fat type with everything in default position (CPU 7% playing);
4. activate TranceGate - with no steps in the Step Editor (CPU 38% playing);
- with some steps (CPU oscilates very fast: when it reaches a step is under 10%, when not, back to 38%);
5. hit Stop (CPU stays at 38%).
C) CamelSpace CombP or CombM in S1
1. load Impact with 4 outputs (CPU 5% playing);
2. insert CamelSpace on an Fx Channel; choose an empty patch (CPU 7% playing);
3. activate MMFilter with either Comb type (CPU 7% playing);
4. hit Stop (CPU 3%);
5. hit Play again; Cutoff and Mix stay in the default position; tweak a bit the Resonance (CPU 8% playing);
6. hit Stop - Resonance in the left part (CPU 3%);
- Resonance in the right part (CPU jumps and stays at 15%).
D) CamelSpace CombP or CombM and TranceGate in S1
1. load Impact with 4 outputs (CPU 5% playing);
2. insert CamelSpace on an Fx Channel; choose an empty patch (CPU 7% playing);
3. activate MMFilter with either Comb type (CPU 7% playing);
4. hit Stop (CPU 3%);
5. hit Play again; Cutoff and Mix stay in the default position; tweak a bit the Resonance (CPU 8% playing);
6. activate TranceGate - with no steps in the Step Editor (CPU 5% playing);
- with some steps (CPU oscilates very fast between 3% and 20%);
7. hit Stop - Resonance in the left part (CPU 3%);
- Resonance in the right part (CPU stays at 15%).
E) CamelPhat LP2 Fat or CombP or CombM in S1
Same situations as for CamelSpace but with lower values spikes and the fact that CPU doesn't stay at those peaks when it reaches them.
Here spikes appear only when I hit Stop and for a very short time.
PC: Intel Core2Duo E6750 @ 2.66Ghz, 2Gb DDR-800 Corsair, RME Fireface UC buffer 128 Samples, 24Bit 48Khz.
OS: WinXP SP3 x32.
DAWs: PreSonus Studio One Professional 2.0.3.17299 and Ableton Live 8.2.5.
VSTIs: S1's built-in Impact, replaced by Korg M1 Legacy and after that a 606 Kit Drum Rack in Live.
I've tried the above steps multiple times with the same results in both DAWs.
Note: when I say 5% or 37% CPU use, it's the maximum value it reaches at that step (VSTi + CamelSpace); usually it oscilates with -2% from the value I posted.
D.H. Miltz - Sat Dec 24, 2011 9:55 pm
mabian wrote:
mabian wrote:
Try putting an effect like DigitalFishPhones normalizer or GVST Normal before CamelSpace in the fx chain. If the problems vanish it's definitely a denormal issue.
- Mario
Just trying to help... has anybody experimenting the problem tried this trick?
- Mario
I meant to come answer this sooner. I did try it, and it made some difference. I can load CamelSpace after GNormal and have it not immediately overload; it looks like it wants to, and the CPU is quite high still on that default setting (I
think that adjusting the settings on GNormal affects this, but I haven't been systematic about testing it), but I don't have to turn it off, change the preset, and restart it before using it now. Using GNormal also seems to completely fix a problem I had with at least one other plug, so thank you for the suggestion.
ZenPunkHippy - Sun Dec 25, 2011 5:39 pm
e@rs wrote:
I also have CPU spikes with CamelSpace 1.50.0.570 and in a lesser extent with CamelPhat 3.50.0.591.
After half a day of messing with them (in Studio One and Live) here are the facts, step by step:
Thanks for the detailed post, this will be incredibly useful during testing
We will have a new beta build available soon that addresses the problem (yes, denormals ... !) once I've had a chance to test the build and make it available to download.
Peace,
Andy.
e@rs - Tue Dec 27, 2011 4:33 am
Great news. Keep up the good work.
Happy New Year!
Phase47 - Tue Dec 27, 2011 8:42 am
I have CPU spikes and higher than normal CPU usage with the new version of CS, and have had since the last beta version. I reported it during the beta, and hoped it would be ironed out for release, but it is still present. (And a bummer.)
ZenPunkHippy - Tue Dec 27, 2011 8:20 pm
Phase47 wrote:
I have CPU spikes and higher than normal CPU usage with the new version of CS, and have had since the last beta version. I reported it during the beta, and hoped it would be ironed out for release, but it is still present. (And a bummer.)
Apologies - that's my fault for having an AMD CPU. The bug doesn't happen the same way, just a very small spike that's hardly noticeable. I'll have a new Intel based PC soon, so this doesn't happen again.
Peace,
Andy.
KungKrille - Sat Dec 31, 2011 6:05 am
I solved a problem with a song I'm currently working on thanks to this post. I could hardly play a certain part of the song in Ableton Live. I got a CPU spike but after a couple of bars it settled down (though still quite heavy). I went through all tracks and turned off plugins to narrow down the one that was causing the problem. I must have missed CamelSpace somehow but after reading this post I went directly to the track that's using it, turned it off and voila - it's playable again. I'm using the LP2 Fat filter btw
ZenPunkHippy - Thu Jan 12, 2012 2:49 am
Hi,
Public beta versions of CamelPhat and CamelSpace are now available to download from your
support account.
These updates fix the denormals problem that could overload the CPU when using the default preset or certainly filter types. The new builds are labelled:
CamelPhat
- CamelPhat Plugin v3.50.1.630 - PUBLIC BETA (Mac)
- CamelPhat Plugin v3.50.1.628 - PUBLIC BETA (Win 32-bit)
- CamelPhat Plugin v3.50.1.629 - PUBLIC BETA (Win 64-bit)
CamelSpace
- CamelSpace Plugin v1.50.1.609 - PUBLIC BETA (Mac)
- CamelSpace Plugin v1.50.1.607 - PUBLIC BETA (Win 32-bit)
- CamelSpace Plugin v1.50.1.608 - PUBLIC BETA (Win 64-bit)
I've tested these builds on Mac (Intel) and Windows (AMD). The minor CPU fluctuations in Live seem to be fixed, but since I was not able to reproduce the problem consistently it's difficult to say for sure. If you have time to try these new builds, please let us know how you get on, thanks.
Peace,
Andy.
ezelkow1 - Thu Jan 12, 2012 8:55 am
A quick test and its looking good, back down to almost no cpu use on the 4bar preset. Ill try to remember to give it a more thorough run-through later today
papatomany - Thu Jan 12, 2012 9:34 pm
Quick test: seems to have fixed my problem. I'll keep testing tomorrow.
Itron - Fri Jan 13, 2012 10:23 am
Hi Andy,
Done a quick test of CS, in Studio One 2 and Cubase V6.0x, on Win XP SP3, Cakewalk UA-25EX, Intel Quad2core, with 4 GB RAM, and although the CPU useage meters seem to be OK now, I am still getting odd very fine clicks on the default patch. Not getting this when I change filter to LP2BQ. It is more like the faint clicks you used to get on a very slightly dirty vinyl, not a loud click but several faint clicks in the background - if that makes sense!! (and you are old enough like me to remember LP's!!)
Just noticed that if you drop the cutoff to under 2000Hz, the "crackles" stop! Probably makes sense to the experts!!
Hope that helps, and please feel free to email me if you need more specific information.
BW and many thanks,
Mark.
ZenPunkHippy - Sat Jan 14, 2012 4:44 am
Hi,
Thanks for the feedback everyone, sounds like we're almost there.
Itron wrote:
I am still getting odd very fine clicks on the default patch. Not getting this when I change filter to LP2BQ. It is more like the faint clicks you used to get on a very slightly dirty vinyl, not a loud click but several faint clicks in the background - if that makes sense
I'm not sure if it's possible to reproduce this. There is some stepping when using the mouse to adjust the filter cutoff, but this doesn't happen with modulation / MIDI control / automation.
Does it occur if the resonance is set to 0? It could be internal clipping of the LP2-Fat filter. If you could record the output and send it as an attachment to support I can compare it to the output here.
Quote:
(and you are old enough like me to remember LP's!!)
Yes!
Peace,
Andy.
Itron - Sat Jan 14, 2012 5:11 am
I will certainly have a go!
craftycurate - Sat Jan 14, 2012 6:26 am
Also getting clicks on the default patch with new BETA, though not the CPU surges like before.
e@rs - Thu Feb 02, 2012 7:02 am
Using CamelSpace build 607 beta. The LP2 Fat seems fine now, but the spikes in CombM and CombP modes are still there [as described in my earlier post at points C) and D)].
e@rs - Sat Sep 29, 2012 7:11 am
CombM and CombP fixes?
ZenPunkHippy - Sat Sep 29, 2012 7:28 am
e@rs wrote:
CombM and CombP fixes?
Hi,
Sorry for the delay, we've been busy with Alchemy and I was having a hard time reproducing your bug.
It might be a good idea if you created a simple project that reproduces the problem and send it to alchemy-beta [at] camelaudio [dot] com. We will need to update Phat and Space with singed installers for OS 10.8 soon, so it's a good time to test this.
Peace,
Andy.
e@rs - Sun Sep 30, 2012 3:46 am
Sent. You'll need the trial for Studio One 2 to open the project. Step by step guide inside the project.
Thanx.
ZenPunkHippy - Sun Sep 30, 2012 10:08 pm
Thanks e@rs - that might be the best bug report we've ever received. Nice work!
I can reproduce this now but it's only happening on Intel based Win PCs. It does not happen on Mac and is not happening with AMD. This would explain why I could not reproduce the problem before: my old PC was AMD based, but since it stopped working (was very old) I've upgraded and have both Intel + AMD systems for testing.
Anyway, thanks again. I'll log a case to be fixed soon.
Peace,
Andy.
e@rs - Sun Sep 30, 2012 11:03 pm
Great news. I'm happy you liked my bug report project.
Keep up the good work.
There are 38 posts in this topic.