So, the Podium CPU indicator shows 4% while the Windows task manager shows 66%?
As soon as you stop playback, does the CPU go back to normal?
You say it glitches. Do you mean you get gaps in the sound without the Podium CPU indicator going into the red?
Do you have any VST instruments in the arrangement? If there are any sample-based instruments then that can explain the rise in memory usage.
How did you make the recording of the realtime monitoring vs. playback?
Is the latency/jitter the same with different VSTi’s? Some instruments may have an internal buffering where they process notes and LFO’s etc. at certain sample intervals, for reasons of CPU optimization. The fact that a constant latency is added for the realtime monitoring may cause the notes to fall in different processing intervals within the synth, resulting in jitter.
It will depend on the ASIO buffer size and the sample rate.
Windows provides MIDI messages with with 1 ms accuracy, so that’s 44 samples jitter (at 44100 sample rate), compared to what you play on the MIDI keyboard. On top of that is all the latency added by the MIDI controller itself and the transmission to the PC.
Some hosts will try to play received MIDI messages as fast as possible, so they will queue up the events to be played at the start of the next ASIO buffer. This method will introduce a sample jitter for each note the size of the ASIO buffer. An ASIO buffer size of e.g. 4096 will add 93 ms jitter. Totally unusable. In Podium I add a latency of the ASIO buffer size to the monitored playback. That means the timing is steady and the jitter is minimal.
That latency is only added for the realtime-playback. The MIDI messages are still recorded with the timing that the MIDI events arrived at, which explains why you see a negative latency when you compare realtime-monitoring with playback. It can be argued whether the recorded events should be placed as they are performed or heard. Some may perform on their MIDI controller as a response to the timing of the arrangement playback, and others may perform on the MIDI controller in anticipation of what their instrument will sound like.
You’re right. I can adjust the calculation of the sample start point, so that it is based on the starting point of the arrangement, instead of the sample position that is closest at the event start position. I may update that in the future.
May I ask why you want to slice the event, if you want the sound to be continuous over the slice point? Normally when I work with sliced sound events, I add fade-in/out, in which case the one-sample gap is not a concern.
If you want sample-precise slicing, then you need to use the “linear (sample rate)” time resolution option when you create the arrangement.
When you use the bar/beat resolution the event time positions are stored with a resolution of 65536 units per bar. Depending on the tempo, that resolution does not match the sound samplerate, and so when you slice a sound event it may occur at a fraction of a single sample.
Strange. If you remove all plugins from the two tracks and just bounce render the raw audio, do you still get glitches?
@zamrate wrote:
Just downloaded the latest Podium yesterday to try out. So far I’m quite impressed, although I had a few crashes when doing drag’n’drop from Inspector Devices to Tracks.
I would be glad if you could find a way to reproduce those crashes. If it is a plugin you’re dragging onto a track, then it may be the plugin that crashes, in which case there is not much I can do. If it is not the plugin, then it should be an easy bug to fix, if you can tell me how to reproduce the bug.
I have created a new hardware definition for my Virus B: The MIDI comes from my M-Audio Delta1010LT card into the virus and the Virus B’s output goes back into Audio In 3/4. It all works for playing’n’sequencing.
I have 2 questions:
1) When I put a few MIDI notes into a sequence that is routed to the Virus B, I press play and record another track on Audio In 3/4 (= Out 1+2 of Virus B). Afer that I can see that the audio in the Audio Track is place too much on the left, as if it would come BEFORE the notes were even playing. Seems like the latency compensation does not work correctly in this case?
If you use the normal audio input mappings to record, then Podium cannot know that this is the Virus, and thus it does not compensate for the Virus MIDI playback.
For the delay compensation to work, you need to have an audio mapping in the Virus device definition, that is linked to the Virus MIDI mapping using the device definition and global instance settings in the mapping properties dialog. If you are using your Virus as a monotimbral synth, then you can combine both MIDI and audio in the same mapping. That way your Virus will appear like any monotimbral VST instrument. Check out the AN1x definition to see how that works.
2) Is it possible to directly bounce my sequence, just as if the Virus B would be a VSTi (in that case one just presses B and everything’s perfect). (I would like to: Stop the sequencer. Position the transport to the start of the sequence, press B and it would play and record the Virus B just as easily as once offline bounces VSTi’s.)
Yes, provided that you have set up your Virus as I mentioned above. Right-click the track where you have the Virus audio mapping, and select “bounce > enable realtime record bouncing”. Currently you have to go in and manually draw a sound event for the bounced sound. That will be fixed in one of the next Podium releases, so that this is done automatically when recording starts.
@thcilnnahoj wrote:
Also in beta6:
Inserting a bus send on a track will automatically add the matching bus return track. Pressing undo once will undo the creation of the bus return track. Pressing undo again will undo the insertion of the bus send.
The return track is not created, though, when you assign the send mapping to an already existing effect track.
Also, when you use the “move track to new group” command, the track created is not assigned a tag. I don’t know if the command will be around after multiple track selection comes around, but here you go anyway.
Thanks. Fixed in the beta7. There’s also a fix for the “add new child track” command which got broken in one of the earlier betas.
About the track header display: There are pros and cons for both methods. I think I’ll let the headers be as they are now. If it turns out that users find the non-hierarchic display confusing, then I can try an alternative solution where the headers are not adjusted if their parent group is hidden.
Also in beta7:
Group tracks now show the collapse button even if there are no child tracks in the group yet.
Next I’m going to revise the way that tracks are drag-reordered. I think I figured out a simple way to allow a track to be dragged into a group track, even when it doesn’t have any child tracks yet.
@thcilnnahoj wrote:
Nice, though I’m afraid it still glitches if there’s a track above it in the tracklist:
Fixed in the new beta6.
There seem to be a few discrepancies with the “depth” of the group level strips. I’m pretty tired, so I’m not sure what to make of it right now…
Here’s an example picture (thumbnail). On the left is what the actual hierarchy looks like.
Not really a bug. When the parent group track is hidden, I draw the header of the track all the way up to the top, instead of showing the arrow at the actual group level. That’s what happens in the middle part of your screenshot. I don’t know if it would make more sense to show the arrow when it does not point to a parent group :-k
A minor issue regarding the follow focus feature: selecting (docked) master or return tracks in the mixer scrolls the tracklist even if those tracks aren’t shown there.
Fixed.
Also in beta6:
Inserting a bus send on a track will automatically add the matching bus return track. Pressing undo once will undo the creation of the bus return track. Pressing undo again will undo the insertion of the bus send.
Beta5 is up. Bug-fixes, including all those reported in this topic so far.
There’s still some problems with dragging tracks when tags are selected, which is what I’m going to debug next. If you find other bugs, please let me know.
@thcilnnahoj wrote:
3. Normally, the navigator zoom snapshot buttons light up when you return to one of their zoom settings. This doesn’t seem to work though if you zoom to the full arrangement length by double-clicking the zoom pane. In the example GIF, I can get the snapshot button to activate after moving the pane around, but not anymore after zooming in and double-clicking to return to the original zoom level.
I’m not getting that here. It looks to me that your zoom snapshot is not exactly the full length.
Can you please verify, and describe how to reproduce this bug?
I try to focus on specific areas during Podium development. Currently it is the track management that is getting an overhaul. Working on improving the note editor will come later in the year. I can’t say when.
Your suggestion for ‘humanization’ edit commands applied on a note event selection, is something I may do.
I can’t see why it’s a problem to press the T key after a drag operation, to turn snap back on. I much prefer that over having a key shortcut for temporarily disabling snap while the key is held. There aren’t many unused single key-presses left, so I think it’s easier to manage two presses on the T key, rather than having to hold shift+T.
i see but it seems to be a bit fiddly to just move one note some ticks – change the grid setting – move – restore former grid setting
What’s your definition of a ‘tick’? Podium uses an internal resolution of 16384 PPQ, so if that is the tick resolution then it will take a lot of keypresses to notice any change. That’s why I use the quantize value as the step value.
@thcilnnahoj wrote:
Try the new beta3. I’ve made it so that tagged tracks that are part of a hidden/collapsed group, is now always shown. Check if you still get the visual bug as in your screenshot, and then tell me how your track hierarchy is. Note that in beta2 I dropped the implicit display of collapsed parent tracks for tagged child tracks. So, if a tag includes tracks from different groups, the tracks are not displayed with their actual hierarchy relations. It saves the space used for unneeded parent tracks. In beta1, the master track was always shown as collapsed at the top, which was annoying.
It’s the same in beta 3, unfortunately. The hierarchy consists of: Master < Vocals group track < Lead Vocal track. This glitch happens when the "lead vocal" track is shown (without its direct parent group) along with the master track.
Thanks. Fixed in the new beta4.
Other improvements:
The tags dialog show ghosted checkmarks next to tracks that are implicitly included in the tag by the “include child tracks…” option.
Adding new tracks will be assigned with the selected tag furthest to the right on the toolbar. So if both “busses” and “tracks” tags are selected, then the new track is assigned with the “tracks” tag. A new child track is not assigned with a tag, if the parent group is assigned with a selected tag and it has the “include child tracks…” option enabled.
I’m continuing my bug-fixing. I don’t plan to add further features, so hopefully 2.26 is ready for release within a week.
@michi_mak wrote:
1. Humanize on the timeline ( select notes – input “strength” – humanize ( randomize ) note start )
2. Humanize velocities ( same as 1. but for velocities )
There are no edit commands for these yet, but if you check the track properties dialog you will find settings for dynamic humanizing of timing and velocity. These will be randomized during playback.
3. when moving notes with mouse ( and snap off ) you can move notes in fractions of the grid – this does not work when moving notes with keyboard shortcuts – would be nice to have this fixed or changed
When you drag with the mouse while snap is off, your mouse position determines the position. When you use key shortcuts, there need to be a defined interval that the events should be shifted with. That interval is determined by the quantize setting. Use the Shift+D/F keys to change the quantize value.
4. related to 3. it would be nice to have a keyboard shortcut to temporarily disable the snap function while moving notes around
You can use ‘T’ key to toggle snap on/off. That will work also while you’re dragging events.
I’m considering adding another tag option called “Include parameter tracks of tagged tracks”, placed below the current “include child tracks of tagged group tracks” option.
Currently parameter tracks are always included when the source track is tagged, but would there be situations where you would like to show a bunch of source tracks together, without showing their automation tracks?