#22

I noticed that behavior today as well.

#23

yes, “mono” monitoring mode sets each ADC->DAC channel path to -6 db. “stereo” mode sets L->L and R->R to 0db and others to -inf db. in 1.x, all monitor paths were either unity or zeroed.

i made this change so that you wouldn’t get clipping on the monitor path in mono mode when the ADC meter levels are not showing clipping.

the levels are hardcoded in oracle.c:o_set_monitor_mix_mono() (but there’s no particular reason this shouldn’t be done in lua instead.)

also level-related: unless i’m missing something, mlr.lua doesn’t set the softcut filter mode mix levels (including dry level.) it would probably be a good idea to set those to known quantities.

if you want to tweak the overall mlr level, change the value in audio.level_cut(1) to something else, like 0.5. (this function takes linear amplitude.)

6 Likes
#24

Changing that line value to 0.5 was just what I needed. Thanks!

2 Likes
#25

Ok, so I am bit stuck on my mlr non-varibright 64 mod, if anyone wants to/have the time to help.

Current issues:

  • Tempo
    When I use alt+Q to set the tempo, the playheads does not follow the new tempo I set(same if I set the tempo in the params-menu). I am not 100% sure how the Quantize function works, so there might just be a misunderstanding of functionality here. Fixed, not an issue anymore.

  • Patterns
    I only have 1 pattern recorder at row1 column5(but r1c6 lights up when r1c5 is pressed), and I want 3 of them. 1 on r1c4, r1c5, r1c6    . Fixed, not an issue anymore.

  • Cut
    works great when the clip is played in the “normal” direction, but is 1 column off to the right when I press buttons in reverse. Edit: Did some quick testing on this again, and adding/removing the +1 in track[i].pos_grid in line 753 fixes the playhead button press position in regular playback(removing + 1) and reverse playback (keeping +1)

  • *Recall *
    I am a bit unsure of this functionality, but I am guessing that this can be remapped to the bottom row of my 64, since this is not being used for anything at the moment. So r8c1-4 for the recall functionality. Fixed, not an issue anymore.

mlr64.lua (20.7 KB)

Thanks!

1 Like
#26

thanks for the reports everyone, will be investigating

3 Likes
#27

FYI: 1 additional “bug”(might just be in my 64 script) is that I am able to make the grid light up on focus on track7, and there are 6 tracks. It throws the following error in matron(requires 2 button presses on the “track7” focus pads)

lua:
/home/we/norns/lua/core/paramset.lua:194: invalid paramset index: 7vol
stack traceback:
[C]: in function 'error'
/home/we/norns/lua/core/paramset.lua:194: in function 'core/paramset.lookup_param'
/home/we/norns/lua/core/paramset.lua:135: in function 'core/paramset.string'
/home/we/dust/code/custom64/mlr64.lua:572: in global '_redraw'
/home/we/dust/code/custom64/mlr64.lua:310: in function 'redraw'
/home/we/dust/code/custom64/mlr64.lua:606: in global '_gridkey'
/home/we/dust/code/custom64/mlr64.lua:311: in field 'key'
/home/we/norns/lua/core/grid.lua:183: in function </home/we/norns/lua/core/grid.lua:174>

Fixed by adding a y<8 boundary in line 602
if x>1 and x<4 and y<8 then

#28

Other issue I’ve noticed is looks like recording has an amplitude envelope applied to it at the start of the recording? that’s how I would describe it anyways, which result in the recorded loop not having a constant volume but slowly fading in at the start of the loop. it’s weird :slight_smile:

1 Like
#29

indeed, there is a logarithmic envelope on record and pre-record levels.

and indeed, in mlr.lua the -60db convergence time for both envelope appears to be set at 10 seconds which does seem quite excessively slow. (maybe in old supercollider implementation it was milliseconds, or something. i should clarify this in the API doc, sorry.)

