View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006924 | ardour | features | public | 2016-07-15 23:54 | 2016-07-30 15:29 |
| Reporter | _FrnchFrgg_ | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Platform | Debian | OS | Linux | OS Version | 4.6.2 |
| Product Version | 5.0-pre | ||||
| Summary | 0006924: Make inserts able to send and receive from the same Ardour track | ||||
| Description | Currently such a flow is detected as feedback by ardour, but it is legit. This bug is for not forgetting that I want to enable that flow one day. | ||||
| Tags | No tags attached. | ||||
|
|
Partially implemented in Ardour 5.0-pre0-688-g19a9d84 Inserts can connect to self (their own return). Inserts can not yet connect to another insert later on the same track. |
|
|
Reading the commit, I see that it indeed allows an insert to connect to itself. But it is not very useful (nor is the possibility to connect to a later insert on the same track, thus bypassing all processors inbetween). What I think would be more useful and harder to do is to allow the following case: - Track1 has an insert - that insert's send connects to the input of Bus1 - the insert's return is connected to the output of Bus1 That would basically enable a bus to act as a "group of processors". On IRC I have been told that because track/busses do all their processing in one single pass, such a signal flow would incur a 1-cycle latency. I didn't understand why that would involve a delayline because you cannot edit pin connections of an insert and thus there's no need to "align" channels that are received from the insert with those that come from above the insert. (Or maybe if an insert return gets some channels from tracks that already roll()ed or no_roll()ed, and some from tracks that are later in the execution order, you'd want to align them all ?) |
|
|
The workflow you propose "sub-group" busses is better done using an actual bus and move the post-return effects there. no return. The schema with return from bus would only work only if the bus is exclusively use by track1 -- in which case you might just as well inline the effects on the track itself. I suppose I'll best revert that commit. Self-connect can be useful to e.g. cross connext 1 -> 2, 2-> 1 or simply bypass 1 channel unmodified. My mind was still stuck in pre pin-magement ideas where we considered using sends to map ports. |
|
|
I'm not saying it is that useful, but for now the error is confusing, because it is not feedback in the audio sense... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-07-15 23:54 | _FrnchFrgg_ | New Issue | |
| 2016-07-16 02:15 | x42 | Note Added: 0018301 | |
| 2016-07-16 10:40 | _FrnchFrgg_ | Note Added: 0018303 | |
| 2016-07-17 00:27 | x42 | Note Added: 0018306 | |
| 2016-07-30 15:02 | _FrnchFrgg_ | Severity | minor => feature |
| 2016-07-30 15:29 | _FrnchFrgg_ | Note Added: 0018336 |
