Idea for a new MLR-alike tool

Renoise Tools
1

I have always wanted to produce a tool which would work simularly to mlr, but as a native Renoise tool *
But instead of just starting to hack away, I think it would be interesting to ask this community for ideas and input.

Basically, I would like the basic mlr functionality to be there: one or more continuously playing loops which you have control over + grouping of loops.
I have previously created a variation on this concept, based on rotary knobs instead of buttons (Notes On Wheels), however the whole mlr style sequencer lends itself much better to a grid controller.

A great thing about doing this in Renoise is, that unlike the original (Max/MSP-based) mlr script, we would record everything directly into a pattern, thus creating a song while improvising.

–

  • For those who have no idea what mlr is, it is a very popular performance tool/script which has grown from the monome community
    This page contains a quick description of the basic workflow: http://monome.org/docs/app:mlr

Artists like Daedelus does absolutely crazy stuff with this software. Check this recent video to see him pushing the boundaries of loop based music:

2

Pretty good idea, and basically everything for this is already available in Renoise I guess!
I don’t have a Launchpad or similar at all though.

How does the grouping work in mlr? And what exactly happens at a button press is still a mystery to me? :)
Anyway for implementation in Renoise this would be like “set all samples to autoseek”, “write pattern data” “write pattern data” “compute 0Sxx value” “write pattern data” “write pattern data”. Or is there more?

3

Sounds like a cool idea. I had no idea what an MLR sequencer was. Found this whilst finding out, perhaps it might help…

4

@Cas: yes, I also believe there’s nothing important missing in terms of API access.
The live-recording aspect of mlr (which is strangely not mentioned on it’s homepage) would however need a bit of customization from the person using this tool.

The grouping/muting is a question of samples getting organized into groups. Inside each group, only a single sample can play at any time.
In a practical scenario, grouped samples are a nice way to organize similar sounds - e.g. a lead guitar sound - into a single “sound entity”.

And each group then has it’s own volume and mute that you control - so no access to individual sample levels (although you could of course have that in Renoise).

As for what exactly happens when you press a button - mlr has some clever tricks. But basically you set the offset, with the sample being quantized to a certain offset.

5

So, here are my first drafted specs!! “mlr-x” - yes, I would like to have the “mlr” in the title somehow…

mlr-x.png?raw=1

mlr-x
inspired by tehn

When application is first started

  • if not already specified, the application will create a top-level group called “mlr-x”, containing four groups - one for each mlr-x group. It then adds (number of visible tracks on controller) as tracks to the first of these groups (the default group). It will then proceed to to scan the list of instruments and determine which ones are compatible (instruments with multiple samples are ignored).

  • whether or not the mlr-x group was already created, tracks that are named after an instrument will immediately appear on the controller (if there is room).

  • if the mlr-x group was already created, a child track named after an instrument will automatically be assigned to a group, based on it’s position. This facilitates automatic the recreation of an mlr-x session.

  • when an instrument is renamed, mlr-x will automatically add the sound to, or pull it from, it’s pool of sounds

  • each mlr-x sound is divided equally (time offset) across the available horizontal buttons

  • for newly assigned sounds (when a track has just been given a matching name), the default transpose is computed so that the sound “roughly” plays at it’s original tempo (best guess, similar to how sample-sync works in Renoise).

  • if an instrument’s sample has been sliced, mlr-x will instead use these as offsets (starting from the first one)

  • number of simultaneous samples are limited to (number of visible tracks on controller)

  • number of groups are limited to 4
    b]How to use it

  • hit play in Renoise. This will cause mlr-x to start writing data into the pattern

  • hit a trigger button to trigger a sound at a specific offset (using quantize)

  • hit a trigger button + hold the retrig button to repeatedly trigger the sound (using quantize + edit step)

  • use group stop/mute buttons to prevent sounds from playing (having immediate effect)

  • for each group, only a single sound can play at the same time - triggering a sound within the same group will stop the previous sound as the new one starts
    Trigger buttons

  • press a trigger button to set playback position to the offset (using quantize)

  • if no sound was playing in that group, the selected sound will start at the specified offset

  • if a sound, assigned to the same group, was already playing, that sound will stop

  • hold retrig + press a trigger button to output the sound repeatedly, using edit-step as the interval, for as long as the retrig button is held
    Group buttons

  • press a group button to toggle the mute state of that mlr-x group and stop note output

  • muting is done with note-off commands written into the tracks themselves

  • a muted track can continue to display a dimmed position on the controller (if enough colors)

  • briefly press to toggle mute state on the group (resuming playback from where it left)

  • press + hold an active group button to stop the group from being able to resume (shut up)
    Overlay buttons

  • In general: hold an overlay button to temporarily display extra information, such as sound volume, group matrix etc. While displayed, the overlay will prevent any changes to the trigger buttons beneath it

  • Group matrix

    • Press any button to re-assign a sound to that group. The actual track is immediately moved from the old to the new group.

  • Nudge

    • Nudging means to slightly offset the time of a sound by a positive or negative amount. Nudging is based on the track delay, so no more than +/- 100ms is possible

  • Transpose

    • Transpose will apply the given amount of transpose to the instrument, relative to it’s current basenote (when a session is imported, the instrument’s default transpose value is automatically computed)
    • +12 / +1 : increment current transpose by an octave, or a single semitone
    • -12 / -1: decrement current transpose by an octave, or a single semitone
    • reset is a one-shot which will reset to the default tempo/transpose. Briefly hold the button to specify a new default value

  • Volume

    • Volume will allow you to adjust the volume of the given instrument, independently of the mlr-x group mixer. Use this, if a single sound needs to be adjusted to fit the overall mix
      Technical implementation
      For a four-group, five-instrument session, the Renoise track/group structure could look like this:

  • mlr-x (group-track)

  • 01 (group-track)

  • instrument 00 (track)

  • instrument 03 (track)

  • 02 (group-track)

  • instrument 02 (track)

  • 03 (group-track)

  • instrument 01 (track)

  • instrument 04 (track)

  • 04 (group-track)

