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.
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 ?
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:
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
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
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 ?
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:
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
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?
Will still be required for tools and else also doesn’t hurt.
Just picked up a Faderport and trying to get this tool to load without much success. I grabbed what seemed to be the latest on github and attempted to drag it into renoise and I get an error stating that it is incompatible. My renoise version is 3.1.1 built 2/6/2017.
Could someone post a link to the latest or working version?
I’d like to do what you said but I honestly wouldn’t have a clue where to start. Could you give me some pointers please?
First you need to enable the scripting terminal;
How to Enable the Scripting Developer Tools in Renoise
By default Renoise has all the scripting stuff hidden to keep things as easy as possible for those who don’t want to mess around with code. If you want to write scripts, the first thing you have to do is enable the hidden development tools that are built into Renoise. This can be done by:
Opening Renoise’s config.xml file from the preferences folder, and set the ShowScriptingDevelopmentTools property to “true”. If you don’t know where to find the Renoise preference folder, open Renoise and click on “Help” → “Show Preferences Folder…”
After doing this in Renoises tool tab you’ll see an entry for scripting terminal & editor, open it and browse, search for the tool you want to edit in the folder tree, click the arrow icon and look for the manifest file, open it through double clicking and look for the ‘apiversion’ line, change it from 4 to 5 and don’t forget to press execute in the bottom right of the scripting terminal window, this will save what you’ve just changed. Now try re-booting the tool.
After doing this in Renoises tool tab you’ll see an entry for scripting terminal & editor, open it and browse, search for the tool you want to edit in the folder tree, click the arrow icon and look for the manifest file, open it through double clicking and look for the ‘apiversion’ line, change it from 4 to 5 and don’t forget to press execute in the bottom right of the scripting terminal window, this will save what you’ve just changed. Now try re-booting the tool.
Thank you for taking the time to help me out Djeroek
I followed your instruction and its working. Now that I know how to get under the hood I’ll try to see if I can modify the Duplex for my MPD32.
