Mlr (norns)

kburwash · 2019-07-08T00:38:44.630Z

Would it be possible/hard (easy?) to add a filter to each track in MLR?

zebra · 2019-07-08T01:29:01.058Z

Each voice has an input filter, for Reasons. Output filter is on my list and not hard

kburwash · 2019-07-08T01:32:40.770Z

Ya, I think I’m looking for output, since my usual use is loading up clips. It’d be nice to be able to filter them. I’m sure you’ll beat me to it as I’ve spent barely any time programming at this point.

zebra · 2019-07-08T01:33:56.166Z

I’ve been saying this for months and will just sit down and add the output filters to softcut tonight, it really is not a big deal.

update: pushed and PR’d the addition of post-playback filtes to softcut. this is completely untested (except that it compiles and doesn’t crash) and of course not integrated into MLR script. posting in case anyone watching here wants to pitch in before i get to finishing it off (soon, but probably not today)

github.com/monome/norns

[WIP] Softcut output filters

by catfact on 03:55PM - 08 Jul 19 UTC

2 commits changed 8 files with 337 additions and 146 deletions.

swhic · 2019-07-08T17:20:33.498Z

any chance increasing the buffer length per track? thanks

zebra · 2019-07-08T17:35:09.309Z

not if you’re gonna eyeroll at us.

change this (must be a power of 2):

github.com

monome/norns/blob/master/crone/src/SoftCutClient.h#L19


#include "Bus.h"
#include "Utilities.h"
#include "softcut/SoftCut.h"
#include "softcut/Types.h"


namespace crone {
    class SoftCutClient: public Client<2, 2> {
    public:
        enum { MaxBlockFrames = 2048, NumVoices = 6 };


        enum { BufFrames = 16777216 };
        typedef enum { SourceAdc=0 } SourceId;
        typedef Bus<2, MaxBlockFrames> StereoBus;
        typedef Bus<1, MaxBlockFrames> MonoBus;
    public:
        SoftCutClient();


    private:
        // processors
        softcut::SoftCut<NumVoices> cut;
        // main buffer

and this:

github.com

tehn/mlr/blob/master/mlr.lua#L35


local g = grid.connect()


local fileselect = require 'fileselect'
local textentry = require 'textentry'
local pattern_time = require 'pattern_time'


local TRACKS = 6
local FADE = 0.01


-- softcut has ~350s per buffer
local CLIP_LEN_SEC = 45
local MAX_CLIPS = 7


local vREC = 1
local vCUT = 2
local vCLIP = 3
local vTIME = 15


-- events
local eCUT = 1
local eSTOP = 2

iincreasing buf size for softcut leaves less RAM for user engines. incuding potentially RAM-hungry popular ones like Timber, Glut. in general, running out of RAM while loading samples in one of these engines will produce inexplicable errors in the user experience (unless/until we try and make a special mechanism to capture them from supercollider.)

~350s for each softcut buffer means that softcut process is using about ~135MB or ~25% of total RAM in the system. there is still ~580MB available for engines, over 50% of system. if that balance is deemed conservative, the change is simple enough for basically anyone to make, and @tehn as the project leader can decide if it’s a good idea on balance for the upstream master branch.

alternatively / additionally, the MLR script could assign buffer regions to clips differently. AFAICT all voices use only the first buffer (there are now two buffers, b/c this was requested of me a while back), so MLR could (say) increase the count of clips from 7 to 8, put 4 clips on each buffer. each clip would be 75% longer. would require the script to redirect voices to buffers when assigning clips to voices.

personally, i am not gonna make changes to MLR script and will limit my contributions to the underlying C++ engine.

swhic · 2019-07-08T19:54:10.059Z

@zebra didn’t mean to, sorry mate, sorted it now!
don’t need more than 45 sec per track, but how can I record 45 secs per track?
@tehn any thoughts? thanks (no emoticon)

tehn · 2019-07-08T20:38:12.370Z

indeed, it was my plan to have the tracks alternate buffers and hence double their length. most dev time has been focussed on the core, i need to prioritize this script— and this issue is a good start @swhic — i’d already made an issue back in april https://github.com/tehn/mlr/issues/11

@zebra this is a general device question, but you know i love softcut and would be happy to give it more memory (50% would be fine by me) but we can discuss this further…

shellfritsch · 2019-07-08T21:48:32.566Z

swhic:

don’t need more than 45 sec per track, but how can I record 45 secs per track?

my current workaround to get longer buffer lengths is to set all my tracks to follow tempo, then turn the tempo down all the way, then set the speed of a voice an octave or two lower and record with it there. it still gives me some room to pitch things down enough for my needs. the audio quality drops slightly, but i don’t mind

zebra · 2019-07-08T21:56:00.785Z

swhic:

don’t need more than 45 sec per track, but how can I record 45 secs per track?

gotcha

well, AFAIK, here is where grid presses are used to set loop endpoints:

github.com

tehn/mlr/blob/master/mlr.lua#L747