mlr-x groups - defined as four group-tracks located underneath a top-level group called “mlr-x”

  • on startup, an mlr-x session can recreate the group matrix from the structure of the tracks contained within these groups

mlr-x samples - defined as a track bearing the same name as an instrument

  • volume/panning/nudge amount is applied to the mlr-x mixer
  • setting transpose to “something” means offset it by a number of semitones (in case the instrument is sliced, the transpose amount needs to be applied to each slice as well)
  • output to a track which correspond to it’s group, and then the index of the instrument itself.
  • in tracks, note data is written into a single note-column, using a combination of computed sample-offset and note-delay commands. This should ensure a high degree of precision, even when triggering instruments with a very long duration across an uneven number of lines (which could be the result of some special transpose amount)

Goals, for the longer term

  • live recording of external audio, creating new samples on the fly
  • ability to define a loop within a sound (however, this would not be saved as part of session)
  • sliced instruments could have individual transpose per slice? too darn complex

changing the tempo to avoid that the tempo is changed in a way that will cause samples to go out of sync with one another, changes to the tempo could use the pattern-write scheduler too (outputting ZT commands with specific intervals)

6

Looks like a well thought out plan. I have used mlr a bit in the past, it’s great at what it does. I was kinda hoping that this one would go one step beyond mlr, and handle midi-sequences as well, but I can see how this would complicate things.

You didn’t include a way to change between “sets” in your draft? Perhaps one could add several top-level groups, mlr-x_1, mlr-x_2 and so on and switch between?

Anyways, looking forward to this. Especially the long term goal of live recording would be really useful to me personally.
PS. Just don’t forget about blinking led state in GridPie. ;)

7

Hey, the equivalent of saved presets? Cool idea!

I guess for each of these groups, you’d be able to specify an alternative set of sounds, or even re-use existing ones (but possibly in new group combinations), that sort of thing could easily be saved in such a preset.
And it would even be simple to collapse an inactive group (slash preset), so it doesn’t get in the way of using the pattern editor.

The only downside I can think of is, that DSP chains wouldn’t be synchronized among different presets.
But then, being able to have different DSP chains for each preset could be even be seen as a feature?

Regarding blinking lights: Aha, yes, planning on doing that update to Grid Pie soon…I’m basically warming up for the coding season :slight_smile:

8

Yes that’s the word I was looking for. It’s called presets in mlr.

Too bad you can’t put groups within a group. But there’s always send tracks. Or one could use several identical dsp chains mapped to the same midi cc I guess. Not a big issue IMO.

Hehe, I’ll keep on nagging till I get me some disco lights the monome.

9

Ah, but you can :slight_smile: at least, it won’t become a problem until you put something like half a dozen groups within groups.
I’m just a bit concerned that it would become hard to manage.

Consider this:

