New Tool (2.7/8): Presonus Faderport Implementation

Renoise Tools
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?

85

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.

Cool, I’ll check it out ASAP … but no promises about the time range … thank you :slight_smile:

86

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?

This is no bug, it has to do with too big value differences. E.g. old value is -INF, new value ist 0 dB, next value is -INF. Whenever the fader is in read or touch mode, the driver reads the values one after another and tries to adjust the fader position of the motorized fader accordingly. As long as the values are continuous no or no strong jumps occur. Discontinuous discrete values cause troubles. The effect could probably be avoided/dampened with some kind of interpolation / smoothing code etc… My advice: experiment with off button in those cases, or simply deactivate touch mode directly after recording, so that the problematic values are not read at all.

:compute_trim_speed() calculates how fast the rotatary encoder (pan control) is turned by the user. The faster the higher the value change. It’s also described in the manual (search for “Speed and Down-Scaling Feature”).

87

Airmann, did you check this with LPB 8 ? Since I got those strange jumps only then, LPB 8. With LPB 4, everything seems to be ok. Or better say, the faster the LPB the more those jumps will be written. How should I or you fix this?

EDIT: For this I have a bit a fix it seems, using a timer instead… Since idle-timer is 10Hz? Far too slow… Isn’t it?

faderport.lua fix

[SPOILER]

function FaderPort:on_idle() if (not renoise.tool():has_timer(self.on_idle_real)) then
  renoise.tool():add_timer(self.on_idle_real, 1000/250)
 end
end

-- idle handler. We're called whenever the workload is low
-- average: 10 times per second:
-- TODO: high load and fader writes: Renoise restriction
function FaderPort:on_idle_real()
...

[/SPOILER]

But one question: Write-mode should write all the time, even if the slider is not moved… Right? Why this doesn’t happen here?

Also didn’t get the difference between shift-write and write?

88

Airmann, did you check this with LPB 8 ? Since I got those strange jumps only then, LPB 8. With LPB 4, everything seems to be ok. Or better say, the faster the LPB the more those jumps will be written. How should I or you fix this?

EDIT: For this I have a bit a fix it seems, using a timer instead… Since idle-timer is 10Hz? Far too slow… Isn’t it?

But one question: Write-mode should write all the time, even if the slider is not moved… Right? Why this doesn’t happen here?

Also didn’t get the difference between shift-write and write?

Yes, if the LBP speed and/or Renoise load is high then some positions are omitted. The 10 Hz are really slow. The solution with the timer is interesting. Maybe this is a better way for envelope writing. Thanks for the hint - I’ll check it out.

What do you mean with “Why this doesn’t happen here ?”. Do you mean the “jumps don’t occur” or the “data is not written ?”

Write mode is per default in “latch mode”. Means: automation data is written from the moment the fader is touched until playback stops. This is the default write mode of FaderPort driver. Means: if you press “write” button, this mode is activated. (you can change the default write mode in preferences, though !)

What you address is “Pure write mode”: new automation data is written as long as the playb ack is running, overriding previously recorded automation. Attention: don’t forget to disable write mode after the recording session. There’s no automatic prevention of unwanted automation overrides. To enable this mode press “shift”+“write” buttons.

There’s also a diagram in the documentation which illustrates the differences between the various modes.

89

Airmann, did you check this with LPB 8 ? Since I got those strange jumps only then, LPB 8. With LPB 4, everything seems to be ok. Or better say, the faster the LPB the more those jumps will be written. How should I or you fix this?

EDIT: For this I have a bit a fix it seems, using a timer instead… Since idle-timer is 10Hz? Far too slow… Isn’t it?

faderport.lua fix

[SPOILER]

function FaderPort:on_idle() if (not renoise.tool():has_timer(self.on_idle_real)) then
renoise.tool():add_timer(self.on_idle_real, 1000/250)
end
end

-- idle handler. We're called whenever the workload is low
-- average: 10 times per second:
-- TODO: high load and fader writes: Renoise restriction
function FaderPort:on_idle_real()
...

checked it out. I’m not sure if timers are faster than on_idle(), since they are called by app_idle_observable().

documentation says:

–[[
Register a timer function or table with a function and context (a method)
that periodically gets called by the app_idle_observable for your tool.

Modal dialogs will avoid that timers are called. To create a one-shot timer,
simply call remove_timer at the end of your timer function. Timer_interval_in_ms
must be > 0. The exact interval your function is called will vary
a bit, depending on workload; e.g. when enough CPU time is available the
rounding error will be around +/- 5 ms.
]]

and regarding app_idle_observable:

– Invoked periodically in the background, more often when the work load
– is low, less often when Renoise’s work load is high.
– The exact interval is undefined and can not be relied on, but will be
– around 10 times per sec.
– You can do stuff in the background without blocking the application here.
– Be gentle and don’t do CPU heavy stuff please!
renoise.tool().app_idle_observable
→ [renoise.Document.Observable object]

