Zynewavedepending on the plug, the number of dials could alter enormously
The inlined dials would be based on the parameter objects defined for the plugin, so if the plugin has a large number of unneeded parameters, you could just delete those parameter objects.
I’m considering a more advanced solution, by adding some kind of graphic control type setting to the parameter properties. I’ll be experimenting with this when I start on the emulated editor for GUIless plugins.
ZynewaveI’ve been thinking about a solution where you in the arrangement properties can define one or more VST plugins to be used as channel plugins. Adding an EQ plugin here would then make the plugin parameters appear as dials inlined in the mixer channel strips (on the tracks where it has been enabled). This way you can more easily use your favorite VST effects as channel plugins. Implementing this would make it unnecessary for Podium to have builtin effects. Even if I could implement high-quality EQ and compression, there will always be someone who will not like the ‘flavour’ of the effects.
This idea is still in the design phase, so I don’t have an estimate on when it will be done.
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.
Zynewave