Maintenance update, bug fixes, 3.2?

I gotta say Renoise 3.1 is the first version that feels really complete. I haven’t had the desire for any additional or new features (except for very minor things that I can work around) which really is a positive sign to me.

If anything at all, every new version that isn’t a bug fix may do worse than better.

Have they mentioned the new cat button yet? Random cats that fixes your tracks to make them more suitable for feline creatures.

I gotta say Renoise 3.1 is the first version that feels really complete. I haven’t had the desire for any additional or new features (except for very minor things that I can work around) which really is a positive sign to me.

If anything at all, every new version that isn’t a bug fix may do worse than better.

Untill the little things start to annoye you

-Envelopes are too slow ( they don’t behave accurately under 30 ms)

-10 Voice count limit , once this barrier is broken we can finally get some serious wavetable/scanning , because we need more than 10 samples per voice for wavescanning …

-Fixed signal flow in instrument editor …now matter what you do …;the amp. envelope is at the first stage , meaning (filter ) overdrive will affect the amp.env.shape , and thus decaying curves will be saturated ,a sel resonating filter wil NOT fade out because of this fixed signal routing .

-Lack of audio rate modulation both audio and event rate wise ( internal resolution )

It would be great i we could have some sort of copy of the existing instr.editor but purely dedicated to realtime synthesis , F.M. , math .generated osc’s etc.

And a lot more …;;

beetlefunnycutelolcat-gif.gif

Have they mentioned the new cat button yet? Random cats that fixes your tracks to make them more suitable for feline creatures.

Yes, a bugfix release would be great…

There’s also one concerning some midi controller users…

https://forum.renoise.com/t/fixed-two-midi-devices-get-the-same-midi-device-name/45789

Maybe we could expect a minor bugfix version for version 3.1this year.

However,for thenextmajorupdate it seems morereasonable to expecta version 3.5 beta at earliest around Christmas 2017 andits final release around early summer 2018.

Myestimation is based on the release history of Renoise so far:

June 2002:Version 1.0 released
March 2005:Version 1.5.0 released
March 2007:Version 1.8.0 released
November 2007:Version 1.9.0 released
January 2009:Version 2.0.0 released
May 2009:Version 2.1.0 released
March 2010:Version 2.5.0 released
November 2010:Version 2.6.0 released
March 2011:Version 2.7.0 released
March 2012:Version 2.8.0 released
December 2013:Version 3.0.0 released
October 2015:Version 3.1.0 released

So almost two years between the 3.0 and 3.1 release (which also involved Redux development).

