Mlr (norns)

shellfritsch · 2019-06-21T18:20:08.584Z

ok i was able to ssh in via wifi, tried journalctl -b -1

> 192.168.1.40 ~ $ journalctl -b -1 
> 
> Specifying boot ID has no effect, no persistent journal was found

marcus_fischer · 2019-06-21T18:31:26.559Z

That is the same with me. The midi on my 16n is problematic. It worked like a dream at first but now won’t work. It shows up on my computer and in Norns but no messages can be sent. Sometimes it starts working again and other times it won’t.

shellfritsch · 2019-06-21T18:38:13.470Z

interesting. i’ve used 16n with midi a lot (via ableton) with no issues.
recently i switched i2c to “master” mode for direct use with the er-301… i wonder if i that is connected to this issue. when i just reflashed the 16n firmware i disabled i2c master mode and it’s working fine (so far!).

have you tried reflashing the firmware to get midi working again?

zebra · 2019-06-21T19:11:08.095Z

ok sorry for the red herring, I’ll work on the correct invocation

andrew · 2019-06-21T20:38:53.572Z

teeny bit of portasound and mlr-ing from my trip to norns

lanserdj · 2019-06-26T00:51:19.534Z

Yes. That would be so great.

lanserdj · 2019-06-26T00:58:30.251Z

Can anyone explain to me how to use midi sync? Struggling to find an answer through the thread. Ideally would like to tempo sync mlr with Ableton. Sorry for repeating a question that seems to have been asked 1000 times - just seems like i’m missing something here. (And maybe a better question is whether or not a solution through ableton link has been generated??).

kasselvania · 2019-07-07T21:16:06.878Z

Does anybody have a method of using the original GrayScale Grid 128 with this (circa 2010)?

Prnts · 2019-07-07T22:15:13.017Z

@kin.sventa uses a non varibright I’m fairly sure

kasselvania · 2019-07-07T22:34:41.809Z

Oh dang! Through code adjustment? I’ll send him a message. Thanks!

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.