Old 08-09-2009, 07:29 AM   #1
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default Audio delay when send to MIDI track

Feature Request in Issue Tracker
http://forum.cockos.com/project.php?issueid=2722

Another Discussion Thread started recently
http://forum.cockos.com/showthread.php?t=75202

EDIT: this is now a feature request

Description
Currently REAPER does not distinguish between MIDI and audio feedback
routing, but rather treats them as a single connection (data type) where
MIDI or audio can be filtered out.

This is an issue as it does not allow users to manually set MIDI and audio
routing with multichannel VSTis using less tracks, which is reducing the efficiency of
already flexible routing capabilities. It also defeats the PDC when the routing
is actually not in feedback, which could be considered as a bug.

User notification [suggested by Evan]
When feedback routing is disabled in project settings, user should
be notified with a pop up that no signal will come from any tracks in
routing upon creating such a connection.

-

Quote:
Originally Posted by Original OP
Hey Reapers,

I have a bit of an issue going on.

The thing is when I am using the NI Battery and MIDI, and route
the 32 channel track (where the VST is) directly to the master output,
than there is no delay between the MIDI triggered sound and the same
audio sample on another audio track - for testing purpose (if I sum
the signals and phase reverse one I get zero amplitude as expected).

However if I send the audio back to the same track that contains
MIDI data to trigger this sample (for the purpose of having one
track with MIDI and audio chain with fx & envelopes), and use
this as an output to master, I get a slight delay of ~ 13ms if I
read this correctly. A strange thing again, if I send it to a new
empty track, the delay is not present. So it happens only if I route
it to the same track that has MIDI data.



Does anyone have an explanation/tip/same issue...?


Of course I can always use two tracks, one for MIDI and one for
audio, but why not use one if it is possible
Regards,
e

Last edited by EricM; 02-05-2012 at 12:49 AM. Reason: Added FR in Issue Tracker
EricM is offline   Reply With Quote
Old 08-09-2009, 07:53 AM   #2
mabian
Human being with feelings
 
mabian's Avatar
 
Join Date: Aug 2007
Location: Italy
Posts: 3,582
Default

Hi,

maybe you have a feedback problem here, because the VST track always plays also the 1/2 channels, you cannot prevent this.

So, you are sending channels 1/2 to another track and that track is sending again the same audio to the original track. Have you enabled feedback prevention option? If so, you should actually get silence, so I guess you have it disabled.

Don't know about the delay though, but maybe the feedback plays a role here...

- Mario
__________________
My DAW: Intel i7700k @4.2GHz / 16GB RAM / RME Fireface UC / 250GB SSD / 2x2TB HD / Win10x64
My Music: http://www.reverbnation.com/errepici - http://www.errepici.it/web/contents.asp?sec=4
mabian is offline   Reply With Quote
Old 08-09-2009, 08:55 AM   #3
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Fist off, thank you for your input!

The thing is, I have to have feedback enabled, if I even want to
route back to track that sends MIDI to VST. I prevent the feedback
from happening by disabling audio send when sending MIDI to VST,
and disable MIDI receive when accepting audio on the 1/2 track.

VST's output Master/Parent send is unchecked, so no audio signals
go to Master. It is being routed to a track. The only difference
is, that in case it is the same track that has MIDI, a delay will
happen.

This is the signal flow:

EricM is offline   Reply With Quote
Old 08-09-2009, 10:17 AM   #4
Mercado_Negro
Moderator
 
Mercado_Negro's Avatar
 
Join Date: Aug 2007
Location: Caracas, Venezuela
Posts: 8,245
Default

Yes, this happens but it's not a bug... it's latency dependent. The more latency the more delay. Reaper needs time to send/read the information from one track only, that's my theory. This behaviour made me quit FBR.
__________________
Pressure is what turns coal into diamonds - Michael a.k.a. Runaway
Mercado_Negro is offline   Reply With Quote
Old 08-09-2009, 10:20 AM   #5
mabian
Human being with feelings
 
mabian's Avatar
 
Join Date: Aug 2007
Location: Italy
Posts: 3,582
Default

Shouldn't PDC take care of the latency and compensate (provided it's not live input but input coming from track events)?

