I doubt there are going to be many cases where the feature in question is “Override development decision? Y/N”
If there were, maybe it would be worth the trouble, but the signal-follower thing is the only one I can think of. There are other ways to handle the signal follower thing. Even just a popup saying “Warning! Attaching the signal follower to a device preceding it on a dsp chain increases latency!” would be sufficient IMO.
How is “make it configurable, and set X as default” not a development decision?
If it’s configurable, why not make it configurable in the UI? Having users messing with config files in the background sucks. If a feature is worth having it’s worth exposing in the UI. In my opinion.
because easier, quicker, simpler
because you can still make it GUI configurable later… you could leave that to assistants even.
I feel like I’m feeding a troll at this point though.
Exposing a hardcoded value to a config file is not adding a new feature.
(if_track_is_before_current_track)
nah, you may not
(if_track_is_before_current_track AND !hardcore_config__allow_messy_routing)
nah, you may not
that’s not a big thing to do. and yeah, I’m kinda talking outta my ass here, but much less so than you.
First you say “expose it to the API because that takes less work”, when I point out that the opposite is true you not just ignore that, you simply say “but why not then make it GUI configurable”. I mean, wtf. I’m outta here. Power users of the world, unite.
The real problem with this idea is that someone has to maintain all this garbage.
The developer to user ratio isn’t 1:1
You seem to have had bad experiences with shitty code. My condolences.
I never said it would be easier to expose it in the UI, I said that if the feature is worth the trouble of implementing then it’s worth the additional trouble of exposing in the UI.
I don’t see where any of this is referring to hardcoded values in the code. These aren’t bits that are just waiting to be flipped by a config file, to my knowledge. Is “ALLOW_MESSY_ROUTING = N” in the code somewhere? I doubt that very much.
You say that as if I claimed you did… which I didn’t. Huh.
Oh come on, you know what I mean. Of course it will require some code, but it’s STILL not what you claim it is, “adding new features”. It just means inserting conditionals that refer to variables read from the config and doing stuff slightly different.
Maintaining this stuff is usually a problem because this stuff is touched in the background to make a program completely personal.
Completely personal means that with each update, stuff in there can get broken very easily without the developer knowing.
You will then have a lot of nitpicking bug reports that keep the developer from fixing the more serious problems.
So a power-user config sounds nice, but breaks the bond between user and developer since you then have parallel environments that respond differently to updates. A lot of clutter without having a good overview of which does what as soon as stuff gets tweaked to behave differently from what is basic.
That is what Conner tries to say by “garbage”. I think “mess” would have been a more appropriate word.
What you’re describing is spaghetti code, not a fundamental problem of making something configurable? If you code it correctly, why would it break if you add/change other stuff later on… if it does, that means there is bugs/wrong assumptions in the code.
Plus, that reeeeeally depends on what kinds of options we’re talking about.
So far we have one example, the signal following device. None of the stuff anyone said here applies to it. So unless you make something configurable which would indeed be messy in the way you’re describing - what would be the problem?
Yeah, for example if you allowed an option for the main volume slider to expand to full available width, that behaviour would have to be coded and maintained. And yeah, if you do this for 1000s of things it would add up. So you shouldn’t do this for trivial things… just for things that a good deal of people really want/need for good reason (which is obviously always debatable) - but which they wouldn’t need to switch back and forth all the time. At least that’s my reason why I think it’s a good idea.
However, that really depends on the individual cases. I think it’s just useless to discuss tales from the slippery slope…
Hey, wait a second… if this was really such a big problem, I wonder why you don’t strip out the theme editor? Doesn’t it make more sense for us to write GUIs/scripts to change the colors etc.? Quick, remove it, before it causes headaches further down the road… Seriously though, imagine having no skinning and someone proposing the theme editor right now… they’d be burned at the stake I guess. I seriously wonder how that feature ever came to be (and I love it, mind you… I’m just looking for some logic/consistency here)
LOL?
where in there do I claim you say it’s easier to expose something to the UI? I claimed you said it would be easier to expose it to the API than to the config, which you did, and I claimed you then skipped my reply to that and simply said “but if you expose it the config, why not expose it the UI [[because a feature worth having is worth being configurable]]”, which you also did.
Hence, I never said you said “it would be easier to expose it in the UI” (easier than what, anyway?), and cute screenshots don’t change that really, just get over it, gah…
You’re absolutely correct here…
Also absolutely correct here as well.
What is a trivial or none-trivial thing? at least a lot of time consuming when it comes to the debate alone. (Fortunately, Taktik rarely responds but is actually just working and getting stuff done which is in the benefit of all users)
Well, its a kinda simple equation:
More options, more code to add/handle this options, more paths in the code that only rarely get triggered, thus tested, thus easily get rotten.
Code gets triggered when it’s being implemented/tested. Code that is as simple as the few things proposed so far can be made 100% tight… unless you’re doing something outright wrong, why would it break or “rot”? I wish this was slashdot… 
Wow, sorry. I looked at that a million times and my eyes saw UI instead of API. So that’s my mistake.
An API is theoretically easier to maintain than a config file because the extra doodads that get added via the API are added by users and maintained by users. All of the options in the config file would need to be supported, whereas all that would need to be supported by an API is the API itself. And again, if the options we’re talking about are as simple as flipping a single bit, if users want it and it’s easy to implement, it might as well be available through the user preferences menu. No reason to hide it in a config file.
Function x is depending on function y
function y is depending on function z
function z is depending on function j
function j is depending on function e
For function z, there are some toggles made available for the user because it was highly requested.
Yet however the toggle is being used only for while then these few users sets it back to default behavior.
Now meanwhile development continues and more dependencies get added. Somewhere in this process, the non-default part of the function z toggle gets broken, yet nobody notice, because nobody uses it anylonger.
Now 3 or 4 beta versions later or perhaps during the final release, someone suddenly realises he needs something changed in function z that was toggable. User toggles the switch and hell breaks loose.
Which dependency we should look into to fix the problem? (not even talking about the waste of time looking in the wrong corner because we don’t know this toggle is the problem and the user is probably not aware this toggle might have something to do with it, so assume we already have been through that wrestling part and have come down to the point of resolving the issue)
The ones we already knew or the ones that came later and depend on it?
Otherwise said: So at which version did this “bug” crawled into Renoise?
And if the source of the problem is found, how much should be changed to fix this problem?
I can predict that the choice between doing a complete engine rewrite and dropping a simple toggle is pretty easy although i don’t fear it would come that far. But having to spit out various previous program version in order to figure out from which moment the bug started is no fun. And having to change several routines to fix the broken code is no fun either.
I say: for any “poweruser” options, if an update breaks it, then the poweruser can just deal with it. They’re not the kind of options that represent core functionality, or even what’s useful for the majority, so maintaining them would be of little use. Just put a disclaimer “please to not submit any options in poweruser config file”
Betas could even have this config file disabled to avoid a flood of silly bug reports.
this is going in circles… o_O
To why which I can only reply, again, WHY WOULD THAT HAPPEN? It’s no use to “answer” that question with a huge blurb before and after this crucial part…
“x depends on y” is a very wishy washy thing to say. How so?
vV, have you ever coded? No offense, but I really wonder.
Dude? Have you? The guy who coded Renoise gave you an explanation. I code 8 hours a day at work…
Sure it’s a metaphor, but it’s a very common problem in programming. If you can’t accept this, fine. But the question goes right back at you.
Indeed. There’s a reason there’s a term called “regression testing” and there’s a reason that regression testing is expensive and time-consuming.