@throbert wrote:
good to hear of the possibility, Zyne. Do you have an ideal if there will be an xp64 bit version or is way too early to tell
It should work on XP64, but I will only be testing it on W7 64.
@MelodyMan wrote:
Bump for this problem. It’s still one of the things that annoys me the most in Podium. In Tracktion for instance, disabling the plugins is enough to not make them cause a delay anymore. In Podium i have to remove them from the track entirely, which is a pain.
The effect bypass button is “softer” than a plugin disable button. One purpose of the bypass button is to A/B the dry signal with the wet signal. For that purpose it is necessary to delay the dry bypassed signal with the same latency as the plugin, or else the dry/wet audio would shift in time.
Also why can’t one save an effect-chain on the Master-track?
I may add support for this later on. I haven’t implemented it yet, because I need to add code that filters out the audio output from the chain.
Hi,
I’m currently changing my VAT registration, so I unfortunately have to take the shop offline for the time being.
Frits
There’s no enough memory to load the selected sound font
That message is not generated by Podium. It must be sfz+ that displays it. Perhaps you could try to clear and then reselect the soundfont, after sfz+ has displayed the error message.
Hi Mike,
Very nice. I’m going to add those as favorites on my YouTube channel.
About tutorial 1:
The ~5 second delay you experience before the plugin scan dialog appears, after clicking the “create project” button, was caused by the old method I used to write the Podium.ini file. This was changed in Podium 2.38, so the next Podium Free release should no longer show this delay.
About tutorial 3:
Instead of 1/create track, 2/drag instrument from list onto track, you can have the track automatically created by dragging the instrument onto the blank area below the last track.
@thcilnnahoj wrote:
@Zynewave wrote:
@LiquidProj3ct wrote:
Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.
Could be possible have a track groove overwritted in real time with by secuences groove?
I’ll consider that. If a groove template is assigned to a sequence event, it would override any groove template assigned to the track.
I suppose a groove assigned to a track should be inherited by child tracks, agreed? This means that any parameter tracks will also be affected by the groove template on the parent track. This may not always be desirable, if you for example are using level automation to gate the audio synced to other tracks. So, perhaps the groove selector on the track should include the options “None”, “Use groove from parent track”, followed by the list of defined groove template sequences.
This sounds like a very good plan to me! 8)
I think this solution would make it redundant, or at least reduce the need for a dedicated “destructive” input quantization. You would just assign a straight 16th note groove to a drum sequence you are recording, and your recorded notes will automatically play quantized on the next loop. Once you are done with the layering of drum notes, you could apply the quantize edit command, to tidy up the sequence.
Comments, suggestions?
Wouldn’t that mean that you have to create a sequence before recording, or pause inputting notes after the first loop to set up a groove template for the sequence to have it auto-quantized? I don’t know how you do it, but I personally don’t create any sequences by hand when recording.
I guess this wouldn’t be an issue if there was a track-wide groove template as well, as suggested above.
It would require a pre-created sequence event before a groove template can be assigned to it, so that is one reason why being able to assign groove templates to tracks is a good idea.
@LiquidProj3ct wrote:
Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.
Could be possible have a track groove overwritted in real time with by secuences groove?
I’ll consider that. If a groove template is assigned to a sequence event, it would override any groove template assigned to the track.
I suppose a groove assigned to a track should be inherited by child tracks, agreed? This means that any parameter tracks will also be affected by the groove template on the parent track. This may not always be desirable, if you for example are using level automation to gate the audio synced to other tracks. So, perhaps the groove selector on the track should include the options “None”, “Use groove from parent track”, followed by the list of defined groove template sequences.
I’ve grabbed the link, for later research. Thanks.
@thcilnnahoj wrote:
I guess it might be an intentional limitation, since the pan value is greyed-out when the fader is set on a bounce track, though I don’t know why either.
It’s because the pan processing needs to consider the mono/stereo format of child tracks, pan-laws and any pan automation tracks. This information is not available once the child tracks are summed/bounced, so that is why the pan control is disabled on bounced tracks. It’s easier with the gain control, because this is applied identically on all bounce output channels.
Ok. After working with this for a few days now, I’m thinking that a proper implementation of groove templates would be better than my previous input quantization suggestion. So, forget everything I suggested previously in this topic, and consider this new extended sequence properties dialog instead:
Previously only the sequence name was in that dialog. You can assign multiple sequences as groove templates. Once you have defined one or more groove template sequences in a project, the right-click or edit menu of sequence events will contain a new “Groove” submenu, with the list of available groove templates.
Making the groove templates assignable to sequence events rather than tracks, makes it possible to assign different grooves along the timeline.
If you edit the sequence groove properties or the notes in the groove sequence, it will affect the playback in real-time of all sequence events that are assigned with that groove template.
I think this solution would make it redundant, or at least reduce the need for a dedicated “destructive” input quantization. You would just assign a straight 16th note groove to a drum sequence you are recording, and your recorded notes will automatically play quantized on the next loop. Once you are done with the layering of drum notes, you could apply the quantize edit command, to tidy up the sequence.
Comments, suggestions?
Happy new year to all.
@thcilnnahoj wrote:
@Zynewave wrote:
It would be stored per track, but it would not work as a track-wide automatic quantization. It would be used for setting up the note editor grid (much like how note map setup is done) and MIDI input recording. If changing the setting would automatically quantize all events, then it would be total mayhem.
Now I’m confused again. So it isn’t relevant to the arrangement editor snap setting but the note editor…? Meaning every time you open a sequence on the drum track, the editor’s snap value could be set differently than when editing a sequence on the piano or bass tracks?
Yes. There are pros and cons of that method. Often you would use different grid settings when editing drum sequences versus chord sequences, but on the other hand, you would need to set the appropriate grid setting every time you create a new track. The grid setting would work exactly like the current “note map” track properties. It’s probably a bad idea, but I just wanted to mention it as an alternative solution.
@thcilnnahoj wrote:
Do you think it’s better to have quantization applied destructively (but still reversible – I speaks gooder English in the morning :wink:) in order to have the notes drawn at the timeline position they’re actually played? I don’t know if a playback-only implementation would be confusing, but I do like the way the current MIDI transpose and randomize options work.
After giving it some thought, I think it is better to have the quantization applied to the events, so that the events are displayed on the editor timeline as they are played. Otherwise it would cause a lot of confusion when editing events, if you are not wary about whether a track is being quantized.
As a consequence of applying quantization to the events, you cannot have different quantization settings applied to phantom copies of a sequence on different tracks.
Did this work before, and if so, when did the bug start to happen: After an update to eXT or Podium? And which version?
Hi,
Podium does not include guitar amp/effect simulation. You’ll need to find third-party guitar effect VST plugins, that you then can load into Podium and use to process and record tracks.
I’m not familiar with any freeware guitar amp effects, so unless other Podium users come up with suggestions, you could try looking for info on a forum such as kvraudio.com
Frits