ZynewaveZynewave@townkat wrote:
being my first post i must thank you for your work (wich fortunately is based on a great IDEA)
Thanks, and welcome to the forum.
The solution I ended up with is a combination of option A and B. You can select ‘render bounce track’ with the track context menu, ctrl+b key shortcut, or ctrl+clicking the B track button. This will render the selected bounce track, even if the track is not record armed, but it will also render any other record armed bounce tracks in one go. That way you decide whether you want to bounce one or multiple tracks, using the same key shortcut.
ZynewaveHi townkat,
Default behaviour of mouse-wheel in Podium is vertical scrolling. Holding shift will scroll horizontally. I chose this behaviour in the editors as well. I’m constantly using the wheel to scroll the track list, piano-roll range, and the time range. You can use the wheel for zooming, provided that you press the shortcut keys for activating the zoom tools, i.e. combinations of shift+ctrl+alt.
However, extra functionality could be provided by use of modifier keys..
eg
Just Mouse Wheel – vertical scroll (as now)
Shift Mouse Wheel – horizontal scroll
Ctrl Mouse Wheel – vertical zoom
Ctrl+Shift Mouse Wheel – horizontal zoom.
Duncan, that’s pretty close to how it already is working. 😉
Frits
ZynewaveZynewaveWell said suges. I’ve made the decision not to put much of an effort into marketing for the first few months, to concentrate on implementing some of the major features.
ZynewaveThere is “realtime export” flag in Cubase audio export dialog and “1x rendering” in Tracktion options.
I don’t think there is much difference between Podiums realtime bounce recording and other applications realtime render options. For the time being I recommend using Podiums existing bounce recording with plugins that can’t render faster than realtime. The existing bounce recording system will not change with the introduction of offline rendering.
Zynewave@Podianer wrote:
Will there be an option for bounce in realtime? I know that the actual bounce is in realtime, but one has to play the arrangement, which, concerning spikes, can be difficult.. Some plug-ins need the slow export/bounce to work correctly..
An option for realtime rendering will not be in the imminent release. If the plugin produces CPU spikes during normal playback, then it will spike during realtime rendering too. The difference being that the rendering don’t need to bypass the plugin when it uses too much CPU, so you won’t have dropouts in the rendered sound. Do you have any examples of plugins that don’t behave as expected when rendered faster than realtime?
ZynewaveI finally have offline rendering working. I still need maybe a week to test it thoroughly. Will appear in release 1.46.
ZynewaveI can confirm that preset storage is not working. If I create a program library preset, then the resulting file appears to be too small to contain the actual preset. If I create a bank library preset, the file is bigger and appears to contain preset data. However upon reload of the plugin, I only managed to make it load the bank preset by selecting a program preset afterwards. I also somehow managed to crash the plugin by doing various bank preset assignments. I would like to keep focus on implementing offline bouncing, so I don’t have time currently to debug this plugin.
ZynewaveIf anyone has a better way of naming the ‘source’ and ‘target’ settings in the mapping properties dialog, then I’m all ears. I originally named these input and output, but the problem is that when you map plugins and soundcards, input and output has opposite meanings. The soundcard provides audio to the host through the soundcard inputs, but plugins provides audio through the plugin outputs. Instead of mapping soundcard input, you should be mapping microphone output, and instead of soundcard output, you should be mapping speaker/headphone inputs. But when dealing with soundcards, people are accustomed to the input/output labeling on the actual soundcard.
ZynewaveBut this bus routing remains very strange for me, since in other mappings the “Target” represents the source audio track and the “Source” represents the target upper track
You should view ‘target’ and ‘source’ from the point of view of the Podium engine. Source is always something that provides input to the mixer. When mapping soundcards, source is the soundcard inputs. When mapping plugins and busses, source is the plugin and bus outputs.
ZynewaveAt work I’m able to use a 2.5GhzP4HT machine, which is nice, but my laptop is a 1GhzP3. The C option would lock everything out until the offline bounce is done, the suddenly all would be well…
No it wouldn’t. The background bouncing would run in a low priority thread, so the realtime engine would not suffer from any ongoing background bouncing except from the extra memory required by the background engine plugins. The UI would not be blocked in any way either.
ZynewaveBut I suppose that even if it becomes the default in Podium, users will be able to continue to use it like it is now ?
The arrangement sub-folders will be optional.
ZynewaveYou have set up your bus 1-3 mappings to be both source and target. You need to modify these bus mappings so they only send mono into the bus (and not return). These mono mappings can be offset to the desired channel number in the bus. Then you create a new bus return mapping configured to extract 16 channels of the bus, which then will be streamed correctly to the 16 channel master out. I have emailed a modified project back to you.
ZynewaveSub-folders for arrangements is already on the plan. I think it will only be necessary with one folder for each arrangement. There is no need to create further MIDI/Audio folders, as Podium does not use individual MIDI files.