New Tool (2.7/8): Presonus Faderport Implementation

Renoise Tools
65

Thank you Airman :D

:drummer:

66

thanks :wink: … faderport’s rotary pan encoder just delivers two values (one for left, and one for right).
I tried several view builder controls and this fit best.

67

Hurray :slight_smile: , finally I released the official Version 1.1 for Renoise 3.0:

http://www.renoise.com/tools/airmann-s-faderport-driver

Everything was tested and after some polishing it should now work pretty stable.

New things added since last beta:

  • fixed some minor bugs

  • Improved emulator dialog / button labels

  • Better tool menu, updated manual, new help dialog and improved manual integration etc…

  • fully tested (regression tests)

  • sticky mode disabled by default, because it turned out that it doesn’t work stable because of Renoise LUA API limitations.

…enjoy

Background and pictures of new emulator mode:

http://blog.airmann.de/faderport-emulator-for-renoise-3-0/

Emulator.png

68

Just wonderful! Thanks a lot, Airmann!

69

Thanks guys :slight_smile: !

70

Hey Airmann, really awesome your driver. But I have some suggestions, that I am missing:

  • In the project mode, jump to a track within a multitrack: What about adding shift+> and shift+< for selecting a inner-track-track?

  • For recording, I am missing metronome control: What about removing the Trns->Sampler function, since it has no more shortcuts for sampler anyway. Instead Trns could on/off metronome, shift tens for pre count metronome… Or something like this.

  • The gui framerate drops extremely to 2fps, if I move the fader on the faderport, until I release the fader. Using Mac/3.01. Is it a problem on Renoise side or could you improve this (maybe because of too frequent bi-directional messages)? If you like to see this problem (doubt it exists on PC version), I can make a video. Also reported this problem as a bug:https://forum.renoise.com/t/osx-gui-slows-down-on-renoise-app-show-status-calls/43129

I can try to help, but somehow lua is not my language…

71

Hey Jurek,

thanks for feedback and suggestions. Since I’m also a user in a lot of cases, I understand that there are always wishes for modifications and improvements.

Problem is: I have very limited time for further FaderPort driver development. Since I still use it myself I will probably keep it up to date and fix bugs, though.

Nonetheless, it’s almost impossible for me to implement new stuff. Also I regard the driver as pretty feature-rich, already. More features than I personally need tbh.

E.g. look at the Reaper faderport implementation: it has far less features, but the main things are there.

@track selection

it’s already possible to navigate between inner tracks. Only thing is that group boundaries are not handled as such. Means: if the first track of a group is selected and you press < the track before the group is selected and so on. Guess what you expect: press < and the last track of the group is selected (cycling through group) ? If you need such a feature look at the LUA code and especially at my midi handler code. Check for the previous/next track selection calls. Have a look at the Renoise LUA Api for group handling.

@metronome control

Have another look at my midi handler code. Search for “trns” and simply create a new function which does what you need. Shouldn’t be too tricky !

@GUI Framerate

IMO it’s 99% a Renoise bug. I don’t say 100%, because you never know :wink:

72

Airmann, thanks for fast answer and info. Ok I will try to add this :slight_smile:

Relating track selection: I do not mean tracks in a group, I mean in a polyphonic track the particular note columns.

73

Airmann, thanks for fast answer and info. Ok I will try to add this :slight_smile:

Relating track selection: I do not mean tracks in a group, I mean in a polyphonic track the particular note columns.

Cool !

@note column: ok, that’s a different requirement. Should be easy to implement. Just add some handling code to midi handler. Guess you will not need more than 10-20 lines of code. Hint: regarding shift state have a look at the other shift-functions.

74

Hey Airmann, one problem appears for me: If I write / touch new automation, let’s say pre-volume, I cannot hear the actual change live that I do with the slider. I can only see the change in the automation graph live, the change is audible only on next play/loop.

Is this a faderport driver or a Renoise problem? Thanks.

EDIT: If there is already automation present.

75

Hey Jurek,

thanks for feedback. This is IMO default Renoise behaviour and no bug. It also occurs if you use the right mouse while moving the slider of an already automated device property.

Background: Renoise of course needs a kind of source/master who defines the current value of a device property. So Renoise can either use the current value of the slider, or the automated value(s) from the envelope. What Renoise obviously does: as long as the slider isn’t moved the last and next automation points define the current property value (think also about interpolated values between two envelope points, Renoise has a high envelope resolution). As soon as the slider is moved, a new envelope point is set, otherwise the journey goes to the next envelope point.

The Renoise behaviour is IMO a kind of incomplete touch mode with one big disadvantage: it doesn’t take touch state into account. Means: only slider movements alter parameter values, just holding the slider does not alter the envelope, nor does it set or override the current value of the device parameter. In other DAW’s like e.g. Reaper the “touch” automation mode takes the touch state into account: as long as the fader/slider is touched, the current fader/slider value is master and overrides already recorded envelope values.

