For me, that would be the perfect reason to come and say hello 
I’m not against this idea, but I agree with the train of thought this is turning Renoise more closely into a synthesizer.
I like the fact that Renoise is a swiss army knife, but I’d rather see other things that would be more useful, and closer to the core of what renoise is used for - for example, the zoom view for the more accurate timing, punch in recording, more accurate sample offsets, etc. (Okay fine, that is just my list of wants, but still, I think it’s more closely aligned to what Renoise currently is - a tracker, not a synth).
David
That’s just words though. “It’s a tracker” has begun to loose meaning somewhere around the 90’s. It’s software, you make music with it and drive hardware.
All “tracker” still means is “numbers and letters, scrolling vertically”. Any other “paradigm” is just something you people make up on the spot.
Yeah well, 99 of 100 are (very) friendly. But every now and then someone feels the need to announce that they have absolutely no interest in what I’m photographing 
And what is Renoise used for, pray tell?
I don’t know about everyone else here, but I happen to enjoy Renoise’s versatility greatly. It’s not only a sequencer dude… it also happens to be 50% sampler. Most good samplers have some aspect of synthesis. Adding more modular effect control will only serve to make it easier to realize your sonic vision. Currently, there exists a great divide between synths and sequencer, and this very much hinders our possibilities.
I mean seriously, you don’t see the guys at Ableton going “hey, we don’t really really need to add the ability to layer samples, that’s too close to synthesis… and the users don’t need fine sample control… what do they think this is, a waveform editor?” … That’s because Ableton, like Renoise, isn’t simply a sequencer. It’s a Digital Audio Workstation… a virtual sound studio. And for a piece of software as progressive as Renoise is supposed to be, you’d think the community supporting it would be a little bit less anal retentive in threads that are simply SUGGESTIONS.
But I dunno, maybe you’re right, we should follow the herd. PIANO ROLLS FOR ALL.
exits thread stage left
BYTE Smasher - I said I’m not against the idea, but I think there are functions that would be more commonly used by a larger amount of the userbase that could be attended to first (like the ones I mentioned).
Didn’t mean to run you right out of your own thread. Just saying, my vote goes to something else first, then this.
Well as does mine… doesn’t mean I’m gonna go around knocking down other ideas. This is a presumeably simple metadevice… the fact that there would be some snags implementing it is fine… I’m not however, going to stop discussing it because it’s not a top priority. The implications that it’s a stupid idea to begin with are what I’m getting frustrated with. It might seem stupid to others, but I see a definite use for it, whether it’s on the top of my priority list or not.
Nothing that gets posted in this idea forum should be presumed by anyone to be a top priority. Claiming it shouldn’t be top priority is a lame excuse for bashing it.
<@VenerealSnails> it’s called the ideas forum for a reason
<@Suva> Like your HFO request? 
<@VenerealSnails> yeh like that one
<@VenerealSnails> it’s not the first time I’ve come under fire for an idea i’ve posted
<@VenerealSnails> and people get downright nasty sometimes
<+get-plastic> :’’(
<@VenerealSnails> granted, the HFO idea doesn’t seem to be stirring that much controversy
<@VenerealSnails> but sunjammer in particular
<@VenerealSnails> I can’t believe that guy
<@VenerealSnails> he whined for ages about the lack of what is now hydra
<@VenerealSnails> and now that hydra is here
<@VenerealSnails> he bashes my idea for being “not in line with the renoise paradigm”
<@VenerealSnails> fuck that shit
<@VenerealSnails> that’s stupid
<@VenerealSnails> what is the fucking renoise paradigm anyway?
<@VenerealSnails> what’s the renoise goal?
<@VenerealSnails> I’d like to know
<+get-plastic> lol
<@VenerealSnails> I’m fuckin serious… that shit pisses me off
<@VenerealSnails> it’s a fucking feature request… taktik’s not gonna just implement it without thinking it out
<@VenerealSnails> he’s a smart man
<@VenerealSnails> let him discuss with the team and decide
Please, everyone stop being so mean. Work things out before he explodes!
Pretty sure I wasn’t bashing it when I opened my post by saying “I’m not against this idea…”
As you can tell by pulsed’s revealing irc snippet, I’m mostly annoyed at comments like the ones Sunjammer has made. And it’s not simply him… it’s all the people in this community that devote their time to insulting the perfectly decent ideas of others. I’m sorry if it came off like I was pissed off specifically at you hektic.
No worries!
For me it’s even not so much the shooting down of suggestions as the way in which it is done. In this case:
“stuff like this exists”
“no it doesn’t”
“yeah, and there’s a reason for it not to exist”.
That doesn’t really feel like a conversation…
I don’t wanna pick on sunjammer though, this has been a renoise forum peeve of mine for years. And I’m sure 99% of the time it’s well intended, to “make sure” other things gets implemented … but we HAVE TO stop making up fairytale programming schedules for taktik!
And again: we say “tracker” and “what the community wants” as if these things actually exist, but they don’t, at least a consensus doesn’t exists and then you might as well not use constructs like these at all… there is a reason they are constantly used in politics, because they serve to obstruct and confuse and nothing more.
So. HFO.
Man, i’ll be first in line to admit that i like shooting down suggestions. Shoot them down the priority list that is. I think a feature should always branch and solve multiple problems, and as such solve as many COMMON problems as possible. The moment you spend important time on super specific specialist tools, time you could’ve spent on improving the experience and utility for the majority, then you need to rework your priorities.
You should NEVER optimize for the minority. I think everything anyone ever wanted should be in Renoise, but i think it should have some real gunpowder behind it for it to have a right to live. Simply throwing ideas out there, i would like to be challenged on mine, and i like challenging others on theirs. To be an arrogant prick, If you can’t sell me, a (i think) fairly demanding Renoise user, on your idea, why would joe everyman need it?
I’m asking, simply, to be convinced that it’s useful. And so far i haven’t heard a single example. I use Max/MSP quite a bit, and high frequency modulation is something i haven’t needed beyond synthesis, or ever felt a need for, so please, EDUCATE ME, tell me what you would like to use it for! I’m honestly interested!
Sorry if i’m a bitch, but i care about Renoise to the point that i have literally had dreams where i’m on the dev team. Hilarious, humiliating ones. Seeing Renoise take a turn towards featuritis has been a deathly fear of mine for years.
There is a bloody good reason why nothing like this exists. Because you CAN NOT modulate VST parameters with high frequency.
Why?
Because data in VST is processed in buffer blocks. The size of the block varies (and is somewhat connected to the Renoise buffer size parameter). Let’s make a little example. Let’s assume the block size is 128 samples. Which in 44100 sampling rate would be ~1/345 seconds. The parameter values can only be update between the buffers, so each buffer is calculated with the parameters set prior to the processing.
What does this mean? It means that when you try to modulate the parameter with higher frequency than 345Hz then the results will be unexpected and erratic.
On analog hardware there is no such problem because the signal is actually processed in real time, there are no such things as buffers. In digital signal processing, the signal is never really real-time, it’s just processed “fast enough”. The 1 sample “buffers” which taktik mentioned earlier can create similar environment to analog processing, but as said this adds huge overhead. And by huge, I don’t mean two or three times slower… Depeding on the plugin design, adding only one instance with this “high resolution processing” on the chain may actually choke even the fastest computers. That’s because that the repetitive calculations are usually done with “the fast areas of CPU” like FPU or even SSE instructions. The other, smaller percent of the time in the plugin is spent on stuff like jumping from one function to other and passing data around, this gets actually pretty slow if it’s supposed to be done all the time. Imagine it like taking laundry out to dry, but instead of bringing the whole batch, you take every piece of laundry, one at a time – before that, most of your time was spent hanging the laundry, now most of the time you will spend going back and fourth to the house. Now if you have important meeting in an half an hour (the buffer needs to be sent to the sound card, or else sound card doesn’t have anything to play and starts glitching), would you really find it efficient to carry one sock at a time?
It is possible to do these kinds of modulations though. One good way is that the modulating signal is also buffered. The problem is that the plugin itself has to support the buffered signal. And as surprising it is, there are already plugins that do support stuff like that. VST plugins with multiple inputs, sidechain compressors, AM modulation plugins, etc. The fact that renoise doesn’t support those is totally different topic.
So concluding the long story.
- HFO is impossible to implement with the current technology.
- Using 1 sample buffers would slow renoise down to a crawl and is not feasible solution.
- HF modulation can be achieved with plugins designed for this purpose which have multiple inputs.
- Renoise will eventually support those plugins and probably offer some itself, but this is another topic.
Sunjammer, presuming that my idea didn’t need a major reworking of Renoise’s innards, (which it seems now it would) what would be the problem in implementing it? If there were no technical limitations, it would be a change that might consist simply of copying the LFO class and adding a multiplier to the rate. So even if one couldn’t see an immediate use for it, it’s not like implementing it would have really taken any time away from other features. This is why I suggested it. I didn’t know there were technical limitations.
Obviously however, there are… and as soon as I realized that, my thoughts on the discussion transcended from simply implementing a seemingly easy feature to the territory of “plz I want to know about teh limitationz” … because such shit interests me. This limitation would obviously affect other potential features as well, and I was trying to suggest a possible way to get around it (exceptions) so as to help Renoise overall… not JUST in regards to this feature request.
The thread, however, degraded into “OMFG WHY R U EVEN GOING ON MORE ABOUT DIS, IT R STOOPID IDEA”, at which point my tolerance threshold for unconstructive criticism broke.
Aside from taktik’s response, which I didn’t entirely understand at first, Suva has probably provided the most constructive input to the conversation so far… although he was still doing some “dude your idea is stupid” style bashing in the irc channel earlier.
Either way, I probably seem like a childish user going “OMG I WANT MAH FEETURZ”… but I really don’t care that much about the HFO idea… it was just an idea. Ideas are a dime a dozen. But that’s entirely the reason why it’s lame to put them down. Like I stated earlier, taktik is a smart dude… he’s not gonna implement stupid shit without thinking it through first. Bashing people’s casual ideas because “oh no, the devs might take this seriously!!!1111oneoneone” is really quite an insult to the intelligence of the team. It’s also just silly.
But yah… I’d like much more to see an arranger, and proper effect and parameter-data routing. That and instrument patterns… w00t!
“Enabling any parameter to be modulated with high resolution” is as generic as you can get, no???
And the distinction between composing and synthesis is an illusion and solely your problem.
I don’t really see this as “yet another feature”, but more like as making the engine more flexible… cough amplitude follower device cough
But I don’t even care to justify that anymore, it’s ridiculous. I experiment more than I “compose”, and using other apps would just kill any experimentation right there for me.
- render something
- save it as sample, do something with an external app with it
- import it
- as soon as any part of the song used for generating the raw material for the third party stuff changed - BACK TO 1
What a waste of time.
And another thing, maybe I got that wrong, but I was under the impression that it would be very slow, but not necessarily hard to code… not buffering stuff was there first, wasn’t it? 
First you implement stuff, then you optimize. Dream less and code more and you’ll be less afraid…
Yeah well okay then… but still: what about the Renoise INTERNAL fx, simple stuff like gain and panning?
Well it’s a clear case of “right goal but wrong methods”. What you do basically want is sidechains, cause only way this high resolution processing would work is when the plugin doing the destination maths can read input signal itself.
Ok, so the consensus is that suggestions should never be discussed, questioned or justified, only thrown out there into the cosmos for the developers to happen upon, and for other users to high five on pure instinct alone? I don’t have a pathological need to mess with you, but i expect you to be able to defend your reasoning. You know, so that i might +1 it or something.
But let’s not have a forum guys. The cruelty of having people care enough to respond to us is too much for us to bear.
And the distinction between synthesis and composing is day and night, like building a car and driving it. I don’t know what you’re on about. As long as Renoise operates in terms of notes, the distinction is quite clear.
Cruelty? That I can handle. Stating you don’t agree with ideas because you personally would never use them? … no, I can’t handle that. Your definition of “useless” is far from definitive. I would use the HFO for synthesis (of the type which potentially can’t be achieved with VST synths), plain and simple (which I stated) but for you that’s “useless” so it’s useless of me to argue with you. It’s perfectly useful for me, and it would probably be useful to other users as well but that doesn’t matter to you. Either way, it’s a moot topic now, because it’s obviously limited technically, but you started arguing it when it seemed it would simply be a matter of copy and pasting the LFO code.
If you had provided anything close to constructive criticism, I might have been inclined to defend my position. However, your point was simply “Renoise shouldn’t be used for synthesis” … to which I’ll respond right now: Why not? There are many people already using it for such things, myself included. Why would we restrict ourselves by limiting that option, when it’s plain for many to see that Renoise’s ability for synthesis is part of what makes Renoise a VERY powerful and versatile piece of software? Might I point out that you yourself are a seeming fan of Renoise’s synthesis abilities, as evident by your distorted-hardcore-gabber-kick-mayhem? Yah. I thought so.
You’re right, we should get rid of all the internal effects, the LFO, and the automation. What silly things to put into a sequencer.
In the future (even if it takes 10-20 years), it will be nice for Renoise to support this kinda stuff. I mean, I’m guessing it won’t mean the interface is noticably changed at all - just that sliders/edit fields will have finer/microscopic resolution.
I wonder if the upcoming Larrabee GPU/CPU will allow this. Hardware synths must use special custom chips to create the sound, so perhaps Larrabee, which combines the slow but versatile nature of the CPU with the raw speed (though less generic nature) of the GPU, will deliver.
In the end, we have a digital monster which emulates the old analog processor completely and in realtime
Oh btw, how can I turn “Enable email notification of replies” by default for all my posts?
Just an FYI, at ridiculously high BPMs, the LFOs work like HFOs. (since the speed settings are line-based)
I’ve done FM in Renoise by creating a sample where the amplitude is maxed all the time, putting it on loop, setting the BPM to 500ish and the LPB really high, and controlling a ringmod with an LFO on the track where the sample is playing. From what I understand of Renoise’s timing system, this works because the LFO speeds are based on the subtick system, which is Renoise’s replacement for the original tick-based timing system. There are 256 subticks per line, so theoretically you could set the LPB and BPM high enough that the number of ticks per second approaches the number of samples per second.
At 450BPM with 36 LPB, you have 25636 subticks per beat. At 450 BPM, you have 7.5 beats per second, and so 7.536*256 gives you the subtick rate, which could be considered the [fingerquotes]sample rate[/fingerquotes] of Renoise’s timing system and the LFOs. This comes out to…uhh…69,120TPS, (ticks per second) or Hz. A sample rate of approx 69 KHz (according to the Nyquist/Shannon theorem) can accurately represent frequencies up to 34KHz. That’s higher than you or I are physically capable of hearing.
I realize that this would only be useful for sample-based synthesis within Renoise, but my point is that it is possible to achieve these sorts of results with the current system. It’s just not practical for real-time processing. However, give it a shot and see how your machine handles it. It (might) give you a vague idea of how Renoise would run if the timing system was synced to the sample rate.
Dunno if that makes sense. Maybe I’ll make a video. Might be fun.