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?
What is the CC Type in Renoises MIDI learn dialog for both controllers?
Should be one of
- Absolute 7 bit: Use the CC value as an absolute value.
- Relative signed bit: Increase at [065 - 127], decrease at [001 - 063].
- Relative signed bit 2: Increase at [001 - 063], decrease at [065 - 127].
- Relative bin offset: Increase at [065 - 127], decrease at [063 - 000].
- Relative two’s comp: Increase at [001 - 64], decrease at [127 - 065].
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
2.1 and 2.5 were also without scripting. But what changed with Midi mapping was that you could map the same CC message to multiple controllers.
I’m on it.
Sorry for the late reply.
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 ;(
thanks for the effort anyway.
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.
tomas
Linux, eh? What window manager are you using? A user has discovered that some of them are shit, and not the ones you’d expect:
Read: Linux, Renoise And Choppy Sound
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?
as i tried it on various computers with various OSes, there are several window managers - on linux machines gnome and lxde. no difference.
graphic card: on notebooks all kinds of more or less crappy integrated gcs (ie. intel 945gme, ati hd4200), on pc i have some basic nvidia (standalone, ie. not-integrated). again, no difference.
as i mentioned before, the problem is not present with old (pre-lua) versions of renoise.
to make the research complete, i’ve tried renoise and akai mpk mini on an imac (with osx tiger). although the mixer faders react somewhat more fluently than on linux and win, there is still some random latency, depending on the speed of knob twisting and number of controllers being operated at the same time (faster movements, more knobs = larger latencies). again, plugin sliders react flawlessly.
the problem sadly persist on 2.7.0 b2
t.
Will try to get my hands on a mpk mini and try this here…
tomas:
could you please check if things work better in the latest 2.7 Beta (B5)?
I’ve tested this with a “mpk mini” here, and the only thing I noticed is that on very slow computers, some mappings may react slowly. We’ve tweaked this in the latest beta a bit.
eureka, just tried (B5) and it works now! i love you guys!
thanks so much,
tomas