Zynewave's Forum Page

Forum Replies Created

Viewing 15 posts - 736 through 750 (of 5,965 total)

← 1 2 3 … 49 50 51 … 396 397 398 →

February 9, 2011 at 22:46 in reply to: x64 version? #20324

Zynewave
Keymaster

@4mica wrote:

So, Frits, you have a new computer now? Congratulations if you do…

I don’t have a new computer yet. Still no ETA of a 64-bit Podium build.

February 9, 2011 at 22:17 in reply to: Tags (late to the party) #20323

Zynewave
Keymaster

@druid wrote:

Frits, is this intentional, or an oversight? I don’t really want midi going to my group track for analysis, just want audio to run through it, almost for it to be invisble.

Input selectors are removed from all tracks in the bus return section. When you move a bus return track into a group track, this group track becomes the bus return section (which can be shown docked in the mixer). This was done as I thought it would be confusing to be able to assign inputs in the bus return section. So it is intentional, but I’ll consider removing the auto-hide of the input selector.

February 9, 2011 at 21:43 in reply to: S L O W loading and "not responding" errors #20322

Zynewave
Keymaster

@ronin wrote:

There was a problem a few versions ago which prevented fast shutdown of Podium. Security tools like virus scanners caused a massive delay while writing the configuration file. This has been fixed a few versions ago and that fix should already be in Podium free too.

This was fixed in 2.38, so it will appear in the next Podium Free release.

February 9, 2011 at 21:36 in reply to: How do I make my CPU stable #20321

Zynewave
Keymaster

I’ve removed the spam links from the post, and locked the account.

February 9, 2011 at 20:32 in reply to: x64 version? #20319

Zynewave
Keymaster

@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.

January 18, 2011 at 22:58 in reply to: Delay compensation #20259

Zynewave
Keymaster

@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.

January 12, 2011 at 16:11 in reply to: problem) cant buy podium #20243

Zynewave
Keymaster

Hi,

I’m currently changing my VAT registration, so I unfortunately have to take the shop offline for the time being.

Frits

January 11, 2011 at 21:53 in reply to: not enough memory to load sound font #20240

Zynewave
Keymaster

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.

January 5, 2011 at 17:43 in reply to: Videos for Absolute Beginners here #20216

Zynewave
Keymaster

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.

January 5, 2011 at 15:20 in reply to: Preview 2.41: MIDI input quantization #20215

Zynewave
Keymaster

@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.

January 2, 2011 at 19:02 in reply to: Preview 2.41: MIDI input quantization #20211

Zynewave
Keymaster

@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.

January 2, 2011 at 18:41 in reply to: Wave Pitch editing? #20210

Zynewave
Keymaster

I’ve grabbed the link, for later research. Thanks.

January 2, 2011 at 01:51 in reply to: Problem with Stereo Panning… help :( #20199

Zynewave
Keymaster

@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.

January 2, 2011 at 01:39 in reply to: Preview 2.41: MIDI input quantization #20198

Zynewave
Keymaster

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?

January 2, 2011 at 01:12 in reply to: I feel the need to do this!!!! #20197

Zynewave
Keymaster

Happy new year to all.

Viewing 15 posts - 736 through 750 (of 5,965 total)

← 1 2 3 … 49 50 51 … 396 397 398 →