Just wondering if the Devs have looked into Dirac much as an option for including integrated timestretching and pitch-shifting to Renoise.
Now I know there are active (well many previous at least) Time-stretch topics and Dirac has been mentioned at least in passing but not really commented on and not for some time. Before even considering putting it as a suggestion I thought it worth seeing if it would even be possible and if it had been investigated.
Now firstly it needs to be compatible with Renoise. Seems as long as Renoise is written with C/C++ this is likely. Although no Linux version is on their site they do say it’s available on request (but maybe only with the pay versions…)
Now there is a basic free version.
This does pose a fairly serious problem of only supporting 44.1 and 48kHz sampling rates so would cause Renoise to take a step backwards if used. Did wonder if it had even been investigated though, just as a test bed… Also each instance working on one channel, so needing to run two for stereo etc.
Unfortunately I guess the licensing is too expensive when you consider our user base the cost of Renoise to go for the more complete versions. For fully unlocked sampling rates it costs 9870Eur and if you want the actual source code it’s typically double this (although they say they are negotiable on this.) For sample rates of 8-96kHz it’s about half that but it lacks “Dynamic Time and Pitch Changes” by which I assume something akin to warp markers, or the ability to automate the changes.
looks like an interesting option, though if I check Renoises own programmable timestretch option using 9XX patterncommand sample offset on high bpms, surely the devs can program their own timestretch engine and smooth things out between ofsets / make it sound better?
I’d prefer something that is painfree to license/implement/update over something that sounds slightly (or a lot) better… even shitty timestretching would rule.
I’d prefer something that sounds amazing as opposed to implementing something inferior.
Why not contact them in an attempt to negotiate the liscensing. (And I’m speaking about the Renoise Dev’s not just random people on the message board). For example, offer them a marginal percent of each Renoise registration. There are a whole number of options that could be explored. It could even be a liscensing option that offers a marginal part of registrations until a certain amount has been reached (perhaps in excess of the one time liscensing option, but at the same time not an ongoing residual).
As a short term (or free) solution I think implementing it with 48k would be fine, and if sampling is set at a higher rate the feature is just disabled.
No shit sherlock, but would you also prefer nothing to something that is “inferior” (inferior to something that is theoretically possible… not inferior to nothing)?
I think it’s sad enough higher sample rates got removed because some fx don’t support them, now you want timestretching that works only at 44.1 and 48, and just stops working at other rates… and is owned by people that want money for it?
I’d rather have some basic timestretching and through that the ability to check out wether it’s worth the bother to timestretch something properly (realtime algorithms will never hold a candle to offline ones, NEVER EVER) – than waiting years for a super duper timestretching that will still not be as good as timestretching in a dedicated application.
You also have to realize that once everything else is in place, improving the timestretching algorithm or swapping it with a better one would still be possible? So what would be so bad about something “crappy” that actually happens?
No, it’s not been looked at or no, it’s never going to happen?
And Johann the 44.1/48kHz version says free for any use. Need to pay for more sample rates and other advancements (but still using same algorithm.) Of course that’s assuming it can be integrated at all without the source code itself. Just thought it could be worth experimenting with at least from the Devs side, even if it never makes it out. (Although a beta version for registered members with it would be nice )
Renoise would require the Studi version, other versions are too limited to be seriously considered to be embedded in the Renoise. The pro version on the other hand costs 4700 USD. I don’t think anybody is interested making that big investment for a minor feature in renoise.
Just like when you work with images, you keep them at the maximum resolution until the very last moment.
Higher resolution → less rounding errors. It’s simple as that.
And hey, 48khz sampling frequency means the highest possible audio frequency is 24khz, which is WAY above the human hearinng range… but that doesn’t matter. Even 384 khz would not be too much…
… it simply should not matter! The sample rate should be a variable which has an effect on memory and CPU used — nothing more, nothing less. I don’t get why all algorithms that can’t be adapted to that aren’t just phased out. Then everbody can decide themselves if they want to operate at 11khz or 4096 khz oder whatever… oh well, I’m a dreamer.
)