Zynewave's Forum Page
Forum Replies Created
-
ZynewaveKeymaster@super_crunchy wrote:
@Zynewave wrote:
@super_crunchy wrote:
Something you may want to consider changing eventually, and this goes for realtime bounce as well… once a bounce track has finished recording (ie stop is pressed after recording) make the bounce track automatically turn off “Enable audio bouncing”
I’m not sure I understand. Do you mean that once you have bounce-recorded a track, either realtime or rendered, that you want the track to be converted to a regular audio track without the bounce button in the track header?
yes Frits, that would be good – because at the moment the bounced audio does not play back until “Enable audio bouncing” is turned off
Say what!? That’s the whole point of the bounce track. Once the B button is activated (and R button is deselected), the bounced audio track should play. This is indicated by muted subtracks and the audio event on the bounce track is drawn in unmuted color.
Another nice thing about the new bounce rendering, is that you don’t have to record arm the bounce tracks if you just want to render one bounce track at the time. The B button then behaves more like the freeze feature of other hosts.
Frits
ZynewaveKeymasterBy the way, you wrote that the punch in/out markers tell Podium what to render.. I still have to draw an event in the bounce track. Is this on purpose?
Yes. It allows you to restrict the track time range that you want to bounce. Note that the punch in/out markers are only used if the punch in/out buttons are selected. Good idea about the missing event warning. I’ll add that for the next release.
ZynewaveKeymaster@super_crunchy wrote:
Something you may want to consider changing eventually, and this goes for realtime bounce as well… once a bounce track has finished recording (ie stop is pressed after recording) make the bounce track automatically turn off “Enable audio bouncing”
I’m not sure I understand. Do you mean that once you have bounce-recorded a track, either realtime or rendered, that you want the track to be converted to a regular audio track without the bounce button in the track header?
Seems to be a few extra steps every time you bounce when realistically after you bounce, you’d only want to play the bounced audio. Well, this is the case for me, to save CPU cycles
When I have bounced an instrument track, I often switch off the bounce mode when composing, to make changes to the MIDI data or to rearrange sequences on the timeline, and then redo the recording. The track bounce feature was designed for quick switching between playing bounced audio and the live plugins.
ZynewaveKeymaster- Offline bounce track rendering.
ZynewaveKeymaster@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.
ZynewaveKeymasterHi 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
January 4, 2006 at 02:35 in reply to: Restricted to Podium license ownersZynewaveKeymasterThis content is restricted to Podium license owners.ZynewaveKeymasterWell 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.
ZynewaveKeymasterThere 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.
ZynewaveKeymaster@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?
ZynewaveKeymasterI finally have offline rendering working. I still need maybe a week to test it thoroughly. Will appear in release 1.46.
ZynewaveKeymasterI 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.
ZynewaveKeymasterIf 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.
ZynewaveKeymasterBut 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.
ZynewaveKeymasterAt 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.