- Mario
__________________
My DAW: Intel i7700k @4.2GHz / 16GB RAM / RME Fireface UC / 250GB SSD / 2x2TB HD / Win10x64
My Music: http://www.reverbnation.com/errepici - http://www.errepici.it/web/contents.asp?sec=4
mabian is offline   Reply With Quote
Old 08-09-2009, 10:25 AM   #6
schwa
Administrator
 
schwa's Avatar
 
Join Date: Mar 2007
Location: NY
Posts: 9,926
Default

Feedback routing defeats PDC, because otherwise the latency could diverge.

Because of this, we recommend using feedback routing for specific feedback effects, not for tidy project management.
schwa is offline   Reply With Quote
Old 08-09-2009, 10:34 AM   #7
mabian
Human being with feelings
 
mabian's Avatar
 
Join Date: Aug 2007
Location: Italy
Posts: 3,582
Default

I'm getting confused here: the described routing actually doesn't seem to be a feedback, because MIDI goes one direction and audio another. Does PDC get defeated anyway?

- Mario
__________________
My DAW: Intel i7700k @4.2GHz / 16GB RAM / RME Fireface UC / 250GB SSD / 2x2TB HD / Win10x64
My Music: http://www.reverbnation.com/errepici - http://www.errepici.it/web/contents.asp?sec=4
mabian is offline   Reply With Quote
Old 08-09-2009, 10:35 AM   #8
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by schwa View Post
Feedback routing defeats PDC, because otherwise the latency could diverge.

Because of this, we recommend using feedback routing for specific feedback effects, not for tidy project management.
Of course, I didn't even think of this safety precaution...

Thanks for the info all!


Edit
-------
Mabian: it not technically a feedback routing, as different types of data are
sent each way. But the connection itself is considered as such in the software
(as "sends" carry both MIDI and Audio, even though one can be disabled)...

This type of routing could still be considered non-feedback in my opinion.

Last edited by EricM; 08-09-2009 at 10:41 AM.
EricM is offline   Reply With Quote
Old 08-09-2009, 11:02 AM   #9
gofer
-blänk-
 
gofer's Avatar
 
Join Date: Jun 2008
Posts: 11,098
Default

Quote:
Originally Posted by mabian View Post
I'm getting confused here: the described routing actually doesn't seem to be a feedback, because MIDI goes one direction and audio another. Does PDC get defeated anyway?

- Mario
This is the part I also don't understand. Just curios: Could this special case not be savely allowed as non-feedback routing and thus avoid the problem? Kind of a SEP (Somebody Else's Problem) solution to the issue
gofer is offline   Reply With Quote
Old 05-10-2010, 09:43 AM   #10
Evan
Human being with feelings
 
Join Date: Oct 2006
Location: Greece
Posts: 3,519
Default

[resurrecting thread]

This topic is important for increasing routing flexibility with multi-out instruments.

Does it really classify as 'feedback routing' when:

track A sends audio only to track B, and
track B sends midi only to track A
?

By adding more elaborate check code, perhaps Reaper can determine that such track relationships can still have PDC active?

And one more thing, if something is forbidden, not allowed, does not work, it's better to not let it happen and give the user information about it. When 'feedback routing' is disabled, users can still build audio-to-audio feedbacks between tracks, they will simply not work (and without warning).
Evan is offline   Reply With Quote
Old 05-10-2010, 10:01 AM   #11
stupeT
Human being with feelings
 
stupeT's Avatar
 
Join Date: Jan 2009
Location: frankonia
Posts: 1,996
Default

Maybe PDC gehts hampered when there is audio and MIDI on that track?
__________________
------------------------------------------
Don't read this sentence to it's end, please.
stupeT is offline   Reply With Quote
Old 05-14-2010, 01:31 PM   #12
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by Evan View Post
And one more thing, if something is forbidden, not allowed, does not work, it's better to not let it happen and give the user information about it. When 'feedback routing' is disabled, users can still build audio-to-audio feedbacks between tracks, they will simply not work (and without warning).
+1 to that, I was loosing my head on that project why I get no signal at all,
found out i had to enabled feedback routing for midi-audio to work as
presented in OP, sadly not as expected.
EricM is offline   Reply With Quote
Old 06-29-2010, 12:58 PM   #13
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,639
Default