i would try changing this value from 10 to something like, i dunno, 0.1 or even smaller (maybe 0.01 for a really snappy punch.) i can also see it being a useful parameter.
[ https://github.com/tehn/mlr/blob/master/mlr.lua#L375 ]

there are a couple other similar things to consider in the engine. one is how to deal with rec/pre during the crossfade; this is quite involved and there is no easy answer but you can see some of my thought process here if you are interested.

since both rec and pre are log envelopes, there is a dip in overall volume when they are set to opposite values simultaneously. i decided not to worry about this since it’s not really noticeable with short slew times. but now that i think of it, maybe a simple answer would be to make pre slew exponential, and keep the rec slew logarithmic. or something. have to play with that.

4 Likes
#30

I noticed this too but you just have to change it to full overdub. What I did was create a new default preset.

**Just saw the post above me though and am definitely going to make that change as well.

#31

Is there some type of filtering being done in softcut? I’m also hearing a pretty noticeable difference in sound on certain types of sounds recorded into the buffers when played back. Its as if there’s a slight low pass filter applied. I never noticed this on 1.0. Maybe it was the same?

#32

following up on myself here, is there a way to set a bounds for what tracks can be focused on? By adding a simple statement that throws whatever attempts of setting it to track 7?

Also, is there some way to set the Y-axis for the recall functionality when you set up the gridnav? Or will you need a separate setup for this in your code since gridnav is basically only row1 of the grid.

Currently I am trying to fix it with this code(but I keep getting errors due to the focus bug explained above)

-- recalls
local b = 2
if recall[i].recording == true then b=15
elseif recall[i].active == true then b=11
elseif recall[i].has_data == true then b=5 end
g:led(i,8,b)
  end
end

Sorry if these are stupid questions, it’s been awhile since Ive been doing any coding actively. But it feels great to at least be trying to do some coding again.

And I have to say, to the people afraid of coding, Norns/lua in itself is not difficult to grasp, especially for some reverse engineering/modification of existing code. The hard part about coding is translating “original” ideas to functioning code :wink:

1 Like
#33

yikes, thanks for spotting that. i’ll get the levels and filters cleaned up.

#34

@tehn just so that I’m not crawling down a rabbit hole without reason. The tempo/quantize settings, do they affect the actual speed of track or only pattern recordings?

#35

speed of track playback, if you have tempo mapping on for that track. pattern rec isn’t affected.

#36

ah, very clever! that clears another “bug”(aka misunderstanding of functionality/not reading the docs well enough).

#37

yes, there is a multimode SVF on the input of each voice (before buffer write.) there is also a dry path.

that’s what the softcut.filter_... functions are about.
https://monome.org/docs/norns/script-reference/

of special note is softcut.filter_fc_mod. by default,each voice filter cutoff is modulated by the rate. (this mitigates bad aliasing when slowing the rate especially near/through zero. it’s definitely not perfect and id like to tweak this in a near-future update.)

like i said just above, i noticed MLR isn’t specifying the filter mode levels / cutoff / Q / mod; i think it would be a good idea to set them on init at leasst. (some “neutral” setting like (a) just LF mode, cutoff =nyquist, RQ = big, fc mod=1, or (b) just the dry path.)

2 Likes
#38

Ah yes ok this makes sense. I suspected that it was part of smoothing the sound. Would I need to make these changes in softcut or add to MLR? Apologies if any of these inquiries are dumb. I’ve been reading the studies and am actually going to get started on them today. I have no coding experience

if I add "softcut.filter_dry(I,1) in the init section of softcut in MLR am I in the right place? And would this be how I’d get rid of the filtering? I’m just looking for a way so the buffer will match the incoming signal. The aliasing is less of an issue for me.

#39 
for i=1,4 do 
  softcut.filter_dry(i, 1)
  softcut.filter_lp(i, 0)
  softcut.filter_hp(i, 0)
  softcut.filter_bp(i, 0)
  softcut.filter_br(i, 0)
end

= 100% dry mix, so fc/rq/mod settings are irrelevant

#40

have anyone had any luck in fixing the playhead issues? I’ve been trying to do some debugging and the only thing I’ve managed to figure out so far is that x is 2 when pressing x 1 on the grid. The clip position seems to be correct if I’ve understand the code correctly.

I enabled
if n==1 then print("> "..x.." "..pp) end
In the poll callback section and pressing X1Y2 gives me this matron printout:
2.0 0.0 (and then it keeps building from there as the playhead moves along)

cannot seem to wrap my head around this. Is it a bug or some math-issue somewhere?

#41

i’ll get a change to push through a bunch of fixes (for mlr and norns generally) tomorrow.

4 Likes