mlr-x  
- preset 01  
- - group 01  
- - - instrument 01  
- - - instrument 02  
- - group 02  
- - - instrument 03  
- - group 03  
- - - instrument 04  
- - group 04  
- preset 02  
- - group 01  
- - group 02  
- - group 03  
- - - instrument 01  
- - - instrument 02  
- - - instrument 03  
- - - instrument 04  
- - group 04

Versus this

mlr-x  
- group 01  
- - preset 01  
- - - instrument 01  
- - - instrument 02  
- - preset 02  
- group 02  
- - preset 01  
- - - instrument 03  
- - preset 02  
- group 03  
- - preset 01  
- - - instrument 04  
- - preset 02  
- - - instrument 01  
- - - instrument 02  
- - - instrument 03  
- - - instrument 04  
- group 04  
- - preset 01  
- - preset 02

The only difference is where the preset group is inserted, but each approach introduce some pros and cons of it’s own:

For example, imagine that you want to remove, or duplicate a certain preset? With the first approach, it’s really just a question of locating the actual preset group.
In the second example however, the preset groups are spread across the whole place, making it much harder to do. And I suspect, programming it would become harder too.

But the first solution also has it’s downsides…primarily, because mlr-x would need to manage send tracks for each group, as you point out.
Each preset would contain it’s own copy of the groups 1-4, so each of these groups should transmit audio to just one final destination.

Hmmm…I’m starting to think that the second approach is in fact the best.
It would be more flexible in terms of adding/controlling FX to a improv session.

10

I just tried to recreate the second approach (see my post above) in Renoise.
Using collapsed tracks, and completely hiding inactive presets to make it as compact as possible:

mlr-x_tracks.png?raw=1

(I think that all tracks created by this tool should initially be set to the collapsed state, after which the person using it can choose to expand, or not).

11

Great! I normally don’t use grouping, and I did it wrong when I tried.

Yes the second approach seem like the smarter solution. No need to mess with send tracks, and you could still add dsp per preset, so that “feature” won’t be lost. Nice!

12

I would’ve thought mlrx>preset>group>track

I do think you might be wanting to do too much at once with this tool though. I would start with no support for fx devices, maybe send tracks. Also, no whole sequences/chords of notes at all, just samples triggered at C-4 and looped. The basics in my eyes should be the writing down of pattern (I think it’s just easier than having renoise play notes via OSC) and even the live recording should be doable. The smaller/custom loops within a sample are very doable this way (writing in pattern).

I have one question; how are the groups and samples layed out on a monome/LP grid? One group viewable at a time?

13

You are of course right. The original mlr is a study in simplicity, and various spin-offs have then expanded on the original formula.

With this particular tool, I’m interested in doing something which will integrate nicely with Renoise as it is. And the concept of presets are kind of pushing this, as they start to introduce extra stuff into the song which is merely used to represent the tool’s configuration. However, I think presets are important enough to consider…so, maybe it was time to actually embed configurations into the song itself, as it has been done with some of the more advanced tools around - such as your Overtune tool. Something I’ve tried to avoid in the past - but the less this tool needs to “take over” Renoise, the better.

On the monome, all you see are rows of sample-offset triggers, one row per sound. The buttons are highlighted as playback progress through a sound.
You don’t “know” which sounds belong to which group before you trigger one and another one stops playing - then you’d know that both belongs to the same group (however, since you did assign the sounds to specific groups yourself, we can assume that this isn’t a problem, unless you have problems with short-term memory :wink: . And on a controller like the Launchpad, each sound could even be painted using it’s group-color).
The ability to use groups to organize your sounds means that you never have more than 4 sounds playing at once (even if the limit of 4 is an artificial one, it seems like a good choice)

Also, each sound can have a different length, which will result in a different playback speed (but matched against a master tempo). In Renoise, I’d think the best solution would be to set the song to 1 tick per line, and use samples which were synced to the master BPM. Using 0Uxx/0Dxx commands would then allow you to instantly pitch samples up and down within quite a large range, but still based on a master tempo. Otherwise, your recordings would all be messed up if you decided to change the BPM later on.

14

So, if we decided to get rid of “preset groups” as a method for describing the layout
(instead embedding this info in the song, somehow), this is what the track layout could look like:

mlr-x_tracks_II.png?raw=1

The idea is, that instead of having the connection between similarly-named tracks and instruments, each group now represents a “pool” of tracks that each preset could then use (or not).

In the image, it’s easy to conclude that A1-A3, and B1 + C1 are active. Also, we can derive from this image that at some point, a total of seven sounds was assigned to group A. However, the current preset is only using the first three tracks.