I have to bump and +1 this as well.

Audio and MIDI are not same data types. So, if I have a "feedback" which sends audio on one side and receives MIDI on another side, technically that's not audio feedback, and cannot be considered a feedback loop.


Can we get some confirmation from the devs about this? It would really rock if we would be able to do this without enabling Allow feedback routing.
EvilDragon is online now   Reply With Quote
Old 06-29-2010, 01:43 PM   #14
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 8,585
Default

Quote:
Originally Posted by EvilDragon View Post
Can we get some confirmation from the devs about this? It would really rock if we would be able to do this without enabling Allow feedback routing.
+1
Would be nice.
nofish is offline   Reply With Quote
Old 06-29-2010, 03:58 PM   #15
-R-
Human being with feelings
 
-R-'s Avatar
 
Join Date: Mar 2010
Posts: 305
Default

+1 and +1
-R- is offline   Reply With Quote
Old 06-29-2010, 03:59 PM   #16
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Should we file an "official" FR for midi/audio feedback detection separation?
EricM is offline   Reply With Quote
Old 06-29-2010, 04:05 PM   #17
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 22,639
Default

Quote:
Originally Posted by EricM View Post
Should we file an "official" FR for midi/audio feedback detection separation?
Yeah!
EvilDragon is online now   Reply With Quote
Old 06-29-2010, 04:19 PM   #18
-R-
Human being with feelings
 
-R-'s Avatar
 
Join Date: Mar 2010
Posts: 305
Default

I'll vote immediately. The dev's will only be happy to see that we care so much about their baby...
-R- is offline   Reply With Quote
Old 07-01-2010, 07:46 AM   #19
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default FR Text Proposal

Title
Separation of MIDI and audio feedback routing

Summary
Currently REAPER does not distinguish between MIDI and audio feedback
routing, but rather treats them as a single connection where MIDI or audio
can be filtered or not.

This is an issue as it does not allow users to manually set MIDI and audio
routing with VSTis using less tracks, which is reducing the efficiency of
already flexible routing capabilities. It also defeats the PDC when the routing
is actually not in feedback, which could be considered as a bug.

----------------

You guys have anything to add/change, or have in memory any relevant discussion
threads to put as reference? I think there was also a similar FR or bug on the tracker
already but searching through it I didn't find anything.

e
EricM is offline   Reply With Quote
Old 07-05-2010, 12:06 AM   #20
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

*bumpedeebump*
EricM is offline   Reply With Quote
Old 07-13-2010, 07:08 AM   #21
Dr.Gunjah
Human being with feelings
 
Join Date: Jun 2010
Posts: 38
Default

Quote:
Originally Posted by EricM View Post
Title
Separation of MIDI and audio feedback routing

Summary
Currently REAPER does not distinguish between MIDI and audio feedback
routing, but rather treats them as a single connection where MIDI or audio
can be filtered or not.

This is an issue as it does not allow users to manually set MIDI and audio
routing with VSTis using less tracks, which is reducing the efficiency of
already flexible routing capabilities. It also defeats the PDC when the routing
is actually not in feedback, which could be considered as a bug.

----------------

You guys have anything to add/change, or have in memory any relevant discussion
threads to put as reference? I think there was also a similar FR or bug on the tracker
already but searching through it I didn't find anything.

e
sounds very well, where can i vote?

this is also a good point, but IMO nice-to-have:
Quote:
And one more thing, if something is forbidden, not allowed, does not work, it's better to not let it happen and give the user information about it. When 'feedback routing' is disabled, users can still build audio-to-audio feedbacks between tracks, they will simply not work (and without warning).
Cheers,
Doc
Dr.Gunjah is offline   Reply With Quote
Old 07-13-2010, 07:15 AM   #22
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

I'll put it to issue tracker (than you will be able to vote), just need to
gather similar discussions issues links for reference to support the request.

e
EricM is offline   Reply With Quote
Old 07-13-2010, 09:14 AM   #23
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Here we go, the issue tracker:
http://forum.cockos.com/project.php?issueid=2722