(See full Renoise history here: http://www.renoise.com/products/renoise/release-notes)

Now of course we don’t know what the future holds. What if, for example, Berlin basedRenoise developers and Bitwig developersdecided tojoin forces?

Also, interestingly enough, here are the official release notes for version 2.0:

We decided Renoise 2.0 would be the best time to incorporate fundamental changes. Some aspects have changed so revolutionary that it completely revitalizes the way you make music in Renoise. Moreover, this massive engine overhaul is essential for behemoth features in later releases, such as
_ Zooming _, the _ Arranger _, _ Audio Tracks _ and a Piano Roll.

(quoted from http://www.renoise.com/products/renoise/release-notes/200)

Thisindicates to me that the developers and Renoise team, back in 2009, were at least open to the possibility of expandingRenoise withfeatures such asZooming, Arranger, Audio Tracks and Piano Roll…

Renoise is getting bigger and more powerful by the years which i would think makes it much harder to make improvements now compared to 14 years ago. It’s no point to release a new version just for the license count, you should really be happy they have something substantial before they release it or else your license would run out before you know it.

@fsus4

Are you even serious ., you think because two programs are developed in berlin then can just join forces …;like 'HEllo beatwig team …like to do some coding for us '.

Bitwig priorities are bigger to begin with, they have their own office and the team is paid on a monthly basis , the price and development cost are probably much bigger then renoise’s .

Renoise dev.team is made up by volunteers .

Talking about naivety .

There’s a reason why each update take’s so long , and why the majority of effects are not on par with N.I. , softube , cytomic etc …

@fsus4

Are you even serious ., you think because two programs are developed in berlin then can just join forces …;like 'HEllo beatwig team …like to do some coding for us '.

Bitwig priorities are bigger to begin with, they have their own office and the team is paid on a monthly basis , the price and development cost are probably much bigger then renoise’s .

Renoise dev.team is made up by volunteers .

Talking about naivety .

There’s a reason why each update take’s so long , and why the majority of effects are not on par with N.I. , softube , cytomic etc …

Not saying anything about the Bitwigs doingcoding for Renoise (or vice versa), only pointing outthe future potentialof having morejoined forces betweenvarious products and services. Bitwig is already doing somebusiness withe.g. the LANDRonline mastering service, Urs Heckmann (u-he) products, andothers. I don’t really see why Eduard Müllercouldn’t possibly choose to strike deals and bundle e.g. future Reduxversions with other companies’ products (or offering discounts on sale), especially with something like Bitwig Studiowhich is also available for Linuxand even quite similar to Renoise in many aspects.

Why oh why .;there a some bugs that the developers know about, in the meanwhile why can’t we have a simplemaintenace update ?

Yes: Why?

Or why no answer?

I think - from my experiences since the 3.0 release or so - the core dev(s) just have strategy to put a big shield around themselves while working on critical steps, as to not get dragged down by forum ramble & the usual lame cat jokes, or be distracted by the urge to justify descisions made. I can understand this, it is a very small project and has some “special” userbase. Imagine yourself being deep in some code work, and then having to deal with all kinds of ramblings by users afterwards…no good thing. Big projects would have a tightly organised timeline, and someone dedicated and instructed precisely how to communicate with the public. But renoise is a smaller thing. Also there seems to be some “its done when its done” philosophy, and one not to raise too many expectations before they can be fulfilled.

I take it as a good sign that communication is pretty sparse currently - only the necessary forum support right now and a lua tools sector which seems to have a user feedback strategy in development. In the past main public communication about the core happened in beta phase and for some time after release.

so keep calm & post lame cat pics. last year santa brought some betas, who knows who will bring the next.

Bugfix would be great. Of all the versions of Renoise from 1.0 to now this has crashed more times than any other by a mile… :frowning:

… & the usual lame cat jokes…

…so keep calm & post lame cat pics…

Aww cmon, don’t cat pic shame :frowning:

xc902a.jpg

Bugfix would be great. Of all the versions of Renoise from 1.0 to now this has crashed more times than any other by a mile… :frowning:

That’s probably also why they need more time to fix it. You may think a simple bug is an easy fix done in minutes, but i’m pretty shure if it was simple and easy to fix then it would have been done already. Maybe they have to restructure something from the bottom to make it work properly? Maybe they haven’t figured out a good enough solution? I don’t know, but i’m pretty shure it won’t get ready any sooner by speculating and nagging. :slight_smile:

this has crashed more times than any other by a mile… :frowning:

Crashed, as in…bringing down the application? That really shouldn’thappen.

Apart from the occasional buggy (and non-sandboxed) plugin, or when really pushing the API to it’s limits, I’m not aware of anything that can cause Renoise 3.1 to crash.

So I’m wondering if there is anything you can do to reproduce these errors? You know, the usual procedure for reporting bugs…

I know there is a maintenance release on the horizon (although I’m not able to say when), and it would be a shame to miss out on something so important. Avoiding crashes is top priority!

I managed to crash Renoise 3.1, by clicking stuff thousands of times per second with auto clicker. :smiley:

Yeah I can crash Renoise too, but it always picks back up where I left off when I restart it so it doesn’t bother me too much. It crashes probably < 1% of the time I use it.