Line-in was indeed for using live feeds with internal effects. When doing any other purposes with it, the line-in device is just being ignored, though i haven’t tested what it does when you would attempt to circumvent this by submitting your line-in device including track to a send-track and then select an area in the send-track instead to use for “render selection to sample”.
If that would already work, you can still expect glitches and skips in your audio, even though (or maybe i should even say:specially because) it is routed back.
Also it is a form of digital loopback which i hardly have seen being purposely being allowed in any application that performed any form of (streaming) communication.
See ardour for example. Every internal routing in Ardour is actually an external routing in Jack. IOW. All routings in Ardour can be connected to other software or hardware. And it works really well.
Linux people would assume the same thing to work with renoise. If you route something through jack it would work as internal routings.
For example using Jamin in a chain to master the sound. Or maybe get notes from ZynAddSubFx to compress with other things. Or using Om to make advanced FX. Or maybe use my behringer ultracurve to master some bits of the data. Or maybe a hardware synth. Etc.
So you can record audio from other applications realtime in the sampler using everything that you need even with the track effects that you want to have applied to the external feed.
The line-in device can also be connected the same way that it was designed for… You just cannot use the rendering possibilities as they are by nature not designed for live feed purposes.
I don’t know how much work it would be to set a trigger for the Line-in device to allow live feeds being processed in Linux only, but if this would require rewriting a large part of the core audio engine i doubt this will ever be done.
A multi-platform application has its restrictions and is hard to make it bend into three different directions.
Now because Windows is the platform Renoise was founded on, the routines and functions are based upon the possibilities and limitations that Windows carries which includes the whole core engine of Renoise.
Ardour is multiplatform but has no Windows equivalent which imho seems pretty strange for a highly respected open source application and this fact alone gives me a pretty good idea about how much work it is to keep an application compatible on all platforms and make it do exactly the same on every platform without exceptions.
Okay, i don’t blame you for not knowing Windows too well on this area and i think that is for the better to be honest.
Also Renoise uses particular speed-up algorithms to render data faster than it would play realtime (if you pick the fast rendering option in the render window) and the speed would then depend on the power of your CPU. If internal samples and instruments would be rendered with that option, then your external gear won’t get any chance to gracefully merge its audio to the stream.
Yeah, I haven’t used windows for audio work since win98 in year 2000 maybe. And then I didn’t do anything more advanced than record from microphone and such. It actually amazed me to find out that this is about as much you can actually do with windows computer in audio production. Everything else is a hack. What amazed me the most is that sending midi from one program to another is also a hack under windows.
There are also options to render the song in real time. Also Jack has a “freewheel” support. Which is intended exactly for this: Running things faster (or slower) than realtime, for rendering audio.
I guess the problems in here are definitely not a priority. There are easy workarounds for the issues here. Like using record instead of render to sample to capture the audio. Just the Renoise currently somewhat misses the point of jack and treats it as just another audio driver.
I’ll try to write a design document about the issues. Just for the consideration.
Thats definitely the way to go on Linux if we want to fully support the Jack environment, but currently we are limited to use Jack only as an “audio driver”. Lets keep this in mind for the next Renoise upgrades. Thats unfortunately nothing I can add/fix for this release, as this requires a lot of changes in Renoise.
the reason why this can’t be possible in renoise is because of a possiblity of a feedback loop during rendering, hence probably smoking hardware, right?
Feedback loop won’t smoke your hardware. Unless you are using speakers turned all the way up to max with amplifier ten times as powerful as the speakers can handle.
I am still writing the proposal and consideration document. Will post it later this week. Surely not for this release. But maybe for next, or one after that.