e
EricM is offline   Reply With Quote
Old 07-13-2010, 09:28 AM   #24
plamuk
Human being with feelings
 
Join Date: Feb 2007
Posts: 3,221
Default

eric - thanks for your well organized attention to this issue.
plamuk is offline   Reply With Quote
Old 07-13-2010, 10:04 AM   #25
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by nym View Post
eric - thanks for your well organized attention to this issue.
Hope this will encourage the devs to consider the request, and I like to keep
stuff organized to a certain degree.

Just noticed that I poorly worded the summary in tracker, oh well...

e
EricM is offline   Reply With Quote
Old 07-17-2010, 01:22 AM   #26
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Bumping this up a bit, should probably be moved to FR forum?
EricM is offline   Reply With Quote
Old 08-09-2010, 10:31 PM   #27
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by EricM View Post
Bumping this up a bit, should probably be moved to FR forum?
one more bump
EricM is offline   Reply With Quote
Old 09-02-2010, 10:00 PM   #28
koolkeys
Human being with feelings
 
Join Date: Jul 2006
Posts: 952
Default

Bumpity!
koolkeys is offline   Reply With Quote
Old 04-21-2011, 09:29 AM   #29
Masarin
Human being with feelings
 
Masarin's Avatar
 
Join Date: Dec 2007
Location: Malmö, Sweden
Posts: 369
Default

Bumpette. Or will this be implemented in version 4?
__________________
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Skodak sounds @ http://skodak.bandcamp.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Masarin is offline   Reply With Quote
Old 04-28-2011, 01:00 PM   #30
Masarin
Human being with feelings
 
Masarin's Avatar
 
Join Date: Dec 2007
Location: Malmö, Sweden
Posts: 369
Default

Bumppp.
__________________
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Skodak sounds @ http://skodak.bandcamp.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Masarin is offline   Reply With Quote
Old 05-19-2011, 02:28 AM   #31
musicbynumbers
Human being with feelings
 
musicbynumbers's Avatar
 
Join Date: Jun 2009
Location: brighton, uk
Posts: 12,602
Default

Bump
musicbynumbers is offline   Reply With Quote
Old 10-26-2011, 02:15 AM   #32
matthias.matthias
Human being with feelings
 
Join Date: Jun 2010
Posts: 166
Default

Bump.

Also, I was wondering whether or not this should be considered a bug instead of a feature request. I don't see why feedback routing has to be enabled in the first place when routing mid form a to b and audio from b to a. Also the priority seems somewhat low to me.

Flexible routing is actually one of Reapers strongholds. I hope we get this fixed some time soon. Working with multi-out vstis and automating them is simply convoluted at the moment.
matthias.matthias is offline   Reply With Quote
Old 10-26-2011, 02:26 AM   #33
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by matthias.matthias View Post
Also, I was wondering whether or not this should be considered a bug instead of a feature request. I don't see why feedback routing has to be enabled in the first place when routing mid form a to b and audio from b to a.
In most such cases it's just a matter of missing feature,
as in the original design not having such broad/flexible
intent.

So yeah, it could be called a bug in the design, but not
in actual software - because it works as designed

e
__________________
Shoelace 4 Theme | SoundCloud/erXon
EricM is offline   Reply With Quote
Old 10-26-2011, 02:56 AM   #34
rictus
Human being with feelings
 
Join Date: Dec 2010
Posts: 226
Default

Here's my problem with what you guys are proposing (that audio A>B and MIDI B>A should not be considered feedback):

Imagine track A has a VSTi on it, and track B has an audio-to-MIDI plug on it. Now, whenever our VSTi plays a note, it gets sent to B, where it's converted to MIDI, which gets sent to A, which triggers a note, which sends audio to B, where it's converted to MIDI, which gets sent to A...

I can't think of a reliable way to allow what you lot are proposing while precluding stuff like this happening - after all, how is Reaper supposed to know when a plugin is capable of producing MIDI output from audio input?

