Hello Everyone! I would drop in a new idea what I think not so hard to make it work. X-Mix mode would be a new version of transition between patterns. Tracker is about simple sequence of patterns, but for live use, it would be nice to make some nice transition.
I imagined that method where next pattern can be āx-mixedā, put it in a new container in the sequence which is simultanously playing in the background, but user must manually (or according some automation) swap tracks. Swapping means when a track swapped, it changes to the x-mixed one instead of actual and plays its content āmixedā with the actual patternās other tracks.
I donāt know how much work needed to develope such solution but I think it would greatly improve live application of this DAW.
Yeah, I guess the UI part might quickly become overwhelming.
But itās definitely possible: A similar method of mixing between patterns (if I understood correctly what you describe) was featured a good while ago:
This reminds actually of the old school way to perform live with trackers (before the era of midi controllers): you needed back then 2 computers + a dj mixer.
If you want to stick with one instance only of Renoise, maybe you could try adding a Redux inside Renoise and crossfade between both?
Think it or not, I tried it. No success. Especially with a notebookā¦
Your system is not powerful enough? Songs are taking up too much CPU?
Because, if you ask me,mixing multiple instances is definitely THE way to go.
On a sidenote: some audio/MIDI drivers are not happy about being shared between programs. But if we pulled our resources together, we could do a proper guide on how to run multiple instances - not just related to Renoise, this is a pretty universal thing.
And actually, creating a good low latency linux system is still a bit like voodoo to me
I can certainly relate to that. Been fine tuning my system for months with very little improvements - although in all fairness, I think Iāve already pushed latency to the limits.
Your system is not powerful enough? Songs are taking up too much CPU?
Because, if you ask me,mixing multiple instances is definitely THE way to go.
On a sidenote: some audio/MIDI drivers are not happy about being shared between programs. But if we pulled our resources together, we could do a proper guide on how to run multiple instances - not just related to Renoise, this is a pretty universal thing.
I think a bit power issue, a bit driver issue, and much of the lack of my experience on multiple instance running. First, how can I share my audio interface with minimal latency? Second: how can I use the same controller for opposite functionality in both instances? Like I wrote in the starting post, when I push a button, one of the instances will have to mute a track meanwhile the other instance have to unmute the same track.
Now Iām half on the way to go. Only one thing missing: how can I use one audio interface to share between multiple Renoise instances?
Steinberg Generic Low Latency ASIO driver -> it appeared first in Cubase 7 software pack. Itās a kind of ASIO server, works with Windows 10 and minimum latency is 10 ms which means a low-level software mixing rents a CPU time around 4-5 ms to summarize audio buffers. Iām afraid the minimal latency on a usual laptop results glitches. Itās part of Cubase, so at least demo version have to be installed on the system. (the driver can be used without licensed Cubase)
ASIO Multi Client Server -> promising but it wonāt work on Windows 10. At least Renoise doesnāt seems to recognize it, or selecting the actual interfaceās ASIO driver does not points out the usage on the ASIO serverās client list, and that driver remains locked when I try to select it in another instance - so it didnāt taken form the server. Here is the driver.
Anyway, multiple instances can be start with this config swapping method, MIDI sync with LoopBe virtual MIDI cable and split incoming MIDI messages from external controller with MidiOX router. This bunch starting up with one click on a PowerShell command file launching apps one-by-one with a proper timing, priority and cpu affinity settings. All other nuts and bolts like proper MIDI mapping on different instances have to be prepared in the future.