ZynewaveThe upcoming 2.07 release has several improvements that deal with the timeline ruler and cursor placement. I plan to release 2.07 this weekend.
ZynewaveThis is improved in the upcoming 2.07 release. The timeline ruler have several new layout options, and middle mouse button can be used to set the edit cursor in all the timeline regions.
Zynewave@sam c wrote:
how do i set my offline bounce to mono prior to the bounce?
You can unhide the bounce track lane, and then open the properties dialog for the bounce sound.
Note that if you change the bounce sound to mono, Podium will not bounce-record any panning you’ve applied in the chain below the bounce track.
Zynewave@aMUSEd wrote:
With the latest version automation is working properly at the start of the track now but if I stop moving a knob but carry on recording (or move onto a different knob) the knob position is dropping to zero on playback from that point which ruins the track. It should stay where I left it.
I’m considering changing this behaviour in a future update. For the time being you need to resize the curve sequences to the full length of whatever they control, to avoid that the parameter value snaps back to the default value.
ZynewaveOoh, what a silly bug 😳 . I assume you are talking about auto-assigned audio inputs. Apparently I have only ever tested recording with auto-assigned MIDI inputs. Auto-assigned audio inputs do not record. Fixed for the next 2.07 release.
ZynewaveIt’s possible that DK+ cannot cope with multiprocessing of multiple instances. Try disabling the “plugin multiprocessing” option in Podium preferences, and see if this fixes the crash problem.
Zynewave@sam c wrote:
from someone who did not follow the betas but just downloaded the update tonight i wanted to tell you two initial things-
it is a little difficult to figure out the bounce off line, real time, hide lane, etc. it just is not intuitive.
What do you suggest needs to be changed?
also, i have never been able to render or off line bounce amplitube. but a new difference is the cpu load. in 2.05 and prior amplitube is a 22% hit on the podium mix cpu meter. on 2.06 it is 47%. i have double checked these numbers.
i will keep working with the update to see if i can get a handle on it. hopefully the cpu hit you can check out?
I don’t have Amplitube installed. Is it just with this plugin that you see a difference in CPU usage?
ZynewaveZynewaveI’ve added a “Select All Broken Plugins” command to the Devices menu. You can then right-click the selection to delete them or move them to a new folder.
ZynewaveBeta10 is up. This hopefully is the final beta. If I don’t find any bugs tomorrow, I’ll release 2.06 this weekend.
I’ve optimized and made minor changes to the way that solo and mute works. It is now possible to solo a bounced track, and still have the bounce playing. Previously the solo would disable the bounce.
If you have some spare time, please try this beta10 and check if your old arrangements still behave as expected.
@LiquidProj3ct wrote:
Cool, thxs. I think that at least the pan should be untweakable althought, visible but untweakable. It would seem more natural.
Perhaps in a later update. The way I see it, if the pan control should be disabled, then there are a lot of other inactive controls (bypass, sends, automation sliders, plugin editors, etc.) that also should be disabled because they have no effect when the track is bounced. And I think that would be a bit too much.
ZynewaveThe “Import File” command in the Arrangements & Sounds menu is intended for importing media files such as audio and midi files. Importing a whole project into another project is not recommended, for the reasons you mention. For that purpose, you should use the “Merge Project” command in the Projects menu. That command will join the device definitions of the two projects, so you don’t end up with duplicates.
ZynewaveBeta9 is uploaded, with the post-bounce gain controls. Let me know if you experience any problems.
@H-man wrote:
I also strongly agree with the others above that the PAN, if not functional on the bounced tracks, should be either locked or not visable.
Currently the text written on the pan slider/dial is dimmed, to indicate that it is inactive. I don’t think the pan control should be hidden, as you may want some indication of what the pan is set at, even when the track is bounced.
ZynewaveThe weekend release I had hoped for got delayed because I found some things in the track management that I wanted to optimize. During that work I examined the possibility of changing how the gain/pan faders work on bounce tracks. In the past there have been a lot of user-remarks about why it isn’t possible to adjust the gain/pan on bounce tracks. The reason is that the bounce sound records the track output which includes the gain/pan adjustments and any automation of these. The recommended solution has been to add another effect track above the bounce track and adjust gain on that track.
With a bit of work I can change the behaviour so that the gain control can be applied post-bounce instead of pre-bounce. I would have liked to be able to do the same with the pan control, but that is technically not possible. You can have both mono and stereo sounds playing on the same track, and the panning is applied separately to each mono/stereo source. So it is not possible to properly apply panning after the mono/stereo sounds have been mixed into a stereo bounce file.
If I change the gain to be post-bounce, it will have the consequence that all rendered bounce tracks in older projects will play at a different level, as the track gain adjustment in effect will be applied twice. You’ll need to redo the bounce in older projects to get the proper level in the bounce sounds.
Another benefit of a post-bounce gain, is that the bounce waveform overlaid on the tracks will be closer to full-range, as the track gain reduction is not recorded in the bounce sound.
So what do you think? Would it be weird to be able to adjust gain on bounce tracks, but not pan?
Zynewave@Zynewave wrote:
@pavouk100 wrote:
Beta7, still the same problem. I’ve an arrangement in which it is possible to consistently reproduce – click ‘B’ button, progress bar appears, goes through, finishes, progressbar disappears and the whole app is frozen, eating 100%CPU. Do you want me to PM you the .pod file, Fritz?
Yes. Please email it to: info at zynewave.com
Many thanks for the file. The freeze bug is now fixed in the new beta8. Also fixed in beta8:
• Fix: Starting playback shortly before the loop end position would sometimes continue playback beyond the loop range.
Zynewave@pavouk100 wrote:
Beta7, still the same problem. I’ve an arrangement in which it is possible to consistently reproduce – click ‘B’ button, progress bar appears, goes through, finishes, progressbar disappears and the whole app is frozen, eating 100%CPU. Do you want me to PM you the .pod file, Fritz?
Yes. Please email it to: info at zynewave.com