Feedback routings are just a bad idea in 99% of cases. Just make extra tracks, and use the track manager to hide those you do not wish to see in arrange view or the mixer.
rictus is offline   Reply With Quote
Old 10-26-2011, 03:07 AM   #35
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by rictus View Post
Here's my problem with what you guys are proposing (that audio A>B and MIDI B>A should not be considered feedback):

Imagine track A has a VSTi on it, and track B has an audio-to-MIDI plug on it. Now, whenever our VSTi plays a note, it gets sent to B, where it's converted to MIDI, which gets sent to A, which triggers a note, which sends audio to B, where it's converted to MIDI, which gets sent to A..
That would be a rare case scenario and a user-error, like putting a mic to speaker.
It's the engineer's job to avoid such errors, if such configuration is used.

e
__________________
Shoelace 4 Theme | SoundCloud/erXon
EricM is offline   Reply With Quote
Old 10-30-2011, 02:39 AM   #36
matthias.matthias
Human being with feelings
 
Join Date: Jun 2010
Posts: 166
Default

Quote:
Originally Posted by rictus View Post
Feedback routings are just a bad idea in 99% of cases.
You're right, but there is no feedback in what we're asking for. It's only that Reaper considers it to be feedback, hence the FR.

Take a look at the way Pro Tools, Studio One or Samplitude handle mulit-out VSTis. In all of them it is possible to route the audio from the VSTi to the track with the MIDI data on it. I attached a screenshot from a tutorial for Samplitude, there you can choose how you want the multi-outs to be handled. Both is possible, the one-track approach that I prefer, but also the two-track method. The same is true for Pro Tools, though you have to set it up yourself, there is no assistant helping you. (I'm really not saying this in the "Every other DAW has it"-mood, I only want to show you what's possible).


Quote:
Originally Posted by rictus View Post
Just make extra tracks, and use the track manager to hide those you do not wish to see in arrange view or the mixer.
Like I said before in other threads, the main problem with the two-track approach is in automating parameters on the audio track. Firstly you can't hide the tracks in the TCP if you want to edit the automation (meaning unnecessary screen clutter), secondly when moving or copying the MIDI items, the automation won't follow, because it's on another track. I use dummy MIDI items on the audio track as work around, but I find that approach somewhat convoluted.


Quote:
Originally Posted by EricM View Post
That would be a rare case scenario and a user-error, like putting a mic to speaker.
It's the engineer's job to avoid such errors, if such configuration is used.
+1
Attached Images
File Type: jpg MultioutVSTis_in_Samplitude.jpg (46.8 KB, 169 views)
matthias.matthias is offline   Reply With Quote
Old 01-11-2012, 04:19 AM   #37
Reaktor:[Dave]
Human being with feelings
 
Reaktor:[Dave]'s Avatar
 
Join Date: Jun 2010
Location: Berlin
Posts: 451
Default

Greath thread!! Any news on this?

Quote:
Originally Posted by matthias.matthias View Post
Like I said before in other threads, the main problem with the two-track approach is in automating parameters on the audio track. Firstly you can't hide the tracks in the TCP if you want to edit the automation (meaning unnecessary screen clutter), secondly when moving or copying the MIDI items, the automation won't follow, because it's on another track. I use dummy MIDI items on the audio track as work around, but I find that approach somewhat convoluted.
So true! Mixing Multi-Out-VSTis is quite cluttered, when you can't route audio back to its midi track.

Last edited by Reaktor:[Dave]; 01-20-2012 at 01:06 AM.
Reaktor:[Dave] is offline   Reply With Quote
Old 02-04-2012, 11:53 PM   #38
Coises
Human being with feelings
 
Coises's Avatar
 
Join Date: Jan 2011
Location: Las Vegas, Nevada, USA
Posts: 28
Default

Quote:
Originally Posted by rictus View Post
Here's my problem with what you guys are proposing (that audio A>B and MIDI B>A should not be considered feedback):

Imagine track A has a VSTi on it, and track B has an audio-to-MIDI plug on it. Now, whenever our VSTi plays a note, it gets sent to B, where it's converted to MIDI, which gets sent to A, which triggers a note, which sends audio to B, where it's converted to MIDI, which gets sent to A...