But maybe the internal call to app_idle_observable() is simply a timer with the parameter (1000/100) !

Anyway, I’ll check it out. If it’s faster we have the answer !

90

AFAIK the only way to make the Lua API respond faster than the in-built frequency is to hook it onto some external message, such as MIDI. This is so, since the MIDI is processed in the audio thread.

But, what you can do (and what I have done with my own tools) is to make the function which write pattern data have a certain “writeahead size” which will automatically adapt to the song tempo - i.e. a very slow song will write only a single line at a time but an 16 LPB song might write several lines at a time. You need to handle a lot of edge cases though, like end of patterns/song and so on, which complicate matters a lot.

It would be nice to have a generic library for this specific purpose - to make it easier to create tools that operate with realtime data.

91

AFAIK the only way to make the Lua API respond faster than the in-built frequency is to hook it onto some external message, such as MIDI. This is so, since the MIDI is processed in the audio thread.

But, what you can do (and what I have done with my own tools) is to make the function which write pattern data have a certain “writeahead size” which will automatically adapt to the song tempo - i.e. a very slow song will write only a single line at a time but an 16 LPB song might write several lines at a time. You need to handle a lot of edge cases though, like end of patterns/song and so on, which complicate matters a lot.

It would be nice to have a generic library for this specific purpose - to make it easier to create tools that operate with realtime data.

Thanks Danoise for the helpful hints

The “writeahead” function is an interesting suggestion. Nonetheless, as you’ve mentioned the problem are the edge cases. I’m not really keen on coding such stuff. From my past experiences it’s probably pretty error prone (?).

Maybe the more simple workaround for the problem is just to temporarily lower the LPB during recording envelopes ?

92

Little off topic message:

received a new FaderPort device last week which enables me to test alternative firmware updates. It’s a free gift from Presonus. They appreciate the Renoise driver development and after the years it’s finally a nice recognition from this company. And beside that: it’s the first time I ever received something for my volunteer work $-). Yes, there are paypal and flattr donate buttons, and people anounced to spend me a cup of coffee etc., but unfortunately no one never did. So:

THANKS PRESONUS ! IT’S DEFINITELY SOOTHING

93

Airmann, these are great news and a good move (and a overdue recognition) by presonus.

Regarding all those timing problems while live recording:

In my opinion the lua api needs observables LINE , LINEF, SEQPOS,TICK from the realtime thread! Just like available in the formula device (which runs in the realtime thread).

Is it possible only to connect those REALTIME values to the lua thread, without moving the whole thread to realtime? I guess there are solutions for this :slight_smile:

94

Airmann, these are great news and a good move (and a overdue recognition) by presonus.

Regarding all those timing problems while live recording:

In my opinion the lua api needs observables LINE , LINEF, SEQPOS,TICK from the realtime thread! Just like available in the formula device (which runs in the realtime thread).

Is it possible only to connect those REALTIME values to the lua thread, without moving the whole thread to realtime? I guess there are solutions for this :slight_smile:

Guess the Renoise devs intended to seperate LUA scripts from realtime access by design. IMO this makes sense, since otherwise scripts would quickly become dangerous. Nonetheless, I’d like to hear what taktik thinks about observable LINE etc.

I know about the formula device … but it seems it was only available in a 3.0 beta version ?

95

Ok, but for a proper working script interacting with live playing, you need a proper tick event… This would simplify script development a lot. I also not able to build a proper workaround for the faderport driver that works good on high LPB… Maybe danoise could have a look into it and a concrete idea?

The formula device is still there, but hidden (no clue why). Have a look at these helper tools:

https://forum.renoise.com/t/new-tool-3-0-insert-hidden-legacy-renoise-dsp-effect/43441

https://forum.renoise.com/t/new-tool-3-0-insert-hidden-legacy-renoise-dsp-effect/43441

96

Small Update note:

FaderPort driver seems to work with latest Renoise 3.1 beta3, but isn’t automatically updated by Renoise.

Means: you have to open the tools faderport Folder and edit manifest.xml. Change the API version from 4 to 5 and then it should work.

BTW: I’ve moved all my projects from Google code to github lately. And I’ll release a proper 3.1 version ASAP.

Thanks to Jurek - I plan to integrate a better status line behaviour, too. And I’ll have a look at those idle handler …

97

Thanks to Jurek - I plan to integrate a better status line behaviour, too. And I’ll have a look at those idle handler …

Hey, I think for 3.1b4+, my patch isn’t required anymore, since taktik applied a fix to status bar lately (not 100% sure about it). Instead could you consider to leave the jump to/from send functionality integrated? It’s v1.2 from here:https://forum.renoise.com/t/new-tool-jump-to-from-send/34051

It should be inside this version:https://forum.renoise.com/t/new-tool-2-7-8-presonus-faderport-implementation/29542

Maybe taktik could leave a short statement, if his statusbar fix also could fix this heavy-calling-statusbar-message-problem via lua?

If you have a version, I can test it on Mac and then let’s decide, if the workaround is still required.