I really really demand a change in diskop for 1.27 final.
so far, I need to doubleclick a file to load and hear it, which sucks at the moment if I go through my collection of snares for example.
this has been requested before, I do it again here, hoping that it will be implemented for 1.27 final, because I am afraid if it does not happen now it will take a long time.
My suggestions is :
clicking a sample in diskop previews it, doubleclicking a sample in diskop does actually load it into the selected sample-slot in the instrument and rightclicking a sample (or double-rightclick if you prefer) does load it into the first empty sampleslot of that instrument. (this is meant for splitted wav-samples).
please make that happen for 1.27 final, its a good suggestion and shouldnt be too hard to do.
Recently I grew abit tired about things like that, people suggest things in the Suggestions forum, everyone nods their head and says “great” idea and then the whole thing is put to sleep, nothing happens.
this goes for example for the pattern-names, the dimmed display of the previous/next pattern in patternview and alot of other things I cant remember at the moment. some of these have been suggested months ago, but they just seem to be forgotten. does any of the developers make a list of suggestions like these so they wont get lost ?!
and finally sorry for the little rant, but as I wrote, its just tiring me abit at the moment.
What I’ve heard 1.27 is mainly ment to be a minor update with mostly bug-fixes. It has been said many times before and therefore only small and/or very well tested improvements has been added to this release.
I do not think you shall expect that every suggestion that is made in the forum shall be implemented in the very next version but I’m pretty sure that the developers reconsider every suggestion that is made, so I say: do not worry about it… The developers do a great job and I do not think we can expect them to be more than humans… I think the goal at the moment is to release a very stable release, and what I’ve noticed so far it seems like the developers are getting very close to that goal this time
I cooled down a bit now, but please note that I am not talking about suggestions which were made between the 1.26 and the 1.27 release … some are much older.
a list of things which will be added for sure (even if its only “some day”) would be nice.
Rightclick (as Johan just said, and as written in other threads)
The feature list is enormous, we couldn’t implement it all in years…
Some things are put on the list with a high priority, some with low priority,
and some things are delayed as a part of our master plan ,
simply because doing some things before others will result in less work,
and in the end faster overall development of Renoise.
One thing that’s easy to forget is that what other product can you even make design change requests and expect them to be implemented? Try doing THAT with cubase - it’s still amazing that we even HAVE the ability to request changes - just thought I’d throw that in there. It’s such a compelling reason to buy. I bet Cubase would see a large sales spike if they ever considered taking an approach like this.
Looza :
I can understand that you are disapointed, but you also have to understand that we have to choose somehow in what we spend our time.
If you think we do it wrong, tell us how we should handle this in future. Should we simply do what is most important to you ? If we do so, every registered user wants to have this privilege, and we are again where we started.
Weve started the WIP thing for exactly this reason, to know what most registered users would like to see next. If I would have always done what Im missing, without listening to you registered users, we would have now an arranger, as this is something I want to have since I started to code this thing.
Further, implementing prehearing without loading a sample into a slot and running this sample on a track that runs beside the normal tracks, is more work than you might think. I would also love to have this, but its damn much work and I cannot do this for the 1.27 final version without delaying the release for some weeks again.
Also remember that its not normal that software developers integrate their users that much into the developing process as we do. So I understand that you are disapointed as soon as you see that there is the possibility to decide what will be implemented, and then these dumb, egocentric programers dont listen to you, if you have an idea or suggestiong from wich you think that its a must have. There are hundrets of things that are a must have, but everyone has his special needs and would therefore priorize the things different.
I dont want to stop you from writing down suggestions, but I would like that you try to understand that we we do what we can. If you thing its wrong what we do, tell us how we could do it better, but dont think of your needs only then …
And yes, of course we have a list of suggestions that where made. Its all written down and as soon as we have finished a release we to pick out the new todos from this list. So nothing gets lost. And yes, this list is huge …
Hehe, I can imagine the to-do list must be huge. The fact that I can sit here and read conversations between the coders and users, and even toss my own ideas into the pool, is pretty darn compelling.
I’m glad I joined this community, can’t wait for what’s to come…
okay, okay, I see the point of the developers of course.
actually I wish I could code at least abit (a shame I stopped that years ago) and I would gladly offer my help. How much people are coding now on renoise anyways ? just you, taktik ?
I also understand that its a matter of summer, I will just wait for winter, because at the moment I can blame no one for going out to the beach instead of sitting at home
i also could say that not much of my suggestions are in renoise or coming soon there… but i suggested a lot… for example i suggested hue/saturation/contrast/lightness filter for colour theme (or skin), and i don’t think it’s hard to code, but it would be powerfull option to change colours with a few sliders (just try to load a screenshot to a graphic editor and change hue for example)…
anyway, i stopped post/mail my suggestion because i can’t fight with developer’s “master plan” which goes up to 2.0 i guess. but i would like to see ALL suggestions in big open voting (open for everybody, not “regged users only”). then we clearly can see what people think about it. regged users opinion isn’t enough, maybe they gave $45 for renoise, but that doesn’t make them smarter than the most of people in general. also i would like to see a few people (somekind of virtual team) which could make final design/standarts for renoise, also they should put user’s suggestions in right and optimal way. also minimal version step should be +0.1…
Zed: That color filter idea is actually pretty neat. Don’t stop the suggestions, they say they write’em down. So let’s think more about Renoise V2.0, they apparently have more than enough ideas for V1.x.
suggestions: well Zed, I also given tons of suggestions and most of them I don’t even know if were readed by the developers, but that’s not a good reason to stop saying what you would like to see in future versions.
poll for registered users only: You are right that the most important source for new ideas is non-registered users; not because they are more in number, but because they could make developers understand why they did not register yet.
There is a reason for closed polls: it is probably the only way to avoid fakings. And I think that what developers want less is a faked poll.
minimum version advancement 0.1: I don’t really get your point here: it has been said a lot of times that 1.27 is mainly a bugfixing version. Yes, it has some great new features too (track moving, new diskop, advanced renderer, to name three), but the main aim was to fix some bugs which were preventing people from using ReNoise and will have prevented it in the future.
What should have developers done? Release 1.27 as 1.3 and then 1.3 as 1.4? Or wait for 1.3 to release all these bugfixes?
they decided to offer us a better ReNoise version with a little 0.01 upgrade step, also preparing in the meantime the code for version 1.3
It appears obvious that the team is getting more and more experienced with time and then it is still correcting some design flaws whose cost they don’t want to be payed by the users.
You are right: there is a “master plan” ( ) until RNS2.0 which is already draftly designed, and I don’t agree with some parts of it (in particular: having skins before extended RNI format), but I really think that these kind of choices can’t be criticized by us who are not strictly involved into coding the application.
well, i don’t think there will be a lot of faking, no body interested in faking, after all it’s not direct “to do list”, it’s just poll where you can get some information about what people think in general…
well, there was a lot of small versions before… small version step slow down the implantation of new features imho, because you always should prepare any version to release it. i think bigger step will allow do more new features. and of course there should be big beta testing before releasing final. after all, it’s hard to test each +0.01 version, i would prefer test every +0.1 version and be sure there won’t be the same bugs until next version.
remember all big software developers (micromedia/sonic foundry/NI/whatever), they release soft with +1 version step (each year or so), of course that step is too big for renoise, and imho +0.1 is optimal
i’m too busy atm to suggest, it got not much of sense. of course i’m trying to keep important stuff in my mind at least. after all, there suggested a lot already, and i would be happy to see all the suggestions in renoise, so, any new suggestion got not much of practical sense…
yes, me too, but I also think it is very important that the result of the poll is relevant, and that is only guaranteed if you know each person only have one vote…
I think the goal at the moment is to release a very stable release, and what I’ve noticed so far it seems like the developers are getting very close to that goal this time 
,
) until RNS2.0 which is already draftly designed, and I don’t agree with some parts of it (in particular: having skins before extended RNI format), but I really think that these kind of choices can’t be criticized by us who are not strictly involved into coding the application.