I can't think of a reliable way to allow what you lot are proposing while precluding stuff like this happening - after all, how is Reaper supposed to know when a plugin is capable of producing MIDI output from audio input?
The bit about disabling plugin delay compensation is what troubles me... it implies that not allowing feedback routing is doing more than just protecting the user from making dumb mistakes, it’s solving a coding problem... even if the audio/MIDI doesn’t actually loop, the internal PDC calculations don’t work when the topology looks like a loop.

But I think there is a way this could be managed without too much inconvenience (certainly less than having to have two tracks for every one instrument supported by a single instance of a multi-timbral VSTi):

For tracks that send MIDI and receive audio, have a “pseudo-effect” that can be placed in the effects chain to indicate where MIDI is sent and audio is received. Effects before this point in the chain do not receive audio from other tracks; effects after this point in the chain do not affect MIDI that is sent to other tracks.

When feedback routing is not allowed, if there is no MIDI-send-Audio-receive pseudo-effect in a track which sends MIDI and receives audio and is part of a potential feedback loop, a send/receive point before all effects is assumed in that track. (In the routing setup discussed in this thread, that means you only have to use the pseudo-effect when you have MIDI-processing plugins on a “child” track that need to affect the recorded MIDI before it is sent to the VSTi. Since the send/receive point is only assumed in tracks that are part of a loop that would now be inhibited, nothing that works now would be broken.)

If the explicit and implicit MIDI-send-Audio-receive breaks described above are insufficient to break the loop, then it is still a loop and is inhibited the same as it is now.

I think that would work to break potential feedback loops in the situations that matter. The question, which I can’t answer, is whether it would also solve whatever programming logic problem makes Reaper have to disable PDC when feedback routing is permitted.
Coises is offline   Reply With Quote
Old 02-05-2012, 12:43 AM   #39
EricM
Human being with feelings
 
EricM's Avatar
 
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
Default

Quote:
Originally Posted by Coises View Post
The question, which I can’t answer, is whether it would also solve whatever programming logic problem makes Reaper have to disable PDC when feedback routing is permitted.
It gets 'broken' because in each loop a minimal
delay is added to prevent converging latency.
Which is ok for the feedback effect purposes.

What this FR requests is recognizing when there
is no actual feedback (as there is different types
of data being sent back and forth), and thus the
delay to prevent converging latency should not
be applied. Effectively, PDC would still work
properly on such routing.

e
__________________
Shoelace 4 Theme | SoundCloud/erXon
EricM is offline   Reply With Quote
Old 02-05-2012, 12:00 PM   #40
Coises
Human being with feelings
 
Coises's Avatar
 
Join Date: Jan 2011
Location: Las Vegas, Nevada, USA
Posts: 28
Default

Quote:
Originally Posted by EricM View Post
It gets 'broken' because in each loop a minimal
delay is added to prevent converging latency.
Which is ok for the feedback effect purposes.

What this FR requests is recognizing when there
is no actual feedback (as there is different types
of data being sent back and forth), and thus the
delay to prevent converging latency should not
be applied. Effectively, PDC would still work
properly on such routing.
I don’t know what “converging latency” means. I understand, though, if it’s too complex to explain here.

I think I do understand the problem rictus raises, though. Many VSTs which are purely audio effects also accept MIDI input for parameter control; they typically pass the MIDI through (so other effects can use it also), so they have a MIDI out. If there are any such effects on the send-MIDI-receive-Audio track, how could REAPER tell that there isn’t a “real” loop? How could it know that none of those effects will use the Audio received from the VSTi track to influence the MIDI sent to the VSTi track? (Granted, there’s no problem if there are no effects on the send-MIDI-receive-Audio track, but typically there would be... that’s part of why one would care to divide the output of a multi-timbral VSTi among separate tracks!)

Does the inability to determine this somehow not elicit the “converging latency” problem?

Of course, if simply assuming that no effects in a track that is part of a loop (as currently recognized) produce MIDI output contingent on audio input is sufficient to resolve the problem, that would be good enough, as such effects are quite rare. Users would simply have to accept the restriction that effects which actually do produce MIDI from audio won’t function as expected in a context that “looks like” a loop.
Coises is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 09:39 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.