I want to automate device parameters in real-time (I know it will lag with smooth transitions :P) via another daw in rewire master mode.
So I thought about:
14-bit midi from rewire master into a virtual midi port> pure data to convert it to osc>bind that todsp device parameters
Is that possible,and/or is the osc done in the gui thread, therefore controlling several parameters even at a somewhat low time resolution is unfeasable?
What is the other DAW?
Won’t all the intermediate steps ruin the latency before it even gets to Renoise?
The other daw is either reaper or Cubase, the only intermediate step that I would have no control over is if osc functions in renoise are run in the gui thread (for example if that’s the only way to bind dsp parameters to osc). If puredata would introduce too much of a latency I’ll consider writing my own midi to osc converter eventually.
I am on 256 bytes/s internet for some time, so checking everything by download is problematic.
Some thoughts:
Send OSC direct from Reaper. http://www.cockos.com/reaper/sdk/osc/osc.php
Send MIDI direct to Renoise and write your own Renoise MIDI handling script to have them alter the device parameters.
My own experience with Renoise and OSC is that it is quite fast; I’ve not noticed any latency issues. But I do think all scripts run in the GUI thread (so you cannot get super-exact timing information, for example). In practice I’ve not found this to be a problem, but that might just be my use cases.
I’ve been told reaper can’t send osc note data, or maybe that was only within the API (along with midi).
I’ve attached functions to midi in renoise before and it is very fast,but if the scripting api is the only way I can preform the automation, that would be too slow for me, as I want to automate several parameters at the same time, not record them to automation.
After some sanity checksofthings I’ve already checked years ago slaps self, this idea would never work as automating already around 8 parameters at ~3ms resolution results in a renoise/virtual midi port freeze.
I’ve attached functions to midi in renoise before and it is very fast,but if the scripting api is the only way I can preform the automation, that would be too slow for me
When you are responding to external events - MIDI, OSC, whatever, the api will try to respond as fast as possible. It won’t be crystalline precise, but also not the sloppy result if you asked the API to tweak a slider while running at UI rate.
And yes, parsing a high messagesfrequency of course means that you have to take great care not to perform anything too demanding - but it’s definitely possible for lua to process a fair bit of information, especially if you use pure lua (avoid too many calls to the renoise API hooks, which always carries a certain overhead).
this idea would never work (renoise/virtual midi port freeze)
Unless you route everything right back at the source, you should be safe?
Or you can investigate basic echo detection within lua itself - e.g. Duplex has this, and will (optionally) ignore “duplicate” messages that arrive within a certain time threshold.
(to test this, I had my mlrx sequencer running as a tool in Renoise, responding to input from a monome which I then routed into a PD patch and then from PD back into Renoise, which in turn would update the monome).
I used the attached xrns to test the problem. I’m using loopmidi as a virtual midi port
lfo in points (otherwise the resolution would be too high)>hydra>midi control device>min max values of empty hydra
As displayed in the loopmidi window, at around 10KB/s throughput, the gui in renoise, windows kind of as well, starts to slow down noticeably. at around 20-30 renoise freezes (it’s a very, very sluggish state, not completely frozen)and loopmidi’s feeback detection kicks in.
I’m not perfectly sure what exactly is the cause, loopmidi, midi on windows, renoise (the cpu usage in renoise does go up quite quickly, proportionally to the midi automation speed). You can pause processing of midi in loopmidi, and it ignores every message sent to the port, at these high rates, renoise is still in the frozen state.
That feedback warning must be a false alarm.
I mean, with such a setup the MIDI will never go back to the source - it’s basically sent down a one-way street.
It probably got triggered because of some internal echo detection in the loopMIDI driver.
Since all such a detection scheme can do is to look for certain patterns in traffic, it’s not 100% foolproof.
To further strengthen this theory, it locked down (detected feedback) the moment I opened the port - now, why would opening an input port cause MIDI feedback, if you just wanted to take a look at the messages being sent?
Probably, the feedback detection kicked in because now one of it’s conditions were true: two programs connected to the loopMIDI stream.
Also, you can trigger the feedback warningreliably as you raise the LFO device frequency - but a real feedback would be happening at a very high rate, the very moment it started.
LoopMIDI does not seem to have a switch to turn off this feature. But maybe I just missed it.
Yeah, that’s what I thought is that it simply triggers when a certain throughput is reached. But I guess I could try some other midi port and see if i’ll get any usable results, though as I mentioned earlier, it’s a very power hungry process, renoise at a frequency of close to one said to use 20% of the processing power in the top corner, and that’s a bit too much to handle.
I have an audio interface that has both a midi in and out, UR22, maybe I could plug it into itself to get a virtual midi port, could the result actually be better?
OK, I made it send cc to the UR22, sinewave, 1 LPC, no midi binding to parameters, not sure if the ur22 does react to feedback, however, the cpu usage does become larger and larger the longer I have the lfo running (and the gui obviously slows down, windows itself is still usable though)