      e = {} e.t = eSTART e.i = i
    end
    event(e)
  elseif y<TRACKS+2 and held[y]==1 then
    first[y] = x
    local cut = x-1
    --print("pos > "..cut)
    e = {} e.t = eCUT e.i = i e.pos = cut
    event(e)
  elseif y<TRACKS+2 and held[y]==2 then
    second[y] = x
  end
elseif z==0 then
  if y<TRACKS+2 and held[y] == 1 and heldmax[y]==2 then
    e = {}
    e.t = eLOOP
    e.i = i
    e.loop = 1
    e.loop_start = math.min(first[y],second[y])
    e.loop_end = math.max(first[y],second[y])
    event(e)

so… each space on the grid is hardcoded to 1 second at rate =1, is that right?

seems like a scaling factor for mapping grid location ->time, would be a really useful parameter and not too hard to add. (well… eh… i guess it would get a little complicated scaling the phase update as well. maybe just limited to integers)

and (also AFAIK, haven’t really tried) it seems like a workaround would be loading a longer clip, assigning track to clip, and enabling record on the track.

swhic · 2019-07-09T07:36:09.348Z

zebra:

and (also AFAIK, haven’t really tried) it seems like a workaround would be loading a longer clip, assigning track to clip, and enabling record on the track.

thanks, yes I’ve tried that and works most times, depending on the loaded clip length. I guess if the loaded clip is longer than 45sec it occupies the next track or something I don’t quite understand…

zebra · 2019-07-09T08:10:26.872Z

hm, it shouldn’t do that.

looking at MLR commits, i see this one on april 22

before which, it looks like it would not crop to the clip region boundaries when loading a file. (which could be an interesting behavior too, but w/e.)

have you updated to the latest version?

kin.sventa · 2019-07-10T22:34:25.050Z

i do use a non varibright grayscale 128 with norns mlr. i haven’t adjusted code or anything, just a small piece of tape to signify the reverse column. it works perfectly for me. for me, mlr feels incredibly intuitive and fun to play even with the non varibright grid.

static · 2019-07-11T03:42:00.720Z

Not sure if it had been mentioned by anyone else yet, but I have been wishing that there was a way to MIDI map the record button to control with a MIDI controller like the Faderfox UC4. That way we could maybe have a momentary button press quickly engage and disengage recording, or a footswitch to sort of punch in and out. I suppose this stems from a desire I have to engage or disengage recording while I’m on the cut page.

Slightly related to this - it’d be great to somehow have control of the overdub level of a given track from the cut page… but I guess that’s already possible with a MIDI controller, no? This could serve as a workaround for the record button… just engage record and then modulate between the lowest and highest overdub value, is that correct? Is that how overdub works, or would it be a different result due to the way that softcut works?

Okay one more wish. Tap tempo… maybe even one that starts the clock!? Either way, I am searching for a fun and natural method to simply get things rolling. Maybe I’m asking for a few more traditional looper like features, but at least they’d be optional. It’s been a nice change from my usual approach using MLR in this current form, but also a bit of a challenge for me to make something more structured, especially without having the record button quantize optionally. With that said, thanks everyone for your hard work. I hope that my feedback helps somehow!

kasselvania · 2019-07-11T08:27:47.253Z

I have been having an odd issue where the okay button does seem to begin the play head. I thought this was possibly because of the grid.

shellfritsch · 2019-07-12T23:42:34.522Z

Anyone have midi sync working with mlr? Trying to send clock into oplab’s host in port with no luck.

LLK · 2019-07-12T23:57:03.513Z

I’d like to know when that’s working! Would be very nice.

shellfritsch · 2019-07-13T00:10:14.129Z

Agreed. Would love to sync this up with some other instruments for live looping

Prnts · 2019-07-13T00:51:03.576Z

shellfritsch:

Anyone have midi sync working with mlr? Trying to send clock into oplab’s host in port with no luck.

I’ve sync’d up my octatrack with it. Currently Norns has to be the master clock for sync

okyeron · 2019-07-13T01:04:10.639Z

your midi device where you want to send clock would need to be in DEVICES>MIDI slot number one on norns.