grough
commented
1 year ago Hi @terrytheplatypus, I made some changes to the feedback path that might be closer to what you're describing, but I still don't think it entirely satisfies your requirement. The send/return behaviour has been made to work the same as other popular loopers and delays in the library that feature a feedback insert path. If you need something substantially different from that, you will probably need to maintain your own fork.
Note that there will be a "Feedback Expander" module (pictured below) included with the next Rack library update, which might make looper two obsolete for you. Looper two will still be included in the development builds.
i know loopertwo is a wip but i had some things i would personally change about the send/return. i'm assuming the audio from the send-return not playing until the next loop is just a bug that was intended to be fixed at some point, but to me, i feel like it would be more useful for the send-return fx loop to always be audible, and the toggle would just be for whether the fx get printed to the loop. it didn't seem like that was the intent of that button as is. it also seems like the way it currently behaves is as a delay thing where the dry signal is mixed with the wet signal, when i would be expecting that it's fully the "wet" signal.
edit: i thought about this a bit more and to implement the behavior i'm thinking of, it seems like the looper then would have to write one step earlier in the vector, for the one-sample delay from the send/return.
edit 2: i completed a initial working version of the behavior i described above, i may make a pull request soon. if it diverges too much from your intended behavior i can fork it as a separate plugin.