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.