ZynewaveZynewaveZynewaveZynewaveI have not considered a Podium API. Currently I don’t think Podium is widespread enough for this kind of API to make sense. I can’t see anyone wanting to program something exclusively for Podium. I think most people working in audio software development would rather not have to support yet another proprietary protocol or file format.
Zynewavethe Bounce took around 15-20 minutes. With Audition, I’m used to a three to five minute mixdown to file
Such a difference must be due to something other than the actual performance of the bounce rendering. Rendering is performed as fast as possible, and using multiprocessing if available. Note that if punch-in/out is enabled the punch-in/out markers define the range that is bounced.
In Edit mode, I’ve tried chopping off the first two minutes of the recital (which was bounced as silence). It took maybe three minutes to do that. In Audition, that happens instantaneously.
Podium performs all edit actions in memory/cache files, and does not write to the sound file until you choose the save command. Maybe Audition operates directly on the file. When Podium cannot allocate more free RAM, it starts writing the edits to cache files, which may explain the slowdown. You can check if the RAM is used up with the Windows Task Manager. How much RAM do you have, and how big are your audio files?
ZynewaveI think I have a good sense of what features users expect. There are technical factors that I need to consider when deciding what to work on next. The amount of work that is required for a requested feature may not be proportional to the apparent complexity of the feature, as seen from a users standpoint. So there are quite a few “minor” feature requests on the future forum that I have put on hold, as they would heavily delay the implementation of some of the major features.
Furthermore, there can be technical reasons why I prefer to do some features in a certain order, as one feature may build on the implementation of other features. That’s why I prefer to concentrate on one area of Podium at the time. Like the recent mixer improvements, which currently have led me to think about some improvements to the main track region, as well as minor changes to the track properties. It all follows a red thread, but it’s not always possible to tell where this will end up a couple of months from now.
ZynewaveZynewavewill I get that feature as soon as possible or will I have to look for it elsewhere?
It is a feature that is on the plan, and I’ll definitely start on it at some point, but based on past experiences I cannot say when. Implementing this ASAP would mean that other features will slide down the priority list. Those other features may be more important to other users. The recent batch of mixer improvement releases was not something I had planned a couple of months ago, and it is a good example of how the priorities may shift as a consequence of user feedback. Before that I was working on time-stretching, which I hope to get back to when I’m done with the mixer improvements. After that, plugin MIDI routing support may well be next in line.
Zynewavethe vast majority of plugins are VST2’s, and I’d be surprised if VST3 would introduce a completely different way of processing MIDI data
It should be backwards-compatible, but they may introduce new methods in VST3 that would expand on the MIDI functionality. I’d prefer implementing this with the latest VST3 spec, rather than doing it with 2.4 and then having to redo it when VST3 comes out. I know that when they went from VST2.3 to 2.4, a lot of the old functions were declared “deprecated”, meaning that they may not be supported in future versions of the VST spec and future versions of Cubase etc.
ZynewaveThank you.
ZynewaveI very much hope so. I would prefer to wait until Steinberg releases the VST3 spec, as this may present some changes to how this can be supported. But there has been no news from Steinberg in a long time, regarding availability of the VST3 spec.
ZynewaveOr is it just my imagination
That it is. 🙂
The new send dials shown in the header are slightly smaller than the old send dials. This may make the pan dials appear bigger in comparison.
ZynewaveZynewaveZynewave