Also, the group tracks themselves are no longer collapsed. This “sort-of” indicates that you are free to enter effect commands, or DSP effects as you please.

15

Aha, with this method one could re-use tracks in different presets… Nice!

I was pondering about the layout, that maybe I’d prefer a vertical layout with the control column to the left. To keep things consistent with track layout in renoise. I’m not sure if there are any drawbacks, for instance ergonomically… Can’t think of any right now anyways.

16

Expanding the specs with some additional thoughts on pattern recording, quantize, looping and track selection

–

Pattern-recording starts when a sound is first triggered. Until then, the controller will display any previous recordings (dimmed down, if possible) - this is simply helpful for locating points in time for the sounds you are hearing.
Of course, Renoise needs to be playing before any of this is possible.

Once recording is started, the application will continuously record - replacing any existing content - into it’s track(s), for as long as there are any actively playing sounds in mlr-x. In other words, you can record “just one beat” by pressing a trigger and then hitting the group mute button just after it started recording (as both start and stop are quantized)

A relevant question here would be: with something as free-form as this, where does quantize even apply? For example, what if we are recording into patterns with a length of 64, but we have selected a (granted, strange) quantize value of 24? We could make a logic that would count backwards from the starting point of the recording, and adding those number together - so we’d get a note on line 00, then 24, 48, and proceeding into the next pattern: line 8, 32 and 56. However, I think it would be better to rely on the way Renoise behaves and count from the beginning of each pattern. Then it would be up to one self to define a pattern with a sensible number of lines for any given application (poly-meter rhythms, or just downright strange values). A big advantage of this simpler approach is, that if you decide to add anything to a previous recording the quantize would work precisely in the same way, no matter which pattern you start on, or for how long it has been playing.

As for pattern boundaries and loops, the application will automatically detect if there is a pattern/block loop defined, or if it has reached the end of the current pattern, and is supposed to write pattern data into the next one. In any case, it will produce a continuous output, unaffected by these factors.

As for track selection: when a sound is triggered for the first time, it’s name will be attached to the track receiving the pattern data. Later on, if we trigger the same a sound, the application will choose to continue recording into the same track as before. This should make it easier to separate sounds from each other. The sounds are associated with a track in the order that they are recorded, and not the order in which they appear in the instrument list.

17

Dude, this is amazing! I started using Mlrv recently(Yeah, i’m late,I know!) and I wished something like that existed in Renoise. I would pay for it even. What I don’t like though about the original mrl is that you can’t play unquantized, you can in Mlrv but the pattern recorders are buggy. I’m a drummer and I like to mix fast triplets,ruffs and mix various polyrythms and when you play quantized, you’re limited. Actually yesterday I tried Pd_mlr and I like it more than the Max version. There’s also the Google plugin one and a Vst version but they’re not that good. But a Renoise version could even attract Monome-heads to Renoise.

18

I’ve just started actual work on this tool, so thanks for chiming in with some extra input :slight_smile:

Agree about the ability to record un-quantized, but (at least to begin with) I think the closest this tool will get is to offer quantize for each line.
Obviously, raising the lines per beat (LPB) in Renoise could then be used for obtaining a higher precision.

Apropos “ruff”, that’s a drummer technique similar to a short roll, right?
Because, I had been thinking about a button (retrig) as a way to easily create such short bursts of notes, implemented as a “modifier button” which you would simply hold while triggering any of the sounds. For the finger-drumming challenged among us, this would be really useful :slight_smile:
To more precisely match the effect of a ruff/roll, such a sequence of notes could even be made to fade out (I guess, with the default being not to fade out).

19

A little progress report: I have now pieced together enough code to be able to say “jam session”.

Recording at 180bpm, 8lpb with no major hiccups. Two modes so far, one that loops a sample (or a segment of a sample), and one that allows finger drumming (playing sample offset for as long as button is held)
Both modes are quantized to whatever Renoise is set to, and the script is just using whatever instruments you feed it.
The script is designed to handle looped patterns, pattern sequence loops without you noticing. Hell, I even “beatmixed” two loops, by changing the pattern length from 64 to 63 and back. Some really creative stuff is possible :slight_smile:

So far, so good. Ironing out some timing issues took quite some work, and it’s still not 100% perfect - I always underestimate the complexity of these scripts?
But I expect a preliminary release to arrive soon. I just need to implement the group logic (limit each group to just one sound), then you are all invited to test-drive this thing!

20

Yay, the first release has now arrived :slight_smile:
I created a different topic for it, located here

However I will continue to watch this thread for input and ideas