ZynewaveNo. As I remember it, the problem is that the value is not sent realtime if you edit the dial on the track. If you however open the event properties dialog, and change the value here, it will send it realtime. Does it not work this way?
Zynewaveooi, what’s the count on registered users?
25-30. Still a long way to go before Steinberg will feel threatened 😉
ZynewaveTo use the drum editor it is required that there is a drum-kit preset assigned to the track. There is an example of this in the freebees demo project. A drum-kit preset is supposed to contain a batch of single key drum presets which then will be shown as lines in the drum editor. If you have created e.g. a library preset for a drum plugin, you can enter the properties dialog for this preset and check the ‘drum kit’ option. Podium will then ask if it should automatically create a set of default GM compatible drum key presets. You can modify these preset objects afterwards.
ZynewaveHi, thanks for the praise 🙂
when will fade in/out be available for individual audio clips in the arrange page?
Sometime early next year. The next big things on my list are plugin editor controlled automation, generic editor for UIless plugins, count-in options for recording and auto-save options. Maybe I can soon find time to implement the fade in/out destructive edit functions in the sound editor, so you don’t have to go to an external editor.
Just imagine being able to use Podiums bounce track feature in non-realtime “bounce now”!
Next year.
ZynewaveSince updating of guis actually has quite an impact on cpu load, could there be some kind of advanced config to set these things up?
I don’t think that will be necessary. The increased plugin UI update rate will consume more CPU time, but it is taken out of the CPU time remaining after the audio processing. The audio thread is running at high priority so it will always be first in queue for CPU time. If anything suffers from the higher plugin update rate, it is the Podium UI, but I doubt it will be a problem.
If the audio processing is taking a massive amount of the CPU, the idle processing calls will occur less frequently. Note that the Podium CPU will indicate 100% or overload at something like 95% of the ‘real’ available CPU time and then start gradually to skip plugin processing etc. to drop down below overload indication. If Podium were to allow the audio thread to use close to 100% of the real CPU time, there is a risk that the PC will freeze completely because the UI thread will never get a sufficient slice of the CPU time. This is what you could experience with at least older versions of Cubase.
ZynewaveHi Jean-Marc,
I have just tested version 1.19 against 1.20. I used the Surround.pod demo project which is using two of your plugins, and added a couple of parameter automation tracks for the two plugins. What I found was that when automating VST parameters, SynthEdit plugs are very sensitive to the rate at which they receive idle notifications from the host.
The problem with 1.19 and older versions was that Podium notified plugins with idle messages at the same rate that the Podium UI entered idle state. That meant that if the CPU load was low or playback was stopped, the idle messages would be very frequent. But once playback was started and the CPU load was high, then Podium never entered idle state because the remaining CPU time was used to update the animated playback graphics. In this case plugins never received idle messages, which for many plugins (including your plugins) meant that they did not update their UI. I even managed to crash the SpatPod plugin by doing some parameter automation during high CPU load. If I were to make a wild guess on what is causing this crash, then it appears that SynthEdit buffers up parameter automation events and does some processing for these in the idle calls. If an idle call is not received at a regular rate, then a buffer overrun probably occurs inside the SynthEdit code.
In 1.20 the idle messages to the plugins are controlled by a timer. Thus the plugins should receive a more steady rate of idle messages independent of the CPU load. I have set the timer to fire with 200 ms intervals (5 times per second), which I agree is too slow to make parameter automation appear smoothly in the plugin editors. I have now reduced this to 50 ms (20 times per second) which gives a more steady CPU reading and smoother graphics.
Fix will be available in 1.21. Thanks for pointing out this problem.
ZynewaveAs things has turned out, I won’t be able to have it ready for your demonstration. With my current routine of releasing a new version every 14 days, this would mean the next release is due December 5th. It may happen that the next release will deal with a couple of other issues that are related to the automation recording, and the automation will then be postponed to the next release mid December.
Zynewaveeg. 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.
ZynewavePodium 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.
ZynewaveZynewaveGood news Gabriel,
Today I downloaded the EST plugin demo and indeed there was an oversight in Podium that causes this plugin to ignore sync.
The problem was simply that Podium never set the (nerd-talk: kVstTransportChanged) flag. Not all sequencer-based plugins requires this flag to be able to sync. The Sonicbytes plugins apparently do. From what I read on the Steinberg VST mailing list archive, Fruityloops also requires this flag. With a bit of luck this fix will cure your problem with Fruityloops as well. And if I may dare to be completely optimistic, this will also fix the reported sync problem with the Sonicbytes Gat’r plugin.
The fix will be in 1.20. Please let me know if the sync problems remains after this release.
ZynewaveI 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.
ZynewaveZynewaveZynewaveThat doesn’t sound good Joachim. To start with; if you suspect you have a bad memory block, then I can recommend the free Memory Diagnostics utility from Microsoft:
http://oca.microsoft.com/en/windiag.asp
A few months ago it helped me identify a bad memory block in my old internet PC that was causing Windows to sporadically blue screen.
Is there a parameter or setting I can invoke to tell Podium to create a crash log?
You can go to the interfaces dialog and create a report. Email it to me afterwards.
I’ve discovered that Podium streams the sound through it’s mixer from my sound card inputs, even if audio mixing for the track in question isn’t enabled. It seems to me when I enable audio mixing for such a track, the risk for a crash is at it’s greatest.
If the mapping assigned to the track is configured to route audio, then the track will be set up with audio streaming no matter what the ‘Enable audio..’ option in the track properties dialog is set to. If you could email me a project file that has the problems you describe, I can have a look at it. Maybe I can use it to recreate your crash scenario on my system.