Program change/loop playback bug -ACID Product Family

Subject:Program change/loop playback bug Posted by: CineGobs Date:4/21/2006 3:15:22 PM Loop playback is really great when experimenting with a MIDI track or when tweaking parameters on a VSTi. It works very well until you insert the Program change envelope. When it's inserted Acid resends the last Program change every time the loop starts over. Even if there's no keyframe anywhere near the loop region. Some VSTi's resets all the parameters when they receive a program change, which means that everything you've tweaked is reset every time the loop starts over. Many complex VSTi's needs a little time when changing program. One of my most used VSTi's: Rhino (Big Tick) takes a second to reset the parameters, which results in the sound stuttering every time the loop starts over. Furthermore this makes Acid's play-cursor get out of sync with the sound. Really annoying! Sony, please remove those superfluous program changes. Bo
Subject:RE: Program change/loop playback bug Reply by: pwppch Date:4/21/2006 5:30:38 PM I will assume that a Program Change Envelope is a Program Change Keyframe in ACID. I have seen this with Rhino. It doesn't look to see if the requested patch is the current patch and there for always reloads - and takes forever. So, when do you want it to chase Program changes? Example: If there is a program change before the loop and with in the loop. We must chase both if it is to playback correctly. With Rhino this would play havoc due to its expensive patch change processing. Also, if you have tweaked the synth settings during the loop playback you must save these, otherwise a seek before the keyframe will send the change to the synth. The only time this is avoided is if you don't use a keyframe and just set the track's voice. Since Rhino is very expensive on program changes, it does not lend itself to the use of program change keyframes on the time line. (I just tried this. Using keyframe changes with Rhino is generally ill advised unless there is lots of space between notes. Even then, it does not seem to process things in a timely manner so it can cause a delay/stall of playback even if the keyframe is significantly before any sequenced notes.) WRT the cursor. Rhino blocks big time on changes. It shouldn't do this. However, even after the lock up Rhino causes, the cursor does snap back. (Of course this is dependent on the audio drivers in use. Too long of a delay and the hardware can get out of sync.) Regardless, the plugin should never block the host. If it can't do what it is suppose to do during its time slice, then it must do it on the idle processing time provided. Anyway, I will look at what could be done to avoid the sending of the prg change during loop playback. Thanks for you input. Peter Message last edited on4/21/2006 6:16:52 PM bypwppch.
Subject:RE: Program change/loop playback bug Reply by: CineGobs Date:4/21/2006 6:36:36 PM Thanks for your info, Peter. >I will assume that a Program Change Envelope is a Program Change Keyframe in ACID. Yes (It's found in the menu: Insert/Remove envelope ;-) >If there is a program change before the loop and with in the loop. >We must chase both if it is to playback correctly. Yes thats inevitable, but if you have a keyframe at measure 1 and another one at measure 50, with a playback loop from measure 20-30. It seems unnecessary that the program change from the first keyframe is sent at every loop iteration. > Since Rhino is very expensive on program changes, it does not lend itself to the use of program change keyframes on the time line. It seems to work ok if I only change programs in silent passages, but I agree that Rhino is a special case. Btw: Most VSTi's ignore program changes when it's equal to the already selected program and I've just asked 'Tick if he could make an option in Rhino for that too. Bo
Subject:RE: Program change/loop playback bug Reply by: pwppch Date:4/21/2006 9:27:12 PM What you are requesting seems reasonable. I am reviewing our options. Thanks Peter

Subject:Program change/loop playback bug

Posted by: CineGobs

Date:4/21/2006 3:15:22 PM

Loop playback is really great when experimenting with a MIDI track or when tweaking parameters on a VSTi.

It works very well until you insert the Program change envelope. When it's inserted Acid resends the last Program change every time the loop starts over. Even if there's no keyframe anywhere near the loop region.

Some VSTi's resets all the parameters when they receive a program change, which means that everything you've tweaked is reset every time the loop starts over.

Many complex VSTi's needs a little time when changing program. One of my most used VSTi's: Rhino (Big Tick) takes a second to reset the parameters, which results in the sound stuttering every time the loop starts over. Furthermore this makes Acid's play-cursor get out of sync with the sound. Really annoying!

Sony, please remove those superfluous program changes.

Bo

Subject:RE: Program change/loop playback bug

Reply by: pwppch

Date:4/21/2006 5:30:38 PM

I will assume that a Program Change Envelope is a Program Change Keyframe in ACID.

I have seen this with Rhino. It doesn't look to see if the requested patch is the current patch and there for always reloads - and takes forever.

So, when do you want it to chase Program changes?

Example:

If there is a program change before the loop and with in the loop.

We must chase both if it is to playback correctly. With Rhino this would play havoc due to its expensive patch change processing.

Also, if you have tweaked the synth settings during the loop playback
you must save these, otherwise a seek before the keyframe will send the change to the synth.

The only time this is avoided is if you don't use a keyframe and just set the track's voice. Since Rhino is very expensive on program changes, it does not lend itself to the use of program change keyframes on the time line.

(I just tried this. Using keyframe changes with Rhino is generally ill advised unless there is lots of space between notes. Even then, it does not seem to process things in a timely manner so it can cause a delay/stall of playback even if the keyframe is significantly before any sequenced notes.)

WRT the cursor. Rhino blocks big time on changes. It shouldn't do this.

However, even after the lock up Rhino causes, the cursor does snap back. (Of course this is dependent on the audio drivers in use. Too long of a delay and the hardware can get out of sync.)

Regardless, the plugin should never block the host. If it can't do what it is suppose to do during its time slice, then it must do it on the idle processing time provided.

Anyway, I will look at what could be done to avoid the sending of the prg change during loop playback.

Thanks for you input.

Peter

Message last edited on4/21/2006 6:16:52 PM bypwppch.

Subject:RE: Program change/loop playback bug

Reply by: CineGobs

Date:4/21/2006 6:36:36 PM

Thanks for your info, Peter.

>I will assume that a Program Change Envelope is a Program Change Keyframe in ACID.

Yes (It's found in the menu: Insert/Remove envelope ;-)

>If there is a program change before the loop and with in the loop.
>We must chase both if it is to playback correctly.

Yes thats inevitable, but if you have a keyframe at measure 1 and another one at measure 50, with a playback loop from measure 20-30. It seems unnecessary that the program change from the first keyframe is sent at every loop iteration.

> Since Rhino is very expensive on program changes, it does not lend itself to the use of program change keyframes on the time line.

It seems to work ok if I only change programs in silent passages, but I agree that Rhino is a special case.

Btw: Most VSTi's ignore program changes when it's equal to the already selected program and I've just asked 'Tick if he could make an option in Rhino for that too.

Bo

Subject:RE: Program change/loop playback bug

Reply by: pwppch

Date:4/21/2006 9:27:12 PM

What you are requesting seems reasonable. I am reviewing our options.

Thanks
Peter