As this limitation is neither documented, nor does there seem to be any a priori reason for it to exist, I believe that this is a bug.
A Doofer is supposed to be self contained and exchangeable, so it does make sense to not allow those. Just imagine saving it and giving it to another user, he might not have the target send channel at all or use it for something different. Allowing some kind of internal Doofer routing is a whole other topic at some point.
A Doofer is supposed to be self contained and exchangeable, so it does make sense to not allow those. Just imagine saving it and giving it to another user, he might not have the target send channel at all or use it for something different. Allowing some kind of internal Doofer routing is a whole other topic at some point.
Well, I can also create an instrument in which I route the FX chain to track 77, which the user might not have either 
It’s a shame the paradigm of sharing stuff has limited renoise in so many areas, especially considering the (sad) reality of how much stuff is shared.
It almost seems that renoise has got to a point where the answer to any request is:
a) use doofers
b) use phrases
c) code it yourself with tools
d) it is incompatible with sharing therefore not possible
It’s a shame the paradigm of sharing stuff has limited renoise in so many areas, especially considering the (sad) reality of how much stuff is shared.
Well, then go ahead and share something 
I don’t think “limitations” of whatever preset format is the real problem here.
If it’s about solving this problem here:https://forum.renoise.com/t/multi-send/44962 : adding 3 send devices in a row in a song that you are currently working on really isn’t stopping you of realizing your musical ideas.
Don’t forget
e) Not compatible with Tracker history
f) Other DAWs do that already, Renoise is different on purpose
But jokes aside, I think that the limitations actually prevent the sharing. I mean the is probably a reason why we don’t see any Renoise/Redux libraries from third party companies. Which is a pity because Renoise and Redux could be so amazingly powerful with just some minor adjustments.
On the other hand, the new beta is already a step into the right direction of course.
There are other topics talking about doofers + sends:
https://forum.renoise.com/t/dest-out-macro-on-doofer/40110
https://forum.renoise.com/t/for-3-0-1-please-allow-send-device-in-a-doofer/41893
IMO: much more in the spirit of the self-contained Doofer device would be internal sends (parallel processing).
https://forum.renoise.com/t/more-dsp-control-audio-splitter/44617
But jokes aside, I think that the limitations actually prevent the sharing. I mean the is probably a reason why we don’t see any Renoise/Redux libraries from third party companies.
Wouldn’t be profitable. It takes a lot of time to do good presets that make use of the features of, well, any audio software really.
As a content creator, I would definitely see Renoise/Redux as a niche product.
That said, sharing is important to us all. It’s a part of the scene spirit and the motivation for setting up the downloads server.
Right now, 32 Doofers and counting…with parallel processing, I’m sure it would even more.
Not profitable? What was all that talk during 3.0 beta testing about being in contact with several companies already and them showing great interest? Wasn’t that one of the main arguments for the back then controversy discussed modulation system? (Please correct me if I am wrong, but this is how I remember it. Bit_arts and others trying to state that you will not find third party interest for libraries with this system, and some one from the team stating that there already is interest and talk about that).
Anyway, my point was basically the same as yours, Redux is indeed niche at the moment. I, however, believe this is mainly due to the limitations or missing basic sampling features (and with basic, I mean things people are used to from samplers since the 80s).
As I said, the potential of Renoise and Redux on the sampling side is enormously huge! For tracker geeks and more traditional sampling enthusiasts alike.
And I also agree with you about parallel processing.
On a side note: I was actually intending to open a new topic to ask this, but since we are at it anyway, are there any plans to release a standalone VST (effect) of the doofer? With all the internal Renoise devices to use in there? Kinda seems like a logical next step after releasing the sampler as a standalone VSTi. I could see people being interested in this, especially when parallel processing will be added and people can create and share rather complex doofers to be quickly used within a project.
I totally disagree with beatslaughter and agree with fladd and meef.
Since instruments now can contain non exchangeable routing,too,
Doofers should be able of contain send and multiband sends!!!
IF YOU DONT LIKE IT, JUST DONT ADD A SEND DEVICE TO YOUR DOOFER! But let us others enjoy this nice workflow improvement.
Btw: Those “limitations” are not applied when using track FX chains, so you can use them in such cases instead.
Not profitable? What was all that talk during 3.0 beta testing about being in contact with several companies already and them showing great interest? Wasn’t that one of the main arguments for the back then controversy discussed modulation system? (Please correct me if I am wrong, but this is how I remember it. Bit_arts and others trying to state that you will not find third party interest for libraries with this system, and some one from the team stating that there already is interest and talk about that).
Indeed there was, and still is. A lot of companies have great sample libraries to offer, and when a new sampler appears it’s only natural to publish for that format as well. Basically, publishing the same content to a number of different formats. Heck, with Renoise this can even be completely automated, so basically 0% effort once the groundwork is done.
But - and that was my point - it’s an entirely different thing to actually take advantage of the platform you are creating sound design for. So, producing for a niche platform not only takes a lot of time, it requires expert knowledge and this is simply not something you’d see most providers of sounds having, at least not in-house.
And yes, I remember that modulation discussion with Bit Artswell enough to recall that I basically argued that, in my opinion, we should not make a design which would sacrifice the abilities of the modulation system just to gain a somewhat more efficient workflow.
Thanks for your answers guys.
Taktik, I would argue that not being able to use FX chains due to the consequences of using them IS the limitation. Also, this limitation is only part of what I think keeps Renoise/Redux in its niche. I have brought up the other issues several times already in this forum, so I will not repeat them here.
Danoise, I understand what you mean. Companies will not make use of Renoise-specific features in the instruments. I agree with your there. My point was rather that those companies could, however, make use of (sorry that I have to use that word again, but I honestly don’t know how else to call them ) “standard” sampler features to bring their, let’s say Kontakt/ESX24/Akai/whatever libraries to Renoise/Redux as well. The reason that this is not happening (and even more so, that the one company that did make Renoise instruments stopped doing them, due to limitations of the format!) makes me think whether it would be beneficial to offer more of those “standard” features so companies will jump on board. And who knows, maybe once they are on board they start to dig the Renoise specific stuff as well!
As usual, please don’t view this as a rant or something. I am actually trying to be constructive here.