Don’t have this experience on catalina on a late 2013 macbook pro
We need a sample BeatSync timing option for “Original sample length”, so we can quickly/easily use the “Repitch”, “Percussion”, and “Texture” time-stretching algorithms to pitch-shift samples, without affecting the sample’s original playback speed
This does seem extremely quick/easy to implement, to the extent that I wonder if maybe it’s already in Renoise and I’m just not finding it?
Having this option would help with multiple things, including using Renoise to learn covers by ear; by being able to pitch-shift samples without having to make a bunch of 512-line-long patterns to playback the whole sample/song.
Being able to time-stretch based on a percentage value of the original sample length would be helpful for this as well
I currently use Harmor in resynthesis mode to pitch-shift/time-stretch songs for learning by ear (I am aware of alternatives), but if Renoise could just add this one feature, it would easily be my go-to for this purpose (and be way quicker to setup/easier on CPU performance compared to Harmor). It would be a useful feature in composing as well.
Yep, unbelievable that wasn’t in the last update, so maybe I’m just dumb & unable to find out how to do it ?
A plan for MIDI 2.0, particularly interesting for a UI is the security aspect surrounding
the features that allow for inter-networked collaboration or web-midi type concepts
included in the new standard. Perhaps there are many implementation possibilities
worth braninstorming over in this space.
Thanks for Renoise.
Isn’t this more of a mac os issue ( amongst others ) ?
Yep, i created a feature request for this, which is quite similar:
Renoise still needs information about the tempo of the sample to get this working. It could be using the current song tempo or detect it like Sononym.
/clear
What I am asking for would be tempo-independent (you could change your song’s BPM and it would not affect the time-stretch of the sample at all). If the sample is 52 seconds, it will be 52 seconds long no matter what.
The only thing I’m wanting is the ability to pitch-shift the sample without affecting its playback time (and the additional idea of time-stretching based on a percentage value would be cool too - so, for example; a 52-second sample playing at 50% time-stretch would become 104 seconds long)
Renoise 3.3 really needs to come for Christmas 2020.
definitely. i got excited when i realized some sections could pop out of the main window, but quickly realized that using the navigation shortcuts like F1,F2,… collapses all the separate windows back into the main window. (F1, F2,… being “recall view preset”)
Slightly off-topic but, after viewing Renoise 3.2 crack as a search suggestion on Google, we need to promote Renoise, ensure its future and let people know how versatile, minimal and amazing it is. Buy it, you won’t regret it!
I think that’s fake. I guess due the kind of community of Renoise, nobody will leak a registered version ever to a cracker. Also it is very low priced, so affordable for most people. Maybe that was different for the other software they do, but I also hardly can imagine any 100% safe protection in javascript… So maybe that is a waste of time anyway. Actually I think Taktik is working pretty hard on the next version, but there also seem to be time issues a.k.a. having another job, family or so. I don’t really know Kind of a pity, those delays.
What do you think, would be the next version worth a 0.5 or even 1.0 jump in version number (and so generating more income for the developers)? At least I think so.
I don’t get why there is only 1 big version every 2 years with let’s say 4 major new features in it. Why not doing 4 smaller updates with only 1 major new feature per version? That way we could already be on Renoise 3.6 and not only 3.2. With updates every 6 months. And so Renoise 3.7 could fall with VST3. So yes @ffx I’m ok for a jump of 0.5 if VST3 is implemented. But I’m also ok with myself (lol) for smaller and more frequent upgrades.
Maybe that was related to macos making a lot of problems, so causing lot of development time anyway…? Yes, I would agree with all you are writing.
We’ve been trying to do that for almost 20 years , renoise is a niche product .
Maybe polyend tracker/sampler will attract new users once they realise that trackers have been around for ages and that renoise is still king .
It’s kinda funny when you read on message boards how people are amazed about polyend sampler and the re-trigger stuff etcc , yet didn’t even know about the existence of trackes in general
I think taktik is also working on other projects (like sononym) and it’s maybe not a good idea to work on too many things at once and that’s maybe the simple answer why renoise upates happen in big chunkes instead of more frequently?
Taktik pls
I suggested this a few years ago but I would still really really like a recording format drop-down in the sample recorder popup window i.e.
16 bit
24 bit
32 bit
32 bit float
Not everything plays nicely with the 32 bit float wavs that Renoise creates, and they can be huge.
I know you can do this after the fact in “Adjust Sample Format” but its another step.
Thanks
have you checked if this is something that can be done through API Lua scripting?
Here’s a potentially unpopular suggestion:
How about a way to set a preference for hex vs. decimal values in the pattern editor? Y’know for those of us in the base-10 community?