Feedback in an audio workstation can really be a wild ride. It gets out of hand fast, but it usually isn't dangerous or even that offensive if safeguards are implemented. My apologies for beating a horse I'm told is long dead; I know feedback in FL's routing can be a touchy subject here sometimes. I've done some digging and experimentation with other DAWs, and Image line's own minihost inside of FL, and I've come away with some thoughts on the matter. I would like to address the drawbacks and concerns Reflex and perhaps others have had about feedback loops in FL Studio and patcher, and have a dialogue with anyone at Image Line curious about making this vast world of sound design and routing flexibility happen someday. I must apologize to reflex personally for this thread.
I've given them the most headache over this topic, and recently said I wouldn't nagg them about it, as a grateful courtesy for answering questions on a closely related topic in another thread. I fear this is the greatest, hopefully most cordial "nagg" of all. I don't mean to be such a bother over this, but I'm not really willing to let it rest either, as I fear too much is missed by continuing to disallow feedback producing routing setups in the mixer. I'm going to bring up points made against feedback loops, like technical challenges and the obvious safety concern, and respond to them individually. Hopefully by the end of this, feedback won't be such a taboo topic -- at least in this thread -- and maybe in the coming years, it can be a celebrated feature of the DAW; a testament to its open ended flexibility. The goal of this post is to preemptively quell any concerns about feedback in the routing, and to have a discussion with the developers about the technical challenges and any concerns they might have about adding something as seemingly useless and hazardous as optional feedback loops in FL Studio's routing.
Quote sourced from: viewtopic.php?f=100&t=176647&p=1311905& ... p#p1311620reflex wrote:I specifically chose not to allow feedback because it would be too easy to create a feedback loop and blow up speakers or ears.
It might be added at some point in the future, but it would have at least one processing block latency. Because FL uses variable sized buffers, that latency would not be constant, by default (I think). And I think that would also cause problems if a small processing block was followed by a longer one ... there wouldn't be enough data to fill the new buffer, so there would be random silence.
Right, I'm going to address the points brought up here, as well as one he didn't mention. A consequence of fixed buffers on automation responsiveness.
Ears and speakers. This is a very real concern. Overloads are no joke sometimes. But in a digital environment like FL, we have several options for mitigating this danger. Reaper's solution is to mute outputs that exceed a user specified threshold. This way no matter where the feedback is coming from, if you clip this threshold, audio output is muted for a short time until you work out where the problem is using the meters, and the signal level drops below the threshold. Of course, sometimes you want to use hardware outputs for feedback, so this threshold can be raised well above 0db if you need it. There are other measures in place as well. By default, feedback is turned off, and needs to be enabled in the settings menu. A similar and arguably even better, if slightly more annoying system, exists in Ableton live. Ableton requires you to individually enable feedback on its return tracks before allowing one to be created. One does this by right clicking the potentially dangerous send knobs on a return track and choosing "enable send." Seems a sensible thing to do, requiring you to consciously chose to create any feedback loop you add. Sure, there are ways to create feedback in Ableton without any warning at all by using the mixer's routing, or auditioning a plugin's sidechain input. But that's where auto muting, or ensuring there is a limiter on all of your output channels comes in handy. And let's be honest; FL is full of plugins that will give you and your speakers a fright. Delay bank and delay three both produce screaming feedback with high filter resonance. Love philter's "mango low-pass" self oscillates quite loudly. And Hardcore opens with an insanely loud preset by default. The potential for frights is still very much alive in FL, even without feedback. The solutions above will keep all of these from damaging equipment.
FL's variable buffers will cause crackling in a feedback loop The next point against feedback in FL is a bit more solid, but I think it can be overcome too. Reflex is right about the variable buffer size being a problem. Create a feedback loop in Minihost modular, and the sound is garbled and crackly. Switching the plugin wrapper option "use fixed-size buffers," solves the problem entirely. Replacing the crackling mess with the comb filter-esque ringing you'd expect from digital feedback. This is honestly all I could realistically ask for from Image line; to switch any plugins on a track (or a thread in patcher) involved in feedback routing to a form of fixed buffer size. (smaller would be better, if possible. More on that and why I think its possible further down.) This does introduce delay, and that's fine. So do other DAWs. The original signal will be unaffected by this problem, thanks to PDC; so only the feedback will be out of sync with the project, and for the most part, this isn't a problem.
The expense is latency As Reflex said, a block's worth of latency or thereabout will be introduced for every plugin added to the loop. A feedback loop with no processing, just idle plugins, will sound more and more like a delay with high feedback for every plugin added. Now, let me take the opportunity to point out every DAW I've ever used to create feedback in its routing behaves this way. So FL doing it too wouldn't be a problem for me at all, provided we discuss a few things first. At this point, it might be good to refer everyone to this section of the manual on fixed buffer sizes and the related options, as they are necessary for proper feedback in FL, and will help some understand my arguments later.
This delay I mentioned above can be a problem, but how big of a problem depends on the size of the buffer being used for the plugins in the feedback loop. I'm just guessing here, but It seems FL can use buffers of any length it feels is appropriate. Anywhere from a few samples, to a few thousand samples. Indeed, variable buffer sizes by default would seem to validate this idea. The fixed size used by default is 2 milliseconds. But it can get much shorter. If you select the option "process maximum size buffers", and switch your ASIO buffer as low as it will go. Setting this up with minihost modular, with FL's default 2ms fixed buffer, the ringing sound was equivalent to setting up a delay of 2-2.4 milliseconds, with feedback near unity. I reckon FL and plugins can do fixed buffers of 1ms or even less. I was able to get my setup with minihost to feedback with a round trip delay of about 1.48 ms (based on comparisons with a ringing delay line) with an ASIO buffer of 64 samples, using the "process maximum size buffers" option. So, if FL did have an option for fixed buffer sizes to be used in audio feedback loops, and given that most plugins can probably run comfortably with a much smaller fixed buffer than 2ms, I think it would be useful to have a few options for the size of the buffer FL chooses to use in this scenario. The default setting can be 2ms, with "Process maximum size buffers from host." Or it could be lower. This way we could compromise between a fast feedback loop with tighter automation; or greater plugin stability, lower resolution automation, and more of a delayed sound in the feedback loop. But if that's too much to expect, just adding the fixed buffer size options from the VST wrapper to FL native plugins would be enough. Easily comparable to the systems used in other DAWsFL Studio Manual wrote:Use fixed size buffers - This option can be useful in fixing rendering errors such as glitching and or timing issues. FL Studio shares data with plugins using variable sized chunks of data (buffers). Some plugins require fixed sized buffers (the VST spec allows hosts to use variable size buffers, but no-one cares about specifications it seems, so we provide this format since FL Studio uses variable sized buffers). If the additional options are both off (see below) the fixed buffer size option uses 2 ms. The disadvantage is that fixed size buffering can introduce an extra delay, depending on the audio buffer size selected in the Audio settings (F10). This delay is doubled for effects plugins. However, in some cases this setting may fix unwanted rendering delays and/or audio glitches caused by some plugins. Options:
These two options are only to be used if the default 2 ms 'Fixed sized buffers' does not work. In general, both these options should be off.Process maximum size buffers - FL Studio block size is used as the fixed buffer size, the block size is the maximum processing size, as determined by FL Studio itself. NOTE: The block size is typically a much bigger than the processing buffer size, leading to even bigger latency.
Use maximum buffer size from host - Same as the above but the plugin is also informed of the block size being used by FL Studio. A few plugins can make use of this data to synchronize their processing.
Fixed buffer sizes really do lower the effective automation resolution for VST plugins. This is the other "expense" of fixed buffer sizes, and the primary reason I asked that the fixed buffer size be as small as possible. I was a bit blown away by this, but it is true. Using fixed buffers really does effectively limit the PPQ for the plugin using them. So fast modulation of a parameter becomes nearly impossible. The default 2ms buffer when using fixed-size buffers effectively limits you to a PPQ of 96 or thereabout. Fine for slower modulation, but anything faster will start to exhibit the "digital chirping" -- parameters suddenly and audibly skipping between values as they are unable to keep up with the automation. This can be made better with smaller buffers, which can be done in the existing system by using "process maximum size buffers" and setting your ASIO buffer length as low as you can get it. It is for this reason that I believe a few fixed buffer sizes are possible options for FL's wrapper. I would strongly encourage a wrapper option to use buffer sizes smaller than 2 milliseconds. Provided this won't break the DAW. My tests tell me a little smaller won't break it too badly anyway.
Final thoughts: So, there we have it. Feedback seems a perfectly attainable feature for FL, and it isn't as wild and reckless as previously feared. If safeguards are implemented, like needing to activate it per mixer track, per patcher patch, and even again in the general settings; and a function to automatically mute any output if the signal exceeds a user specified level -- with a sensible and safe default -- then I think feedback in the mixer and patcher would be a useful tool to have. I've rambled on too long in this post, so I won't go into the many things we could set up with feedback in the routing. Suffice to say, there are a lot of interesting effects one can achieve using feedback, delays, pitch/frequency shifters, distortion, filter banks, gates, reverbs, ring modulators. . . the list goes on. The latency and comb filtering feedback would impart on the signal is par for the curse in the digital domain, so FL needn't be concerned very much with avoiding it for now. So, if this isn't too unreasonable, I'd like to have a dialogue with someone about this feature. It doesn't have to be made a priority, I'd just like to see it placed somewhere realistic on the ToDo list. A "We're working on this, give us an 'Image Line minute,' " sort of situation. I would be very grateful to hear from someone at Image Line about this topic. "Feedback on my arguments for feedback," if you will. I'm not a developer, of curse, but please; discuss with me about the challenges and things I haven't thought of yet. I'd really like to see what can be done about this.