|
|
|
08-09-2009, 07:29 AM
|
#1
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
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
|
|
|
08-09-2009, 07:53 AM
|
#2
|
Moderator
Join Date: Aug 2007
Location: Italy
Posts: 4,327
|
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
|
|
|
08-09-2009, 08:55 AM
|
#3
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
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:
|
|
|
08-09-2009, 10:17 AM
|
#4
|
Moderator
Join Date: Aug 2007
Location: Caracas, Venezuela
Posts: 8,687
|
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
|
|
|
08-09-2009, 10:20 AM
|
#5
|
Moderator
Join Date: Aug 2007
Location: Italy
Posts: 4,327
|
Shouldn't PDC take care of the latency and compensate (provided it's not live input but input coming from track events)?
- Mario
|
|
|
08-09-2009, 10:25 AM
|
#6
|
Administrator
Join Date: Mar 2007
Location: NY
Posts: 15,821
|
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.
|
|
|
08-09-2009, 10:34 AM
|
#7
|
Moderator
Join Date: Aug 2007
Location: Italy
Posts: 4,327
|
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
|
|
|
08-09-2009, 10:35 AM
|
#8
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by schwa
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.
|
|
|
08-09-2009, 11:02 AM
|
#9
|
-blänk-
Join Date: Jun 2008
Posts: 11,359
|
Quote:
Originally Posted by mabian
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
|
|
|
05-10-2010, 09:43 AM
|
#10
|
Human being with feelings
Join Date: Oct 2006
Location: Greece
Posts: 3,554
|
[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).
|
|
|
05-10-2010, 10:01 AM
|
#11
|
Human being with feelings
Join Date: Jan 2009
Location: frankonia
Posts: 1,996
|
Maybe PDC gehts hampered when there is audio and MIDI on that track?
__________________
------------------------------------------
Don't read this sentence to it's end, please.
|
|
|
05-14-2010, 01:31 PM
|
#12
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by Evan
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.
|
|
|
06-29-2010, 12:58 PM
|
#13
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
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.
|
|
|
06-29-2010, 01:43 PM
|
#14
|
Human being with feelings
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,109
|
Quote:
Originally Posted by EvilDragon
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.
|
|
|
06-29-2010, 03:58 PM
|
#15
|
Human being with feelings
Join Date: Mar 2010
Posts: 305
|
+1 and +1
|
|
|
06-29-2010, 03:59 PM
|
#16
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Should we file an "official" FR for midi/audio feedback detection separation?
|
|
|
06-29-2010, 04:05 PM
|
#17
|
Human being with feelings
Join Date: Jun 2009
Location: Croatia
Posts: 24,798
|
Quote:
Originally Posted by EricM
Should we file an "official" FR for midi/audio feedback detection separation?
|
Yeah!
|
|
|
06-29-2010, 04:19 PM
|
#18
|
Human being with feelings
Join Date: Mar 2010
Posts: 305
|
I'll vote immediately. The dev's will only be happy to see that we care so much about their baby...
|
|
|
07-01-2010, 07:46 AM
|
#19
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
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
|
|
|
07-05-2010, 12:06 AM
|
#20
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
*bumpedeebump*
|
|
|
07-13-2010, 07:08 AM
|
#21
|
Human being with feelings
Join Date: Jun 2010
Posts: 38
|
Quote:
Originally Posted by EricM
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
|
|
|
07-13-2010, 07:15 AM
|
#22
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
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
|
|
|
07-13-2010, 09:14 AM
|
#23
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
|
|
|
07-13-2010, 09:28 AM
|
#24
|
Human being with feelings
Join Date: Feb 2007
Posts: 3,221
|
eric - thanks for your well organized attention to this issue.
|
|
|
07-13-2010, 10:04 AM
|
#25
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by nym
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
|
|
|
07-17-2010, 01:22 AM
|
#26
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Bumping this up a bit, should probably be moved to FR forum?
|
|
|
08-09-2010, 10:31 PM
|
#27
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by EricM
Bumping this up a bit, should probably be moved to FR forum?
|
one more bump
|
|
|
09-02-2010, 10:00 PM
|
#28
|
Human being with feelings
Join Date: Jul 2006
Posts: 952
|
Bumpity!
|
|
|
04-21-2011, 09:29 AM
|
#29
|
Human being with feelings
Join Date: Dec 2007
Location: Malmö, Sweden
Posts: 369
|
Bumpette. Or will this be implemented in version 4?
|
|
|
04-28-2011, 01:00 PM
|
#30
|
Human being with feelings
Join Date: Dec 2007
Location: Malmö, Sweden
Posts: 369
|
Bumppp.
|
|
|
05-19-2011, 02:28 AM
|
#31
|
Human being with feelings
Join Date: Jun 2009
Location: South, UK
Posts: 14,218
|
Bump
|
|
|
10-26-2011, 02:15 AM
|
#32
|
Human being with feelings
Join Date: Jun 2010
Posts: 194
|
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.
|
|
|
10-26-2011, 02:26 AM
|
#33
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by matthias.matthias
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
|
|
|
10-26-2011, 02:56 AM
|
#34
|
Human being with feelings
Join Date: Dec 2010
Posts: 226
|
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.
|
|
|
10-26-2011, 03:07 AM
|
#35
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by rictus
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
|
|
|
10-30-2011, 02:39 AM
|
#36
|
Human being with feelings
Join Date: Jun 2010
Posts: 194
|
Quote:
Originally Posted by rictus
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
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
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
|
|
|
01-11-2012, 04:19 AM
|
#37
|
Human being with feelings
Join Date: Jun 2010
Location: Berlin
Posts: 563
|
Greath thread!! Any news on this?
Quote:
Originally Posted by matthias.matthias
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.
|
|
|
02-04-2012, 11:53 PM
|
#38
|
Human being with feelings
Join Date: Jan 2011
Location: Maricopa, Arizona, USA
Posts: 28
|
Quote:
Originally Posted by rictus
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.
|
|
|
02-05-2012, 12:43 AM
|
#39
|
Human being with feelings
Join Date: Jul 2009
Location: Ljubljana, Slovenia
Posts: 3,801
|
Quote:
Originally Posted by Coises
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
|
|
|
02-05-2012, 12:00 PM
|
#40
|
Human being with feelings
Join Date: Jan 2011
Location: Maricopa, Arizona, USA
Posts: 28
|
Quote:
Originally Posted by EricM
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.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 04:19 PM.
|