Hi Fritz
I’ve been emailing Jon at ConcreteFX about a synth plugin he’s got called Kubik. When run in Podium. some presets make the CPU use rise to 100% while the user interface of Kubik is open. This problem does not occur in energyXT, it seems to only occur in Podium (my main and favourite host 😉 ).
You can get a demo of Kubik here for testing
http://www.concretefx.com/KubikDemo.zip
These notes I’ve written are copied from an email to Jon – they were meant to help him create the problem so many of these steps will be well and truly obvious to you 😉 Feel free to jump to step 5 after you’ve imported the Kubik demo .dll
Steps to recreate the problem
1) Create a new project in Podium. Using the project wizard on the right, set up your outputs and inputs etc. Under the section “Plugin mappings” click on the “Import plugin” button and navigate to kubik.dll and load it. This works fine
2) Create a new arrangement, by clicking the button at the bottom of the project wizard. Now double-click on the “New Arrangment” bit in the top left to open the arrangement
3) Click the “New track” button on the left and click OK. Now right click on the new track (now shown highlighted in colour) and choose “Wrap in new group track”. Now click on “New group track” so that it is selected in blue. Now click on the “Map” tab and then click on “Master stereo” (or whatever represents your sound card output).
4) Clicking back on the first “New track” you created (not the group one) click on “Map”. Drag “Kubik insert” onto “New track”. This inserts Kubik on the track. Now on “new track” click on the faded letter “E” to open the Kubik window.
5) Load the Blaster78_Kubik1 bank and click through the presets. When I load the 4th one (LED PWMing) the CPU meter shoots to 100% and stays there, and sound stops. When I try clicking other presets, and even loading other banks, the CPU stays at 100%.
6) Now… CLOSE the Kubik window, and watch what happens. The CPU meter shoots back down to a reasonable level, and sound is heard again. So this issue only occurs apparently while the Kubik plugin window is open in the host.
7) Open the Kubik window again. The sound still plays back fine. Then, when I start editing partials eventually the CPU shoots back up to 100% and the sound stops again… and starts again when I close the Kubik window
Thanks Fritz, good luck!
Chris
I’m also trying to use Kubik in Podium. I get brief 100% cpu spikes when changing presets but is OK otherwise. The odd thing I’ve found is that I can’t get midi to trigger the Kubik built in sequencer. All the patches that utilise the Kubik sequencer just remain static, so to speak. Works fine in Energy XT. 😕
Mart
I have not yet been able to recreate the 100% CPU lock, but I have fixed the problem with the internal sequencer not responding. This fix will be in 1.20, to be released later this weekend.
For those with technical insight into VST programming, here’s my notes concerning this fix:
The VST 2.3 documentation is vague in explaining the ‘position’ parameter in the tempoAt() plugin to host call. So far Podium has interpreted this parameter as an absolute sample position in the song. I have now changed it so that it interprets the position as an offset to the sample position of the currently processed block. Hopefully this doesn’t break the tempo sync in other plugins. Most plugins I have tested does not use tempoAt() but rather calls getTimeInfo() which provides more detailed sync info. The getTimeInfo() call is not affected by this fix. When Kubik calls tempoAt() it always sets position to zero, which caused Podium to think it requested a tempo at a position before the song started, leading to a wrong tempo sent to the plugin.
Podium 1.20 is now released, with various VST related bug fixes. I did not manage to recreate the 100% CPU lock you described, but maybe some of the 1.20 fixes have cured the problem. I noticed also that Kubik 1.1b was released with a fix for a ‘denormalization spike’ etc. Maybe Podium 1.20 and Kubik 1.1b can live in perfect harmony? Let me know if you still have problems.
Hi Fritz
Worked out the bug was caused by user error on my behalf – I was double-clicking a dragging where only single clicks were required. The developer of Kubik is going to look at making it more foolproof. It was weird that it only happens in Podium though and not energyXT – maybe Podium has a higher rate of “mouse tracking” so it was therefore trying to process more commands (eg. when click and dragging it must detect more points of the drag than energyXT does, which therefore means more functions are called in the same time – does that make sense?)
Chris
I will also try 1.20 with Kubik to see what happens and will report back
eg. when click and dragging it must detect more points of the drag than energyXT does, which therefore means more functions are called in the same time – does that make sense?
Podium used to inform all plugins with idle notifications whenever the user input was idle. Moving the mouse around would mean this would occur often. In 1.20 I have changed this to be timer controlled, to reduce the rate at which idle notifications are sent. This may fix your problem with Kubik.