I tried to simulate this behaviour in the FaderPort driver (also I did simulate write and latch modes), and thus envelope points are at least written while the FaderPort’s fader is touched, but I can do nothing about the envelope read-ahead-priority that is currently implemented into Renoise. Renoise authors could IMO easily implement at least touch mode, by introducing a proper touch state and remove the read-ahead behaviour. E.g. as long as right mouse button is held the touch state would be “true”.

The whole automation recording concept of Renoise is pretty basic and unfortunately not comparable with the concepts of DAW’s like Cubase, Reaper et al. Also is the mixer concept. These are differences between DAW’s mainly intended for audio recording/cutting and the more creative DAW’s like Renoise. On the other hand envelopes are essential for Renoise, too. So IMO better envelope recording and also undo handling should be on the developers TODO list. IMO this is, what makes a DAW mature.

For more details see my FaderPort manual. I describe all automation modes there.

76

Did you request a proper touch automation priority as a feature request?

77

No, I didn’t. TBH I doubt that this would have high priority on the devs todo list. Guess there are more important things now like Redux and fancy modulation stuff ;-)). Ok this is super-sarcastic but you get the idea. Anyway, would be great, if you could enter such a feature request.

78

Hm, but they also could think: Shit, we are doing all this time-consuming, complex programming, why not then implement all the little missing stuff while we’re already diving so deep in abstract worlds? A deep diver only requires a fraction of time.

79

Feature requests are a difficult topic here in the forums, since each and everybody has fascinating ideas and requirements that are “total must” or “killer feature” for themselves - totally subjective, of course. My observation and experience is, that a big number (not all) of those feature requests are either ignored or workarounds are suggested like “write your own LUA script” - btw: that was a reason why the LUA API was introduced. In the Renoise beginning things were different: the user base was smaller and to me it seems that people were more involved. E.g. devs made a feature request poll a few years ago.

To be honest: I can understand the devs. So many people and opinions are difficult, if not impossible, to handle. People demand this, people demand that. At the end of the day the devs have to decide by themselves where the journey goes and how their product shall look like. Also from the software engineering perspective it’s in most cases better to reduce the number of features and options of a product to a minimum. It’s a known disease among developers to implement too many features. These features have to be maintained, cause side effects, make the product more complex and so on.

So, even if the devs are diving deep into abstract worlds, they actually do a good job not to implement too many littlea and big features, but instead try to make their product more mature. That said, IMO they left this path during the latest Renoise releases. Fancy features like “tracker in tracker” were introduced, while other, more elementary gaps (e.g. midi routing, wav tracks, weak mixer concept, side chaining etc.), are still there. In my opinion Renoise is still a cool and stable DAW, but feature-wise it’s in the meanwhile somehow “unbalanced”. The roadmap seems to say “Renoise is primarily an instrument”. I wish it would say “Renoise is primarily a DAW with a tracker GUI”.

Therefore, I doubt that touch support for envelope recording is that important for the devs.

Nonetheless, I encourage you to try to submit such a feature request. Good luck !!

80

Added metronome support to faderport driver. Optionally toggles metronome/precount on/off on edit mode toggle. See help for details.

EDIT: DOWNLOAD LINK BELOW

Now I would like to try to fix this annoying slow down in Renoise OSX, if the fader is moved and write or touch mode not activated, as reported here: https://forum.renoise.com/t/osx-gui-slows-down-on-renoise-app-show-status-calls/43129

Do you experts think this could be fixed within the faderport driver or is it Renoise related?

EDIT:
It seems to be a bug in the status bar code of the Renoise OSX version. The faderport driver doesn’t seem to cause any problem.

81

Added metronome support to faderport driver. Optionally toggles metronome/precount on/off on edit mode toggle. See help for details.

http://tstlab.virtualcreations.de/renoise_forum/de.airmann.FaderPort.xrnx.zip

Now I would like to try to fix this annoying slow down in Renoise OSX, if the fader is moved and write or touch mode not activated, as reported here:https://forum.renoise.com/t/osx-gui-slows-down-on-renoise-app-show-status-calls/43129

Do you experts think this could be fixed within the faderport driver or is it Renoise related?

Hey Jurek, nice to see you managed to add the modifications. A first FaderPort driver branch :-), yeah !

Regarding the OSX problem: I replied in your other thread.

82

For all who have stutter problems while using the faderport on OSX Renoise, here is a dirty workaround that delays / reduces the amount of status messages (since it’s causing the stuttering):

http://tstlab.virtualcreations.de/de.airmann.FaderPort.xrnx.workaround-stutter-osx.zip

83

Hey airman and faderport users,

here is the fixed faderport driver version, it includes the following patches:

03-Aug-15: de.airmann.FaderPort.xrnx-03-aug-15.zip (unzip and then double click extracted xrnx)

Please report bugs. Thx.

84

Hey airmann,

still have this problem that on writing/touching automation data, the values will crazily jump between some old values and the new values in the moment I leave the fader…

Do you have this problem under Windows, too?

Could you describe me in short how this works, which functions will be called, so I can try to fix it? Btw. what is this :compute_trim_speed() for?