from ableton? which version? Live 9 does not send start/stop over Link

see Norns: clock above

Thanks @okyeron im using ableton 10, so i think that is not the problem.
I think im getting confused with the settings of link quantum and reset, on the settings page.
What do this do?
Thanks for your help!

1 Like

Working on a test script with midi clock and seeing some weird behavior.

I get inconsistent looking timing while simply trying to make a graphic blink on the norns display in time with midi clock. I’m testing with midi clock being sent from a TR-09 drum machine over USB-midi.

In the following, the on screen box blinks OK, but sometimes stays on for more than a beat. The print output to maiden for my blink flag seems super inconsistent watching it go by in the REPL. I feel like it should be printing right on the beat, but it stutters.

issue is more apparent at slower tempos like 40-80

Am i doing something stupid/wrong here or is this some deeper issue?

test script:

local blinker = false

function init()
  midi.connect()
  params:set("clock_source", 2)
  clock.run(blink)
end

function blink()
  while true do
    clock.sync(1/2)
    blinker = true
    redraw()
    
    clock.sync(1/2)
    blinker = false
    redraw()
  end
end

function redraw()
  screen.clear()
 
  if blinker then
      screen.level(12)
      screen.rect(52, 20, 24, 24)
      screen.fill()  
      -- screen.pixel(112, 6)
  else 
      screen.level(1)
      screen.rect(52, 20, 24, 24)
      screen.fill()  
  end
  print(blinker)
  
  screen.stroke()
  screen.update()
end

Will try to test MIDI sync tomorrow, but I wonder if this could be related to wonkiness I experienced using crow clock in. Norns scripting - Link + syncing bar starts (global clock)

Out of curiosity, is there a reason you call clock.sync twice in the loop instead of doing something like this

function blink()
  while true do
    clock.sync(1/2)
    blinker = not blinker
    redraw()
  end
end

I’ve been noticing some weird clock behaviour with crow as an input. Not sure if it’s crow or the apps but Quence and Animator seem to loose or skip a pulse and this ends up messing up sync. Wondering if anyone can have a look into it?
I don’t have the coding skills to know what to look for.
Also I would really like to see a reset option for the clock. A start/stop function when a clock is present or not would be nice. Even a reset input via crow input two would work. I’m trying to achieve tight synchronised loops and delays with my sequences. Using Norns sequences and Ansible Kira together is so good until they fall out of sync. Hopefully someone can come up with a elegant solution for better synchronisation.

you can check the beat counter before and after syncing using clock.get_beats() and print those values. it might be that sync is being called after the beat you expect.

in this case, moving redraw into a different coroutine might help as it can delay blink() execution.

I did try this with redraw called from a separate coroutine and had the same result.

I’ll try with get_beats tomorrow.

redid my blinker function to this:

function blink()
  while true do
    presync = clock.get_beats() 
    clock.sync(1/2)
    postsync = clock.get_beats() 
    blinker = not blinker
    print (postsync -  presync)
    redraw()
  end
end

and I get the following with TR-09 set to 80bpm

Summary

0.097621789224945
0.49990303243544
0.49963747352945
0.50004003439756
0.499514239424
0.4994022068779
0.49969468934353
0.4997608276974
0.49980425465128
0.49967061567838
0.49977148787741
0.49985446704852
0.49962993260044
0.50117528777946
0.49757529339172
0.00075865104508921
0.4986562293235
0.00091395666697736
0.49954768557973
0.49955377981337
0.49964222414883
0.49954797328007
0.49971954212901
0.49949702408298
0.49942131070929
0.49981931264404
0.4997396413662
0.49970512230084
0.49951175137983
0.49980447878852
0.49976542215461
0.4997611420938
0.49999982653071
0.49944758919719
0.49993976230814
0.49978132203353
0.50088000946198
0.49733383049966
0.00099296762471113
0.4987628715005
0.00071735504457138
0.50006167563697
0.49922705603831
0.49983508799971
0.49976420925077
0.49949020296469
0.49963662436278
0.49976203632514
0.49978363765467
0.4997821328285
etc.

1 Like

it would be more helpful to see the actual get_beats() value before you’re calling sync, but i think you’re having the same problem as @robotfunk here: Norns scripting - Link + syncing bar starts (global clock), so adjusting the tuning might help as well. have you tried it?

1 Like

Having a really tough time with a clock-related bug in one of my scripts. For some reason, the global clock tempo keeps getting overwritten by my script in strange ways, and I can’t seem to find any clear underlying cause.

Here’s a gist of the full script:

The script inits with my two clocks disabled (it expects two crow triggers by default). Once I switch the clock source option to global clock in my script params, everything works great except for the fact I can’t for the life of me adjust the tempo value in the CLOCK menu – it keeps getting reset. If I switch the clock source to anything but internal, everything is fine too.

No pressure on anyone to take a look, but if you happen to be curious… :slight_smile:

Hi all,

I’m trying to sync my Norns and modular via an FH-1. I don’t really care which one is the master and which is the slave. As far as I understand I can send clock input to the X channel of the FH-1 but I’m not sure how to receive it in Norns. On the other hand I should somehow create a tempo synced square LFO and output it on the FH-1 which also breaks my head every time I look at any Expert Sleepers config tools.

Any advice?

Got back to this today…

Made the change to clock.c and re-running my blinker script (with print(util.round (presync, 0.0001)) to make it a little more readable) …

Here’s get_beats() pre-sync

Summary

