Conquistador@Zynewave wrote:
Does the full special edition of Podium feature in that one or the next edition, maybe due out around the end of Nov / early DEC ?
The next one coming out early December (issue 1|2007).
Cheers Fritz! 🙂
Conquistador@Podianer wrote:
I just saw in the current issue of BEAT, that the next issue includes a full version of Podium. So THAT is the mag that is gonna spread Podium.. 8)
Max
I had a look at Beat magazines website today. It looks like the latest edition has been on sale since the 3rd of November. Does the full special edition of Podium feature in that one or the next edition, maybe due out around the end of Nov / early DEC ?
Conquistador@Zynewave wrote:
Or is this already part of the plan?
Extending the destructive edit features of the sound editor is not on the immediate plan.
Thats fine 😉 I think the track level changes are more important right now anyway.
Cheers. 8)
ConquistadorI was thinking about this earlier today… will the fades and crossfades be accessible / editable from within the Sound editor as well as at track level?
Track level would be ideal of course (my first choice) but if not now, then at some stage applying / editing fades and crossfades would be nice to do from the Sound Editor as well, before clicking on Save sound as😉
Could slot in nicely as an option accessible from the Edit button.
Or is this already part of the plan?
ConquistadorThanks for the update. 😉
Conquistador@Zynewave wrote:
Ok, I did not find anything unexpected in your project. It works as intended.
If you mean the bounce process was accurate, then yes it does work as intended. It’s the slower bounce process when using the New Group Bounce track sound event length (which is as long as an arrangement) that I was trying to draw attention to here.
Even though your audio file playing into the reverb is shorter than the bounce event, there is no way for Podium to know that the plugin will be silent after the audio file has stopped playing.
You are talking about Podium not having any way to know the plugin will be silent. Maybe there is no way, but it should matter either way. It certainly should have no negative bearing on the speed of an offline render.
The necessity that Podium has with a sound event to bounce to, is really I think, the real problem here as other hosts that I have use/d, Tracktion, P5, Live, Sonar, Cubase e.t.c do not need a blank sound event to bounce to for offline rendering.
In the case of zReverb you have the tail that slowly dies out. Other effect plugins may produce audio continuously. So Podium will process the entire length of the bounce event (even if only feeding the plugin silence), because it assumes that the bounce event is set to that length for a reason
All well and good but…Podium really should not be processing the entire length of a blank sound event because it is causing slower bounces. Why process a bounce sound event that is 80 bars long when the child track event is one bar!
Fx tails in other hosts can be included without the necessity for a sound event that stretches all the way to the end of an arrangement…by default every time.
I do not know of any host that does this. Yes of course it does the job in Podium but really this area of Podium is behind other hosts. Some refinement to the feature cannot hurt surely.
In other hosts I simply select the track and bounce the contents of it. Simple. Or select a particular clip on the track and bounce that. Podium would benefit greatly from that level of simplicity with offline bounces.
Podiums realtime bounces on the other hand are fantastic and unique. Just not as fast as offline bounces for longer audio passages.
The need for a sound event for offline rendering makes the process work in Podium, but is slows it down compared to other hosts.
In the case of zReverb you’ll notice that once the progress bar goes past the section where the audio file is playing, the bounce render speeds up significantly because the zReverb is optimized to consume less CPU when input is silent and the reverb has died out.
But it is still slower than if I had drawn in my own sound event on the bounce track and then rendered. Every FX I have tried in Podium has this issue. zplug, kjearhus or Voxengo.
Btw. The bounce render even for your long bounce event took less than a second on my machine, so it was difficult to notice any difference between a short and long bounce event. How long does your render take with the long bounce event?
To make this clearer I have copied the file four times and then bounced with a long bounce event, (as long as the arrangement) it took about 5 secs and with a short bounce event that was only as long as the child track events it took about 2 – 3 secs.
Whichever way you look at it and however small or not the difference my be to you offline rendering is slower with a longer bounce event.
I am not the only one who has brought up the issue of slow bounces.
Perhaps if there is simply no way to avoid the use of a bounce event in Podium for offline renders because of the way it was designed (just guessing here) then the bounce event IMO could always be a little longer or as long as a child event but Podium could intelligently add FX tails to a render.
How do you get FX tails in a render?…you might ask, well other hosts have an option to include FX tails in renders. Perhaps this is how they avoid needing a blank sound event to bounce to.
Either way it works very well in other hosts. Or is faster as it does ‘work’ in Podium of course, but slower. Unless the bounce event is drawn in by a user.
I really think the suggestions I made in my first post on this thread will help. Here are some more…
1.(a) The provision of a user configurable FX tail option.
Let the user decide if FX tails will be included in a render.
1.(b) Allow a user to configure how much additional length will be added to a bounce sound event…1bar, 2bars e.t.c But the default length will match the child track event/s that are selected. This option allows for any user configured additional length to be added to that default length.
2.(a) Avoid the need altogether for a blank sound event to bounce to, as this is another step to take which is just not a necessity in the hosts I have used, and clearly slows offline renders down.
2.(b). Allow any individual clip to be rendered from a track or all clips on a track.
2.(c). (Same as 1a) Allow a user to configure how much additional length will be added to a bounce sound event…1bar, 2bars e.t.c But the default length will match the child track event/s that are selected. This option allows for any user configured additional length to be added to that default length.
In summary (yes I know it is a long post) 😉 …
I am just trying to suggest ways to refine the offline bounce process here Frits. It can and should be better. Especially compared to other hosts. 😉
Conquistador@Zynewave wrote:
Conquistador: If you have a project using zReverb (and only zReverb) that suffers from the slow bounce, please email it to me. I think it may be easier to understand what you’re talking about if I can see it in action.
Ok…a basic project has been sent over. You only need to simply render the track as is. But try it a second time, but this time draw in a sound event that is equal to the loop length. If you need the original file I can send that over.
With longer passages of audio it is even more noticable. It simply takes longer to get a rendered file when the sound event on the group bounce track stretches to the end of a project than when it matches the file size to be rendered (on the child track).
The problem persists with any length of file.
Conquistador@acousmod wrote:
I don’t think that these could be called “bugs”.
Bugs, design flaws, unforseen problem areas, in any case they are not working as they should or could.
The first one is something logical : if you render a longer file, it takes more time..
Of course as in any host. But…a slow bounce is not logical unless Frits always wanted offline bounces to be slower than other hosts which would be another matter entirely.
The second one must be corrected. If I remember well Frits has said that it was on purpose to be sure that the end of a previous event was not missing in the render.
We are slipping into developer issues here which is just not my area of expertise so I have no idea if Frits can change this behaviour. It would be nice if it could be done. To avoid slowing offline bounces down.
Perhaps the problem is also that we must use the bounce track feature for very differents purposes : freeze, premix and final bounce.
In an ideal software, there must be perhaps different actions and results.
For example :
– freeze : click on a button and the content of a track (and sub tracks) is temporarily replaced by a rendered version of all the used segments (not the silences !) which is invisible for the user, and can be “unfrozen” at any moment for editing
– premix : the actual bounce track feature
– final bounce : a simple menu that bounces all the arrangement (or a selection) directly to the disk, without the need to creating a bounce track and saving the file after.
Maybe…I think Frits has made a great effort to include offline renders into Podium however as Podium continues to mature it is not really so much major features that are needed (outside of a few) but more a case of refining the great features that are already there. Hence this thread. 😉
But the current offline bounce technique in Podium is already good for me, except for the workaround at the begining
It is good yes but I would prefer to not have the workaround as well.
Conquistador@Zynewave wrote:
If the effect plugin CPU usage is constant no matter the input (even silence) then the bounce render time is proportional with the length of the bounce event.
That may very well be correct but even the zReverb produces a slow bounce. As does every plug in (Kjaerhus and Voxengo) that I have tried so far. These are of course very popular plugin developers.
Perhaps I misunderstood what you said but it does not appear to make any difference to slow bounces even with zPlugins.
When a new bounce track is created the sound event is set to the length of the arrangement.
In a nutshell this is the problem. Offline renders as far as I can tell are accurate and precise. It’s just the way the sound event is created that is the problem. Changing that (as I suggested in my initial post) solves this problem.
If you want it to be shorter just resize the bounce event.
Yes that works but is not something I would want to do every time. Offline bounces are much quicker than realtime bounces especially for longer passages of audio. It is supposed to make things quicker. In it’s present state it doesn’t.
You can also press undo once after creating the bounce track. This will undo the bounce event creation. A second undo command will undo the bounce track creation.
Correct but again I would much rather have Podium do the work, not me by Podium not creating a sound event that is based on the length of an arrangement in the first place. That is clearly what is causing slow bounces so fixing that either by using the suggestions I made (or anything similar) solves the problem.
It really becomes a problem using offline renders for high track count arrangements if workarounds have to be used every time. Seriously Frits.
Too many workarounds in a host can build up to a point where they just waste precious time trying to keep track of them all, when a given feature really should just work properly. This has always been one of Podiums strengths and is why I started this thread. Your track record for fixing bugs is exceptional.
@acousmod wrote:
And don’t forget to place a Punch in point if the bounce section doesn’t start at the begining, because Podium calculates all the blank space from the begining or the punch in point.
Or has this changed ?
I just checked this out in 1.72. I placed a two bar loop at around bar 70 and an equal length blank event above it on the bounce track. It did take longer. So that is still a problem.
So really there are two bugs here.
1.The slow bounces caused by the connection between the arrangement length and the sound event that is created. Should be separate.
2. Podium calculating the blank space at the start of an arrangement into the bounce render process. Perhaps there is a different technical way to describe it but that is what is happening.
Here is a very interesing twist to the first bug…
I just tried the New Group Track option instead of the New Group Bounce Track and it wraps any track in a bounce track, of course this has been around for some time but crucially it creates an empty bounce track, leaving the user to draw in their own sound event length.
So the already existing New Group Track option already works in the same way as option c in my original post…
“No Bounce Sound Event. User configures length option will simply stop Podium from creating any sound event when the New Group Bounce Track option is used. Allowing a user to draw in the exact length he wants anywhere on a Group bounce track instead, to ensure a normal and much faster offline bounce every time”.
So frankly this makes the New Group Bounce Track in it’s current state a longer, and more time consuming way to bounce a track.
I guess the New Group Bounce Track option was designed to speed things up by offering a dedicated bounce track option available on right clicking but it is much quicker instead with the New Group Track option.
I would much rather prefer if the New Group Bounce Track option remains in Podium but with some way to accurately produce a sound event length for any clip in a quicker and much more efficient way. Many hosts do not even need to draw in a sound event first. Perhaps looking into a way to avoid the need for a sound event to bounce to, would eliminate the problem of sound events being too long?
Definitely two bugs here with slow bounces and Podium calculating blank space into render processing time.
Conquistador@Zynewave wrote:
Even if each arrangement uses a similar or identical file, all Podium would need to do is simply replace any instance of that file wherever it is missing in each arrangement in a Project.
That’s not what I meant. Say you have two different sound files: arrangement1/beat.wav and arrangement2/beat.wav. If you now rename both arrangement folders and want to relink the files in your project, Podium wouldn’t know which beat.wav belonged to which arrangement. Thus you need to do the search for one arrangement at the time.
Ok yes I agree. In that case it would cause a problem. It is probably best left as it is for now then with the “Search in File folder” option. It is still far quicker than relinking each file individually so I am quite happy with that. Thanks again for pointing me to the new write up in the guide. 😉
I guess at some point in future maybe Podium could get around the renaming of arrangements scenario you mentioned but for now it’s another layer of complexity that is porbably not needed, especially as Podium is now far easier to use IMO. Best left as is.
Thanks for the explanations.
Cheers. 😉
Conquistador@acousmod wrote:
If I remember well, it is on the plan ?
It looks like it’s already in Podium ! 😆
The “Search in File Folder” menu command was added in Podium 1.68, and in the latest 1.72 it was added to the guide:
http://www.zynewave.com/wiki/doku.php?id=guide:project_start_page#arrangements_sounds_panel
He he, thanks for pointing me there. I have not read the Podium guide for 1.72 yet. It does work as described as well thanks. 🙂
Your next question may be; “Why is there no “Search For Missing Sound Files” menu in the Arrangements & Sounds panel menu?”. Because each arrangement in a project may have similarly named sound files placed in different arrangement subfolders. So you need to select the broken sound files for one arrangement at the time, and direct the search to the proper subfolder for the arrangement.
That is quite a clever approach and does make sense but I still think a Project wide “Search for missing audio files” option in the Arrangement and Sounds column could be much quicker for linking any file that is missing in any arrangements within a Project.
Even if each arrangement uses a similar or identical file, all Podium would need to do is simply replace any instance of that file wherever it is missing in each arrangement in a Project.
So if Drum loop 9 is used in arrangements 1 and 5 for instance and is flagged as missing by Podium, the “Search for missing audio files” option would simply copy the same files to both arrangements. If Podium can flag files as missing in both arrangements it should I would have thought be able to replace them in both arrangements as well.
Also the “Search in File Folder” does work very well but as I am re linking files from an external firewire drive it would be even more useful to copy the missing files to my arrangement subfolder. So Podium would not just create a link but copy the missing files to any specific arrangements sub folder.
The Project wide “Search for missing folder option” I am now suggesting could also have a copy to Arrangement sub folder option. 😉 It just makes it far quicker to locate, copy and as a result restore links to large numbers of files in a single click. 😉
Conquistador@acousmod wrote:
… a dream for 2008 ?
Thats funny you almost made it sound like a request to host a major global sports event :lol:.
But anyway 8) 2 weeks, 2 months, 2008 or 2080! 🙂 …as usual I am simply making Frits aware of suggestions for Podium but he alone of course knows best when or even if to implement any of the suggestions made on this forum. 😉
Conquistador@acousmod wrote:
It is something like “consolidate” found in some hosts or the option “copy media in project” in Vegas ?
I think that it has already been asked and thought that it was already on the list, but I didn’t found it.
Good to remind it…
Yes the Vegas option you mentioned is exactly what I had in mind. 😉
@Zynewave wrote:
A menu command to copy all imported/externally linked sound files into the project/arrangement subfolders is something I plan to implement.
Great, thanks. 🙂
Conquistador@Jaegerteam wrote:
yes, in these 2 host sequencers you must not have a number of effects PER TRACK, you can also choose a number of effects PER CLIP. This means before and after each clip the effects are not active (which saves a lot of resources).
Drag and drop functionality for clip based FX would be great as well. 🙂
Conquistador@mahtazz wrote:
Thank you to share! 😀
If Frits likes the ideas, the information and links I provided will hopefully make this much easier to implement. 8)