View Single Post
Old 02-05-2012, 06:51 PM   #42
Coises
Human being with feelings
 
Coises's Avatar
 
Join Date: Jan 2011
Location: Maricopa, Arizona, USA
Posts: 28
Default

Quote:
Originally Posted by Reaktor:[Dave] View Post
Reaper knows that simply because "Send to track xx" is set to "post-fader" by standard. MIDI will be sent from track A to the VSTi-track B before it gets to the fx on the MIDI-sending track A you described. Audio comes back from the VSTi-track B and may alter the MIDI-stream via fx on track A. But who cares, as MIDI from now on is sent from one fx to the next without getting into another track (like track B) and thus cannot feed back?
That is not actually true.

Consider this:

which is about how we think of the sort of routing discussed in this thread.

It doesn’t really work that way, though; it works like this:


You can test this with feedback routing allowed using a MIDI-only effect like ReaControlMIDI and an audio effect. Both effects work, and if the audio effect can learn MIDI controllers, they will work, too.

I’m confident that if the audio effect did affect the MIDI, such as by filtering out CCs linked to effect parameters, that would happen, too; but I didn’t yet find an effect like that to try. If I’m wrong, then my second diagram isn’t correct. If I’m right, then the latency of the audio effect — or the “MIDI latency,” if there is such a thing as distinct from the audio latency — would be part of the delay in getting the MIDI on the track to the VSTi; and it would add to the latency ordinarily allowed for the audio effect in computing the total latency between playing the MIDI on the track and getting audio out of the track, since that effect is being passed through twice: once as MIDI and once as audio.

How can REAPER know that the audio effect doesn’t modify the MIDI output in a way that depends on its audio input? I think that it cannot; but the more I contemplate it, I’m not even sure that is the predominant problem.
Coises is offline   Reply With Quote