Zynewave's Forum Page
Forum Replies Created
-
ZynewaveKeymaster@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.
ZynewaveKeymasterZynewaveKeymaster@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.
ZynewaveKeymaster@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.
ZynewaveKeymasterWell, 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.
ZynewaveKeymaster@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.
ZynewaveKeymasterBeta9 is up. This one only has a CPU speed optimization of the UI repainting. Zooming and scrolling should not show significant speed improvement, but in cases where only stuff like meters and play cursor is updating there should be huge speed improvements. Let me know if you see any noticeable changes for better or worse.
ZynewaveKeymasterBug confirmed here as well 😮
I’ll fix that before 2.26 is released.
Frits, how does offline bouncing work, anyway? Does it interface at all with the audio device and/or its drivers (ASIO), or is it completely Podium and the plugins just working with data?
It doesn’t use the audio driver. It uses a buffer size of 128 samples (or the size set for the ASIO driver if it is smaller than 128 samples).
ZynewaveKeymasterWhat display resolution do you use?
Maybe there is somewhere in the display control panel where you can define how much of the system memory the gfx controller allocates? I remember many years ago, this was something you could set in the BIOS.
If you have other programs running while running Podium, try closing them to see if that makes the Podium CPU usage jump down. Even having just an Internet Explorer open will use up some graphics memory.
ZynewaveKeymasterAn explanation for these sudden jumps in UI CPU usage, could be because you’re on the edge of where the graphics card memory resources are being exhausted. Podium will create some of the often used bitmaps in native graphics card memory, if possible. This ensures that the gfx card hardware accelaration can be utilized. If there is not enough memory on the gfx card, then the PC CPU needs to kick in and do some of the rendering normally done on the gfx card. This is all handled by Windows.
The fact that you see a reduction when showing the track inspector, is likely because you then reduce the size of the timeline area. Please do this experiment to verify this:
When you see a high CPU usage, gradually size the Podium window smaller and check if there is a point where the CPU usage drops significantly.
Also, check your display control panel, and see what info is shown on the “Adapter” tab. There should be some info like “dedicated video memory”. Let me know what this is at.
ZynewaveKeymaster@Zynewave wrote:
Next I’m going to revise the way that tracks are drag-reordered. I think I figured out a simple way to allow a track to be dragged into a group track, even when it doesn’t have any child tracks yet.
😯 That turned out to be a tough job to implement, taking longer than I anticipated.
Check out the new beta8.
I think the revision of the track dragging is complete, including dragging when a tagged subset of tracks are shown. With the new method it is possible to drag any track into any group track, just by dragging vertically. When a track is dropped over the bottom half of a group track header, it will be added as the last child track.
Let me know if you find any problems with the new method of dragging tracks.
ZynewaveKeymasterBtw. In case you have selected a track timeline image file in the project properties, you could try to remove this. This is one of the things that may take up some CPU if the graphics card does not have a lot of memory.
ZynewaveKeymaster@sam c wrote:
@Zynewave wrote:
So the problem can be described as a sluggish UI? Is there anything that you can’t do, or is it just slow to respond?
It actually is workable if I don’t see the play cursor. If I have to see it I keep the inspector open and it is only 32% CPU and it works fine.
Please describe in what way it is not workable at the higher CPU usage. Things like: Does anything in the UI freeze? Does menus take several seconds to open? etc.
ZynewaveKeymaster@sam c wrote:
Desktop.
This was not happening in 2.23. I might have missed it in 2.24 it is hard to tell. I only opened my task manager because I was hearing a drop off when I should not have. My Podium mix never shows higher than 30%. If it does I might bounce to conserve so I could have missed this for awhile.
Ok, then I assume it’s possible that it is only a slight UI CPU usage increase in the recent Podium versions that caused the occasional dropout. It is likely that your previous Podium versions also showed a high CPU usage in the task manager, only just not enough to cause a dropout.
ZynewaveKeymaster@sam c wrote:
Frits, I can play without audio glitches even at 66%. I just can’t do anything else.
Ok, that makes better sense to me. I thought you had audio glitches even when the Podium CPU indicator was low.
So the problem can be described as a sluggish UI? Is there anything that you can’t do, or is it just slow to respond?
The CPU made available to the UI will decrease when the audio processing needs more CPU. This will of course result in an increasingly sluggish UI as the Podium audio CPU meter grows towards 100%. To make the UI snappier, the fix is to find what particular UI feature is using so much CPU.