hi,
when i assign a midi knob to a mixer fader (or anything else) to be cc controlled, i can’t manage to get fluent, continuous performance. when turning the knob faster, the fader kind of stutters, jumps, various latencies appear between knob action and actual fader response (up to cca 1500ms!). this can be both heard and seen. it looks like renoise somehow cannot handle more values in short time. the response is smooth only if i move the knob very slowly.
my setup: linux (debian) on asus eee, akai mpk mini. yep, quite a whacky setup, but probably this is not a cpu load issue- it happens even with empty song with cpu load meter on 1%. and just in renoise - in other apps like ardour the control work just fine with the same hw, with heavy dsp too…
does anyone have some idea how to solve this annoying trouble?
thanks!
In the GUI preferences, you could try to lower the frame-rate (from 60 to 30 or 20) and see if that makes a difference. Renoise doesn’t concentrate too much on the graphical updates and shifts more attention to the audio processes.
the thing is that this is not just graphical issue (that wouldn’t bother me so much). the problem is obviously with the actual midi transmission. the midi/dsp response is distorted/delayed the same way, ie. every time i make faster change of the track fader level, i see AND HEAR the corresponding volume slide with variable amounts of delay, or the slide seems to be skipped and after some delay the fader jumps directly to the final position, etc. this makes for example beat mixing quite impossible.
anyway, i tried lowering the frame rate in gui preferences, but nothing changed…
How exactly do you use the MIDI in Renoise: Via Duplex or MIDI mapping in Renoise directly?
Do you have the same problem with all mappings, or just with a few controls (like parameter of a DSP vs. the track volume).
1500ms is huge. And never should happen - whatever method or mapping you use though.
i use direct midi mapping (not duplex).
after some testing it looks like plugins sliders react ok, but mixer faders (both pre and post) behave as described.
i’m not sure if we understand right each other. i’m not trying to automate the faders’ movements, i want to control them live/manually using akai mpk mini’s knob set as a control surface.
or are you talking about some settings of the controller itself? how would i do it then?
thanks,
t.
i’ve just tried mpk with renoise on my “big” computer (dual core amd64, ubuntu) and the problem is present, too. again, plugin sliders move fine, faders stutter. again, in ardour everything works fine with mpk. i should also add that all other functions of mpk - keyboard, pads, arpeggiator - work fine with renoise - no dropouts, no extra latencies…
yet, i tried to connect another control surface (bcf2000) and it works fine with both renoise and ardour. so, just the combination i need the most -renoise+mpk- sucks. really frustrating. any ideas? thx,
tomas
If plugin parameter sliders behave ok but not the pre and post faders, it reads like something in the midi feedback area is going on there, it might not be possible that values are returned to the mpk and then sort of causing a war-trailing between Renoise and the mpk in who wins the battle for setting his side of the volume level?
There must be something strange going on with MIDI messages that are handled via scripting on Linux (Pre/Post vol/pan is, DSP params are not). I’ll dig deeper.
Very Strange that it works with the bcf2000 but not with the mpk for you. Do you maybe use relative MIDI mappings with the mpk, abs. ones with the bcf2000?
i don’t (intentionally) feed any midi signal back to mpk - as mentioned before, i use direct midi mapping, not duplex, i’ve even disabled the clock.
but what is confusing: when i connect mpk (by selecting it in preferences’ midi pane as an input device), it appears in qjackctl on the writable clients side as renoise’s midi input! screenshot here:
i use always absolute 7bit cc.
and yes, it could be something with scripting. i tried to enable the experimental sample loop markers mapping script Experiment: Use Midi Knob To Set Loop Markers (btw. very cool feature!) and it behaves similarly to the faders.
I’m going to use a cross-thread suggestions of mine just on the off one chance might work.
Have you tried connecting your controller using only one USB plug per root device? (I.e. nothing else plugged in, basically) Have you updated the driver?
It sounds like an issue with the USB polling being interrupted due to the MPK being kicked down to a lower priority. (I’ve suggested this before, but here’s why): This wouldn’t be noticed with something like a single note or pads, etc, because it’s just one short signal, but the fader moving might require more ‘bandwidth’ of the polling cycle to update what’s going on with the software, causing a latency if other devices (mice, keyboards, audio interfaces, hard drives) are hogging up the polling cycles. I’ve had similar issues with devices such as recoding interfaces that are USB based. This also being said there may be an issue in with the drivers being able to handle this as well, since you are having problems on two seperate systems.
thanks for the idea. tried to disconnect all other usb devices, but it didn’t help. actually, i think the usb transmission itself is ok (mpk works fine with other software and even with plugin sliders in renoise). it must be some problem in how renoise handles some particular mappings (volume faders).
as for drivers: mpk is a driver-less instrument, ie. it is a class compliant usb device that uses default system usb drivers.
if i find enough time, i will try it with duplex yet - probably i can try to modify akai lpd support Duplex Device: Akai Lpd8 , although im generally very bad at coding…
one more update: i tried to connect mpk to a windows machine with renoise 2.6.1 and i had exactly the same problem. then i found on the same machine (win xp) an old install of renoise 1.9.1, so i tried the mpk mapping in it and it works! this indicates it is probably some (platform independent) bug in newer versions, possibly connected to scripting somehow (1.9.1 was without scripting, right?).
is there a way i can help to solve this? should i fill some kind of bug report? is information provided in this thread sufficient, or should i do some more research?
tomas
Did a few more tests with Duplex on Linux and other “scripted” MIDI stuff in Renoise and unfortunately? could not replicate this. In theory scripted mappings are indeed a “bit” slower and less responsive than non scripted ones, but that’s far far away from 1500ms. more 10 ms. I thought this maybe is a platform, Linux related issue, cause I haven’t tested MIDI & scripting that excessively yet. But its definitely not a general Linux prob.
Unfortunately I also have no more idea why you could get such a lag ;(
one thing i can say for sure is that it is NOT a platform related issue. i just tried it on a brand new dualcore amd64 laptop with win7 and the problim still persists. must be something with scripting combined with the way how akai mpk mini handles the midi data (is it somehow non-standard? have no idea). the problem is present just on scriptable faders in renoise- all other mappings work fine, as well as other software under all kinds of linux AND win versions. if i have a chance i’ll alco try it on mac, but i’m pretty sure the result is going to be the same.
When you say “just on scriptable faders in renoise- all other mappings work fine” and “when turning the knob faster, the fader kind of stutters, jumps, various latencies appear between knob action and actual fader response” I can’t help but find the problems similar.
Lua scripts are run in the GUI thread…
Since you say the problem occurs on Windows too, what’s your graphic card for good measure?