Zynewave.
thcilnnahojNo bug, just a little weirdness: When you delete an event that you’ve got ready in the embedded editor (whichever type), you normally end up with an “empty” embedded editor. If you delete the whole track the event is on, however, the editor will stay and still reference the no longer existing event (provided there are no phantom copies of it left elsewhere).
This happens to the non-embedded editor also when you delete the event that’s currently opened in it, but in this case, I think there’s not much else to show other than an empty sequence window…
MelodyManI think it’s a bug but i can’t really reproduce it. When you want to pan your sounds in the mixer, some meters don’t show the panning; both sides (left and right) show activity, when only one side should. You can still hear the panning being done, but the visuals don’t show it.
Mind that this goes for only some tracks, that’s why it’s so weird. I have two guitar tracks with exactly the same plugins and settings on it and one shows the panning and one doesn’t.
thcilnnahoj@MelodyMan wrote:
I think it’s a bug but i can’t really reproduce it. When you want to pan your sounds in the mixer, some meters don’t show the panning; both sides (left and right) show activity, when only one side should. You can still hear the panning being done, but the visuals don’t show it.
Mind that this goes for only some tracks, that’s why it’s so weird. I have two guitar tracks with exactly the same plugins and settings on it and one shows the panning and one doesn’t.
You most likely have the meter position set to a track that’s further down the chain than the track the pan automation is on. Try checking where it’s set at in the mixer right-click menu (meter submenu) or enable the fader/meter grid from the mixer options menu.
Edit: Oh, or if you mean just the pan slider (no automation), then you probably have the meter set to a different position than the fader in one of the tracks’ effect chain!
MelodyMan@thcilnnahoj wrote:
@MelodyMan wrote:
I think it’s a bug but i can’t really reproduce it. When you want to pan your sounds in the mixer, some meters don’t show the panning; both sides (left and right) show activity, when only one side should. You can still hear the panning being done, but the visuals don’t show it.
Mind that this goes for only some tracks, that’s why it’s so weird. I have two guitar tracks with exactly the same plugins and settings on it and one shows the panning and one doesn’t.
You most likely have the meter position set to a track that’s further down the chain than the track the pan automation is on. Try checking where it’s set at in the mixer right-click menu (meter submenu) or enable the fader/meter grid from the mixer options menu.
Edit: Oh, or if you mean just the pan slider (no automation), then you probably have the meter set to a different position than the fader in one of the tracks’ effect chain!
I figured it out. It turned out that the panning-slider was in a different place in the effect-rack. Something you can’t see in the mixer, only in the rack-slot. In the mixer, the panning-slider is always on the bottom, but in the effect-rack you can really see its place in the effect-chain. Don’t know if you can call that a bug.
LiquidProj3ctI noticed, since 2.23 I think, that Podium reacts a little slow. Try this with feew 16th notes in loop, mute and unmute the track while it’s playing and you will see that the cursor has to move around 1bar or more until the mute/unmute/modified note take effect.
I downloaded another host to test, same drivers, and I hadn’t this problem.
thcilnnahojA little weirdeness again: If you adjust an audio event’s volume handle and while dragging, move the cursor near the edge of the tracks region, it will start scrolling lightning-fast: Example GIF (the same happens if you increase volume on a track further down, of course). The area in the example is very cramped, but this happens to me sometimes when I’m on the mixer page, where the tracks view only gets ~40% of the screen. Of course it should scroll if you try to move an event up or down, but not while dragging handles, I think. Edit2: A similar thing occurs when you’re resizing a track near the bottom edge. The grabbed edge of the track doesn’t follow the cursor anymore after you hit the scroll area at the bottom: Example GIF.
I’ve also got a question related to this: What’s the point of being able to scroll down far, far below the last track, almost into infinity? Shouldn’t it behave more like the navigator, stopping when only the last track is visible anymore? Edit: Oh yeah, after you scrolled down so far you no longer see any tracks, the navigator still falsly displays events on the bottom track as visible.
@LiquidProj3ct wrote:
I noticed, since 2.23 I think, that Podium reacts a little slow. Try this with feew 16th notes in loop, mute and unmute the track while it’s playing and you will see that the cursor has to move around 1bar or more until the mute/unmute/modified note take effect.
I downloaded another host to test, same drivers, and I hadn’t this problem.
In my experience Podium has always taken a little time to process MIDI again after unmuting a track or moving parts around, regardless of buffer size. Audio events play immediately after unmuting for me.
When bypassing just the instrument, and not muting the whole track, it works like that with MIDI events too – as I said, all in my experience.
If you actually never had this delay after unmuting before 2.23, then I’d be curious if I’ve been doing something wrong. :-k
LiquidProj3ctIf you actually never had this delay after unmuting before 2.23, then I’d be curious if I’ve been doing something wrong.
Or maybe I didn’t notice it before 😉 I weren’t using Podium between 2.16-2.22 (I was needing a feature for practise a new music genre)
Best regards
Zynewave@thcilnnahoj wrote:
A little weirdeness again: If you adjust an audio event’s volume handle and while dragging, move the cursor near the edge of the tracks region, it will start scrolling lightning-fast: Example GIF (the same happens if you increase volume on a track further down, of course). The area in the example is very cramped, but this happens to me sometimes when I’m on the mixer page, where the tracks view only gets ~40% of the screen. Of course it should scroll if you try to move an event up or down, but not while dragging handles, I think.
Fixed. Thanks.
Edit2: A similar thing occurs when you’re resizing a track near the bottom edge. The grabbed edge of the track doesn’t follow the cursor anymore after you hit the scroll area at the bottom: Example GIF.
I think this has been fixed with the new track height system implemented in the 2.25 beta. Let me know if you still have this problem.
I’ve also got a question related to this: What’s the point of being able to scroll down far, far below the last track, almost into infinity? Shouldn’t it behave more like the navigator, stopping when only the last track is visible anymore? Edit: Oh yeah, after you scrolled down so far you no longer see any tracks, the navigator still falsly displays events on the bottom track as visible.
I could add a limit, but I generally try to avoid imposing limits like these. Same reason you can (almost) scroll the timeline to infinity. If the topmost vertical position should be limited to the bottom of the last track, then various UI actions would cause the tracks region to scroll automatically. Say you have zoomed in on one of the bottom tracks. If you then collapse the master group track (in the mixer) this would cause the tracks region to scroll upwards to the now minmized tracks. When you then expand the master group track again you have lost the previous zoom position.
