There is no built-in video support currently. I hope one day to integrate video playback support into Podium, but I have no idea when I’ll find time for this.
One solution meanwhile could be to use a video playback VST plugin. There’s some discussion of that here:
Thanks 8)
An “advanced quantize” edit command has been on my todo list for quite a while. This will open a dialog where you can set “quantize strength” in percentage, along with other stuff like randomization and swing. The dialog will have a “preview” option (like the beat-slice dialog), so that you can hear changes to the settings in real-time.
I’m currently on a roll with track management updates, but I can be persuaded to take a little detour around this feature. How about this: If you buy a license, I’ll release 2.27 next week with the dialog described above? You’ll be able to try out betas and have your say in how features should work 😉
@druid wrote:
Thanks for fixing the bug I posted. Though I couldn’t test it, it was reported that 88200Hz has the issue too. Have you fixed it for this as well?
(I ask just in case; it’s quite possible the fix was a general one and doesn’t need to be tweaked for each sample rate. 😛 )
Yes. it should work with all samplerates. If you want to test it, try the 2.26 beta10 I just uploaded.
Beta10 is up. This is hopefully the last beta. If no bugs are reported, I’ll release it before the weekend.
I think I have fixed all bugs reported in this topic. Let me know if you find anything not working as expected.
I’ve revised the way new tracks are created, so that they now are inserted after the shown tagged tracks, instead of after the last of all tracks.
Double-click and right-click can be used on the empty space in the mixer region to create new tracks.
@thcilnnahoj wrote:
Okay, since this is taken care of, please allow me to share some of my bouncing woes. In the hope that it’s just me who’s doing something wrong. 😉
1. Delay compensation isn’t quite right when a track is bounce-enabled and the effect producing the delay is bypassed.
2. Sometimes, there are segments that just don’t get rendered. The bigger the delay a plug-in adds, the more often it seems to happen. This is most prominent at bar 1, but I’ve since also had it happen elsewhere, especially with short audio events.
Both can be seen in a short video I just uploaded: http://www.youtube.com/watch?v=IJT33lhDhh4 (I don’t know why, but YouTube does some horrible resizing :?)
Thanks for the video.
It seems that setting the bounce capture on an effect track will “bypass” the bypass delay compensation of the plugin on that effect track. The bug can be worked around by inserting an effect track above the delay introducing effect, and set the bounce on that effect track.
2. Sometimes, there are segments that just don’t get rendered.
In your video you have SIR on the track. Does the dropped audio in the bounce happen only when you have a delay introducing effect on the track?
I’ve fixed the 96K (and 192K) samplerate bounce bug mentioned in this topic, but the issue with the delay compensation may have to wait until 2.27, so I have more time to get it right.
@thcilnnahoj wrote:
– I get a crash when I use a tag that has “include child tracks …” disabled, and I try to select a group track (it has to have a child track) that is the last track visible in the tracklist. Only happens in the arrangement view, and strangely doesn’t crash when I select it with the arrow keys.
I followed your description, but I could not make it crash. I must be missing some crucial step. Could you perhaps describe it more detailed, or make a gif?
– In an arrangement with multiple “master” tracks, they will not appear docked in the mixer, which I really think they should if docking is enabled! 🙂
If both masters are docked, then it will be difficult to see which undocked tracks belong to which master.
@sam c wrote:
Frits, is there a way to remove the entire new track tool bar? I can see how to remove SMR and Tags, but what about deleting that new bar from my view if I do not need it?
Select “view > customize editor profile” menu, and then delete the “Toolbar (Track)” region. You may want to delete the “Space (Recess)” region above it as well.
Well, I’m glad you reported this issue Sam, because it made me look at my UI updating code. I tried out an alternative method, that helps reduce the areas that are painted when only things like meters and the play cursor are updating. At least on my machine it meant a huge reduction in UI cpu usage 🙂
If you want to test it, you can download the 2.26 beta9.
Let me know if this reduces your CPU usage further.
@UncleAge wrote:
I had a similar problem a couple of years ago in another app. What sparked the memory was your mention of the cursor issue. For some reason my comp was having issues and the all revolved around the cursor. The program was drawing its own cursor instead using a system cursor (I have no idea how Podium handles this) and the only way to resolve it was to reduce the hardware acceleration of the video card. I could do it from the desktop using the display settings.
I think Sam referred to the Podium play cursor, and not the mouse cursor. Podium does not do anything non-standard with the mouse cursor pointers.
Normally I recommend that the hardware acceleration slider is set to maximum acceleration. For each step you move the slider down, you’re telling Windows that more of the stuff that normally is handled by the video card, should be emulated by the main CPU. That means less CPU time for the audio processing. But if there are problems with the video driver, reducing this setting is a solution. That seems to be the case here.
Sam, perhaps you could check if there are updated video drivers for your VAIO PC.