oh man. I know you were joking but RnsSQL query commands would be so sweet.
on second thought some kind of python-like scripting would be cooler. auto-generated and self-modifying patterns…yeah 
gosh though. it seems like it’s been a while since an update, just because we usually get updates so often. but I for one am quite happy with Renoise how it is. I’ve certainly got my money’s worth, and then some.
I think taktik should compile a “Light” open source version of Renoise. In such a version, the source code for all “heavy stuff” would be stripped out (and developed further only in the commercial version) – which means that features such as loading of VSTs, the mixer, sampler, instrument editor, even the entire audio-engine would be gone… and that leaves us with what?
Well, how about a framework for loading clips, manipulating clips, performing various operations on pattern data itself… maybe even that SQL-database and a google-like interface to search for clips… It wouldn’t hurt to see what can evolve out of it over time…
Everything doesn’t have to be implemented into the main software, you know. Renoise and Renoise Light could co-exist together and the user would just switch between the windows, using copy and paste of the xml-data…
Seriously – Renoise team – you should consider this Transcender™ suggestion! 
I’m not entirely sure there will be a 1.9.2 as I have read that after 1.9.1 comes version 1.A
I think in case of the new melodyne, the hype does actually help sell the program already.
Links & names please.
I like surprises! 1.9.1 had lots of those and they were delightful.
Honestly whatever features are added to renoise from now on for me are just bonus, since the audioin device was added it’s pretty much got everything I could want in a tracker…
cheers
Hmm…I’ve heard an argument against developing two versions of the same product in parallel, that it somehow opens wider the doors for piracy. I’m not sure how this works but I assume that this would be at least part of the rationale against this. Seems unlikely.
Oh man. Thanks for reminding me that I can do this. I’ll just write some simple clipboard-mangling code. That’ll at least take care of pattern edits. Sweeeet.
That’s true. I am radically against the idea of Renoise being open source – in fact, one of the reasons I really love Renoise is because it IS a commercial music software. This is like saying: “Hey, we take this project seriously and we expect to profit on our success”.
Yes, production and development is essentially the same as profit. You plant 10 potatoes in your soil today, and if you later harvest <=10 potatoes you haven’t produced anything and your profit is zero. The same logic applies in most areas that involves productive work – and incentives to do more productive work.
Let me also say that my suggestion wasn’t meant to imply that the Renoise team can’t figure out what is the better strategy here. I think you guys have spent a lot of time on these issues.
The “open source” tool I was thinking about here wasn’t Renoise itself – i.e. not a TRACKER – but rather the already existing XRNS toolkit integrated within an environment that looks like Renoise in terms of loading of content. What I am proposing is an easier way for the user to do custom scripting and code.
Now you point out that there are very few people working on such scripts today. Yes, but let’s not take the status quo as the standard for future potential. I personally believe that Sourceforge is too difficult, too abstract, too un-intutive and too ugly – in fact, I really hate that place. It’s a jungle where you need a lot of courage and a big macheta knife just to carve yourself in two or three inches just in order to download a simple script. Now who’s Joe Blow expected to do that?
Oh my…!
This is a cementary. I hope I’ll never see Renoise on that list in the future!
Well, I’m not saying that Renoise itself should be distributed in two versions (see above).
I don’t see how the existing (open source!) XRNS toolkit correlates with Renoise piracy, do you? Now when Renoise goes 1.9.1. with the Linux community – which has a long history of fostering an open source culture – I don’t see why it should be impossible to target specifically the potentials of external developments. Having a memory and CPU friendly (i.e. it doesn’t load VST/sample-data or other heavy stuff) Renoise-like environment opened next to Renoise, in which stuff such as songs – or clips! – can be stored in an easy manner… now that’s what I’m proposing as open source.
Let me also be the “devil’s advocate” and ask this:
Why does everything HAVE to be integrated in ONE package (i.e. Renoise the tracker)?
Wouldn’t it be wise, at this point (or when Renoise reaches 2.0) to split the project in two parts? (Avoiding complexity issues, bugs, design issues that show up later, and a lot of other shit.) But – adding a way of communicating between them?
Why not keep Renoise the tracker as simple and enjoyable as possible – and then place stuff that can be transferred to Renoise itself with the press of a button in another software? With dual monitors, that’s most convenient too.
I need a second opinion.