kingtubby.
ConquistadorI noticed that if for instance you have a two bar loop in Podium say from bar 4 to 6… If you press play and let it loop a couple of times then extend that loop end further, for example 3 bars to bar 9 Podium will not update fast enough.
So playback will ‘bounce’ back from the original bar 6 loop end point even if I have already moved the loop marker end point to bar 9.
Only once it has hit the original bar 6 loop end point (the loop end point is not even there at this point) and returned to bar 4 (or the original loop start point) will it correctly keep going past bar 6 to bar 9.
It is like Podium cannot change a loop point in real time without at least having to keep the original loop end point in memory or something, even if the loop end point has been moved further into the arrangement during playback.
I would have thought that if I move the loop end point from say bar 20 to bar 25 ( it’s easier to see with longer loop sections), provided I move the loop end point before it reaches bar 20 or in the first example bar 6 that it should not ignore this change (looping from bar 20 instead) until it has looped all the way back to the original start point first, then correctly loop past bar 20 to bar 25.
Or am I doing something wrong here?
ZynewaveOr am I doing something wrong here?
No. This is something I will improve at some point.
swindusI also noticed when adding notes in a drum editor while looping the playback drops immediately after adding a note and then starts again at the loop start.
ZynewaveTo achieve the ‘gap-less’ performance, Podium prepares the playback one second in advance before outputting the prepared buffers to MIDI and audio interfaces. This is why e.g. edits applied to events within one second of the current playback position will not be output.
Conquistador@Zynewave wrote:
Or am I doing something wrong here?
No. This is something I will improve at some point.
Thanks for clarifying that one. It has been a problem for sometime I just had not got round to posting it.
I also noticed when adding notes in a drum editor while looping the playback drops immediately after adding a note and then starts again at the loop start.
I noticed this as well especially when when preparing the drum map tutorial.
To achieve the ‘gap-less’ performance, Podium prepares the playback one second in advance before outputting the prepared buffers to MIDI and audio interfaces. This is why e.g. edits applied to events within one second of the current playback position will not be output.
Ok that explains it. Thanks. Don’t know if this is possible but if there was some way in future to have both gapless playback and to avoid the issues I, as well as Swindus experienced that would be ideal…if it is not possible then..it is just not possible 😉 . At least I now understand why this happens in Podium 😉
Cheers.
soundquist@Zynewave wrote:
Or am I doing something wrong here?
No. This is something I will improve at some point.
Good. The current behavior is a bit annoying.
/SQ
ZynewaveThe next 1.79 release will have a fix for this. Now the loop range should update properly within the current loop cycle if the play cursor is at least one second away from reaching the loop end point.
Conquistador@Zynewave wrote:
The next 1.79 release will have a fix for this. Now the loop range should update properly within the current loop cycle if the play cursor is at least one second away from reaching the loop end point.
Thanks Frits!
I noticed you also increased the hit point for selecting tracks in the group panel, now clicking any part of a track listed in the group panel (not just the top half) will select it in the group panel…perhaps that change should also have been on the 1.78 list, in any case…cheers! 🙂
spritex@Zynewave wrote:
To achieve the ‘gap-less’ performance, Podium prepares the playback one second in advance before outputting the prepared buffers to MIDI and audio interfaces. This is why e.g. edits applied to events within one second of the current playback position will not be output.
This is one of the first things I noticed when I started testing Podium yesterday. It’s a bit annoying when you are editing a drumloop or whatever.
If it can’t be gotten rid of, would it be possible to make an option to change this from 1 sec. to a shorter time sacrificing CPU cycles of course?
Oh, and hello – this is my first post here! 🙂
I am currently pondering if I should purchase it (testing with the 1.77 demo).
(I wrote a couple of messages on KVR as you might remember.)
Zynewave@spritex wrote:
@Zynewave wrote:
To achieve the ‘gap-less’ performance, Podium prepares the playback one second in advance before outputting the prepared buffers to MIDI and audio interfaces. This is why e.g. edits applied to events within one second of the current playback position will not be output.
This is one of the first things I noticed when I started testing Podium yesterday. It’s a bit annoying when you are editing a drumloop or whatever.
If it can’t be gotten rid of, would it be possible to make an option to change this from 1 sec. to a shorter time sacrificing CPU cycles of course?
Hi spritex,
Are you talking about realtime response to loop range adjustments or editing events?
spritexEditing events.
(And you sure respond fast, I like!)
Zynewave@spritex wrote:
Editing events.
To make sure I understand you correctly: The problem you experience is that inserting/editing events that are within one second ahead of the play cursor is not heard until the next loop cycle?
This realtime response can be improved, but it will require a few days of work. Currently I feel my time is better spent on some of the more essential features that have been discussed on this forum recently.
spritex@Zynewave wrote:
@spritex wrote:
Editing events.
To make sure I understand you correctly: The problem you experience is that inserting/editing events that are within one second ahead of the play cursor is not heard until the next loop cycle?
Exactly. 1 sec. is quite a long time when editing a four bar loop.
I trust that you are doing important things, I gathered as much. 🙂
But it would be important to have a more instant feel to the editing, so I hope that you’ll try improve it when time allows.
EDIT: I played with it for a while again, and it’s in no way unusable as is – but halving the time to 0,5 sec. would be really nice.
ConquistadorI have noticed that when building drums in Podium over say 4 bars that Podium can sometimes drop out audio wise.
If I enter the midi data while it’s looping it seems ok but…it appears if I enter data too close to the time the play cursor starts looping (back to the beggining of a loop or loop start point) then Podium will play back the entire 4 bar loop in complete silence until it starts the loop again.
It is as if Podium’s engine is knocked out of sync or dis engaged by midi data entry if it takes place too to close to the time the play cursor reaches the end of a loop.
This problem really does complicate drum production somewhat.
This realtime response can be improved, but it will require a few days of work. Currently I feel my time is better spent on some of the more essential features that have been discussed on this forum recently.
Of course improvements have been made since this discussion began (thanks) but the midi entry issue still appears to be there.
If possible please do consider looking at this problem at some point (I appreciate you do have to carefully prioritise user requests and fixes e.t.c) and you have consistently done this very well, but when you can please do re visit this problem as drum production can be unpredictable in Podium.
Cheers.
cachet25@Conquistador wrote:
I have noticed that when building drums in Podium over say 4 bars that Podium can sometimes drop out audio wise.
If I enter the midi data while it’s looping it seems ok but…it appears if I enter data too close to the time the play cursor starts looping (back to the beggining of a loop or loop start point) then Podium will play back the entire 4 bar loop in complete silence until it starts the loop again.
It is as if Podium’s engine is knocked out of sync or dis engaged by midi data entry if it takes place too to close to the time the play cursor reaches the end of a loop.
This problem really does complicate drum production somewhat.
This realtime response can be improved, but it will require a few days of work. Currently I feel my time is better spent on some of the more essential features that have been discussed on this forum recently.
Of course improvements have been made since this discussion began (thanks) but the midi entry issue still appears to be there.
If possible please do consider looking at this problem at some point (I appreciate you do have to carefully prioritise user requests and fixes e.t.c) and you have consistently done this very well, but when you can please do re visit this problem as drum production can be unpredictable in Podium.
Cheers.
I’ve notice this too when I edit drums