1013.0005
1013.5006
1014.0004
1014.5004
1015.0004
1015.5003
1016.0004
1016.5004
1017.0022
1017.4995
1017.9996
1018.5004
1019.0005
1019.5006
1020.0006
1020.5004
1021.0003
1021.5004
1022.0006
1022.5005
1023.0005
1023.5004
1024.0004
1024.5004
1025.0006
1025.5004
1026.0005
1026.5005
1027.0006
1027.5018
1028.0021
1028.4994
1028.5008
1028.9994
1029.0006
1029.5005
1030.0003
1030.5005
1031.0006
1031.5004
1032.0005
1032.5006
1033.0004
1033.5007
1034.0003
1034.5006
1035.0005
1035.5006
1036.0006
1036.5005
1037.0006
1037.5019
1037.9994
1038.0004
1038.5001
1039.0003
1039.4996
1040.0007
1040.5005
1041.0009
1041.5036
1042.0004
1042.499
1042.5007
1043.0004
1043.5004
1044.0004
1044.5003
1045.0004
1045.5003
1046.0004
1046.5005
1047.0004
1047.5017
1047.9995
1048.4997
1048.9998
1049.5007
1050.0004
1050.5003
1051.0004
1051.5004
1052.0008
1052.5003
1053.0006
1053.5006
1054.0004
1054.5005
1055.0004
1055.5004
1056.0006
1056.5003
1057.0004
1057.5005
1058.0005
1058.5017
1058.9981
1059.002
1059.4994
1059.5009

here's another pass with unrounded values

125.00038107682
125.50051083379
126.0006772059
126.50048854331
127.00046182727
127.5003872255
128.00036202053
128.50055553832
129.00039845784
129.50036315788
130.0004037633
130.50042025742
131.00037066048
131.5018334103
131.99940912318
132.00065144651
132.49942393294
132.50068592023
133.00042569444
133.50036928672
134.00047920936
134.50038863495
135.00038423826
135.50040105045
136.00042457235
136.50052962025
137.00039330264
137.5004948146
138.00037107944
138.50051952601
139.00046953304
139.50056114657
140.00047175493
140.50037697773
141.00039435476
141.50171125342
141.99950295867
142.49973044423
143.00076928949
143.50053120383
144.00034713106
144.50058369549
145.00050170111
145.50037353263
146.00035846436
146.50038465707
147.00036897752
147.5005716319
148.00051806648
148.50039545151
149.00054137477
149.50039621066
150.0005700381
150.50047684109
151.00037075658
151.50178860482
151.99946190958
152.50011827762
153.00047088708
153.50002479182
153.99359897408
154.00102142561
154.46442043267
154.50043530788
154.94900238529
154.99865255172
155.00028226384
155.47582096828
155.50038580754
155.93293440423
155.99707620146
156.0002154332
156.4517201026
156.49921000974
156.50027240581
156.99200703129
157.00035776119
157.50331719612
158.01458973774
158.50779636333
159.00077533409
159.50044622877
160.00139051495
160.49926992424
160.50083222291
160.9991375898
161.00086525841
161.50045162687
162.00041570265
162.5002868069
163.00036696101
163.50033879987
164.00036985046
164.5003339111
165.00029104769
165.50036662874
166.00029886455
166.5003348234
167.00031314826
167.50059483486

At 80bpm it seems a little bit better than before, but I think I’m seeing some (minimal) slight stutters or missed beats on the screen blink.

here's some values when that happened

1463.0001
1463.5
1464.0006
1464.5001
1464.9999
1465.5018
1465.9996
1466.4992
1466.5003
1467.0006
1467.5002
1467.9999
1468.5007
1469.0001
1469.4998
1470.0006
1470.5002

1 Like

Questions:

Should these be consistent?
clock.set_source(1) - value is zero based?
params:set("clock_source", 2) - value is 1 based


The following gives me inconsistent results for tempo1 and tempo2 if I change default_bpm and reload the script
Do I need to save/write params for this to “stick”?

local default_bpm = 100
function init()
  params:set("clock_tempo", default_bpm)
  tempo1 = util.round (clock.get_tempo(), 1)
  tempo2 = util.round (params:get("clock_tempo"),1)
  print(tempo)
  print(tempo2)
end

clock docs for set_source (source) need to be expanded for link and crow

currently only shows
source integer : clock.INTERNAL (0) or clock.MIDI (1)

Also are clock.INTERNAL and clock.MIDI still valid globals? clock.MIDI returns nil

2 Likes

+1 on this. Happens with both crow and link syncing

1 Like

I’ve noticed the same thing in my script and any other that uses global clock, sync to ext is all over the place.

hey all, apologizes for the radio silence, as i’ve been working on something else. i think a few problems mentioned above might be fixed with the upcoming single-thread clock implementation, but no promises on when exactly.

the workaround (but also a good practice to follow in general), is to keep time-critical coroutines separated from the graphics and control i/o whenever possible.

2 Likes

Hi all,

As I understand clock can be only sent to one MIDI port (in system menu).
Is there a way to send clock to all midi port to synchronize more than one midi device?

Thanks!

1 Like

Yes, you can

a) send clock events (midi:clock) directly from the script to the ports you need.

b) every midi device has an IN port and an OUT port, so you can daisy-link them together to have the clock signal pass through them all.

Hope this helps!

Thanks a lot!

I try to sync a Digitakt and an O_c (captain midi).

I’ll try to use midi:clock for each port but I was more thinking about an option in clock parameters to avoid modifications in each script . Maybe in a future update.

thanks again.