New Tool (3.0): Loop Control

Renoise Tools
1

Yo, Renoise crew, here’s a tool that lets you do sample loop point automation

4939 Screenshot 2014-04-21 20.27.59.png

It works by creating a doofer that is tied to the loop points of the selected sample. This can be done to multiple samples across multiple instruments. The loop control doofers are contained in a dedicated FX chain within each instrument and numbered according to the sample index.

Usage:

To create a loop control doofer, select ‘Add Loop Control’ from the sample list context menu in the instrument view, or run it from a keyboard shortcut. The selected sample will then have a loop control doofer created and attached to it. To access the doofer go to the FX chain labelled ‘~Loop Control’.

There are six controls per doofer, from left to right these are:

1) Loop Size - This controls the loop start point to adjust the loop size.

2) Snap Mode - Set the grid that the loop size will snap to. Three modes are available:

  • Free - No snapping
  • Beat - Snap to a beat grid of 2,4,8,16,32,64 divisions of the sample
  • Note - Snap to the nearest musical note, this is more noticeable on small loops

The dial is split into 3 sections, the first third corresponds to Free mode and so on.

3) Snap Value - This only works when the Snap Mode is on Beat Mode, then it selects the sample division for the Beat snap. All the way to the left is 2 and all the way to the right is 64, there are 6 divisions in total.

4) Loop End - Sets the loop end point, the loop start point is also moved so that the loop size is maintained.

5) Snap Mode - Same as before but for the Loop End point, this time there are only two modes, Free and Beat.

6) Snap Value - Same as before but for the Loop End point.

The settings will be restored when you save and load any songs that have loop controls set up. As long as you don’t rename the doofers or the FX chain. You can disable this by deselecting the option in the tools menu.

Have fun!

DISCLAIMER:
Although it may look like a native tool, the performance of this will not be as good as native DSP effects, this is an inherent limitation of Lua tools. Performance may vary depending on your system, in particular offline renders don’t work very well, realtime renders seem to work fine on my system, but you may get inconsistent behaviour, the best thing to do is try it for yourself.

Download:

com.afta8.LoopControl_V1.01.xrnx (4.5 KB)

7 Likes
2

Thats awesome, Thanks!!

3

This is fantastic! Great work!

has some problems when not rendering offline - only real-time rendering worked accurately, not a huge deal though.

here’s an example of realtime vs offline with a drum loop (1st half and 2nd half)

http://soundcloud.com/skolskoly/r3noise-sample-loop-modulation-dddd

4

Cool, that sounds pretty good

I’m having problems getting offline render to work as well, real time works ok though. Because Lua scripts are run with the same priority as the GUI there is always going to be the potential for this kind of thing not always being 100% accurate.
I do remember reading somewhere about giving the GUI thread more priority which might help, I’ll look it up. The script could probably optimised more as well but for now I’m having too much fun rinsing it with my breaks collection… I need another easter holiday! :)

5

interesting - it works for now, though, that’s what counts! thanks again!

6

Especially super awesome! Thanks a lot for this doofer!! :yeah: :drummer:

7

I suppose this is a “hack” that uses observables to change other parameters ‘as fast as possible’? It might be prudent to label it as hackish in that case, since the outcome isn’t predictable in all cases.

8

Sick stuff :drummer:

9

fantastic!!!

10

brilliant tool, many thnx :drummer:

11

SUPER!
THX!!!

12

Pretty great. Always nice ideas.

13

Thanks for the great feedback everyone, also very pleased that no bugs have been found (yet)

I’m not sure I would call it a hack, I’m not using app_idle observables, just notifiers on two doofer dials for loop start and end. It seems quite consistent to me as long as you don’t do offline renders.
Surely it faces the same limitations as any tool that offers realtime performance options due to the API running in the GUI thread? Or am I missing something?

EDIT: Updated to 1.01
Just some minor code optimisations for better responsiveness, it also seems to improve offline renders but it’s still not perfect. See first post for file.

14

Its a small price to pay, I always render realtime anyway, just a shame you cant render to sample. Maybe that could be you next tool ;) .

15

I wouldn’t consider this method fully reliable or consistent (on par with the Renoise application itself), and would suppose that new users could download it unaware that it is a workaround/hack. Not only is the ‘realtime’ result unpredictable, but also the fact that people can load an .xrns where this tool has been used without having the tool installed. Not even a warning will pop up saying that the song will not sound the way it was supposed to. This is a design flaud that cannot be avoided (to my knowledge), and imo it should be considered good practice for coders to warn users that the implementation is not full-fledged.

Edit: Also, there will often be numerous of small limitations and quirks, as already discussed in this thread.

16

You just mad you didn’t make it Joule, stop hatin’ :P

17

Nope. I’m not into making tools anymore and I have nothing against this tool. On the contrary. I just raise the issue, worried that we’ll see a hackfest with new tools having unexpected limitations that are not clearly stated. That wouldn’t be good in the long run.

Edit: (ideally, there should be a framework handling warnings and popups for tools that will break song portability, render unpredictably et c)

18

Wow! Cant wait to try this:D Thank you!

19

Lol @Jonas

Interesting idea, although probably quite difficult to implement… Really I hope this becomes native in future so I don’t need to…

@Joule, I get where you are coming from, I should probably put something in the Instrument or Song comments that indicate this tool is required. However…

I disagree, I think a hackfest would be great, I don’t think any kind of tools should be dicouraged, lets have them all regardless of how hacky or unexpected they are. Ultimately those kind of things can lead to unexpected uses and insights which is worth having even if it does confuse some noobs.

User based innovation is a powerful concept that the API enables and is widely adopted in many industries, see: http://www.oecd.org/…no/37450155.pdf and http://en.wikipedia…User_innovation I think this should encouraged in Renoise with few restrictions (except the obvious ones like blowing people’s computers up or causing WW3!)

I have always been under the impression that tools come with a general disclaimer anyway. It’s not like my tools are officially endorsed, I’m just sharing things that I primarily make for my own personal use, if there are issues with these they tend to come out in the discussion anyway as we have seen here. So nothing to worry about IMO

EDIT: Also I should add, I have done realtime renders of the same loop several times with this tool and it always sounds the same, so it’s not really that inconsistent in its behaviour.

1 Like
20

@afta8, I agree totally that hackfest is good, so long as every coder is clear about it. I think this is a matter of how purist you are. Personally, I’d expect any tool to behave as if it was fully ‘integrated with Renoise’ unless anything else is stated. It should strive to behave as if it would have been a native feature (ugly GUIs set aside).

On the other hand, you can always hope that hacks like these will put some pressure on the Renoise dev(s) to implement or allow the features to be implemented properly, as I suspect they see the potential hazard in too many “hack-tools” (with no disclaimers) as well.

EDIT: I have always been clear if any of my tools were an “API abuse”, and I just want to encourage others to be as well.