Noticed today that Clock system does not understand Swing, any swing amount is ignored. I was using crow to clock Norns so perhaps it has something to do with crow? Would be great if this could be implemented in the next update, will give the patterns more funk and life 
Thanks!
1 Like
since this came up in another thread, reitrating: this needs to be part of a script’s logic since there is no universal definition of what it “means” to reset the sequence/process whatever.
i wonder if there is utility (e.g., turn those 22 lines into 2 lines) for baking a “reset” handler into the clock API… somehow.
hmm… AFAIK we just respond to PPQ ticks. is there a standard for “swing” that tells us to post-process the PPQ stream in some way? who would be sending us this “swing” value and how? or are you proposing the addition of a swing parameter at the norns system level? (ed: sorry just re-read: you want the clock coming from crow to be “swung” or “shuffled” in some way, i think)
AFAIK, the concept of “swing” in DAWs and e.g. MPC sequences, means: process a sequence of notes such that some rhythmic unit is subdivided asymetrically - for example, eight-notes to dotted-sixteenths (or triplets or something in between.) in other words, it is a musical transformation defined by a sequencer. (not actually a property of a low-level clock.)
and given that assumption, it seems to me that sequencers can easily implement swing by calling e.g. clock.sync(0.75 /4)... clock.sync(0.25 /4)... instead of clock.sync(1/8)...
(or, more broadly, clock.sync((0.5 + swing) / 4)... clock.sync((0.5 - swing) / 4), with swing in [0, 0.5)).
(at least, that’s my understanding of what “swing/shuffle” usually means. could get a lot more granular / weird of course.)
maybe relevant too: at one point we considered adding the ability to metro to use a sequence of durations instead of a single duration. wasn’t convinced this was a sensible point of abstraction though.
if there is a general call for “clocks” to encapsulate more musical logic outside of what scripts do with them, then that could be sort of a bigger discussion; could do a lot more than swing/shuffle.
5 Likes
Thanks so much for adding this and writing out all the details to achieve it. I had a look at the updated Awake but couldn’t quite get it to work how I imagined. I also looked at trying to add a crow input to reset the sequence but I think it’s a just a little over my head at the moment.
I wish I had the knowledge because I know I could achieve many ideas if my coding was upto scratch. I might need to do some study.
1 Like
for sure!
gotcha, makes sense. can you spec out what exactly you want the script to do? i think that it’s important to not let the “it’s mostly there” stuff die out, you know? if we can land on a set of parameters that scripts should ideally incorporate through this process, it’d be time well spent
so, what’s your ideal?
Definitely agree that we shouldn’t let “it’s mostly there” stuff die out.
Norns would really benefit from a solid clock system with start/stop and reset functions for the internal clock, link, midi and crow.
At the moment I think most things work well besides crow. I use crow 99% of the time when using Norns.
Not to digress too much but I still find syncing Norns with crow a little unstable with some apps.
Talking about the reset, what I’m ultimately wanting to achieve is that apps reset to step one of a sequence once a clock stops.
As input one on crow is used for clock, input two makes sense as a reset input just like on Ansible. But for me the issue with using input 2 for reset is some apps might use that input for other functions and I think it’s important to keep it free for that sole reason.
So I’m thinking there are a few things to achieve.
- Have the Norns clock detect if the clock (internal, link, midi or crow) has stopped and therefor reset to the start.
- An option to enable this reset function or not.
- Have Norns send Link info when internally or externally synced (this is a very specific use case as I recently got a second Norns and would like to sync one via crow and have it send Link sync to the second crow).
Hope that explains it a little better.
1 Like
cool, this is helpful to have laid out, thank you!
fwiw, stopping and resetting isn’t the duty of the norns clock, tho. the global clock should never stop — it is a fundamental timing heartbeat rather than a transport (side note: ohh, a global transport actually might be the right framing for the feature you’re requesting!). so, it’s up to each script to kinda create their own transports – to listen for external “stop” messages and to have a plan for what to do when it receives such a message. it’s also up to each script to define what it considers a “reset” and what it should do when it receives one. we can help standardize this with a clear example and more visibility of this standard in the documentation, so more folks can include these functions in their scripts.
re: crow syncing, i’ll follow back up on this thread tomorrow: Crow/norns/clock question
re: Link, that’s trickier — from what i understand, Link isn’t a “destination” or “source”, but more like a conversation between equals. i don’t think that you can send Link data without also listening to it, which becomes complicated in a system with only one clock. @artfwo will have much more concrete things to say about whether this is a norns-solvable issue or just the way the Link protocol works.
5 Likes
Ah right, that makes sense re:global clock and I think you are onto something with terminology and concept of a global transport.
This would make it a lot easy for people to implement into their apps, especially with having it standardised.
Excited to see if we can get something like this happening. Having solid sync and reset on Norns would be great running side by side with other sequencers like Kria.
Appreciate you looking into the crow clock stability.
Keen to hear what @artfwo has to say about Link. Totally understand if it’s not possible. My end goal with that is to sync 2 Norns while 1 is being clocked via crow so it would be nice to have that option as sometimes I want to use my second crow with ableton.
1 Like
link allows sending sync data from a single node to the network, but it’s not yet implemented in the norns API. but even with a working implementation it will still require some manual adaptation of the scripts for the use-case you described:
1 Like
I would like to add my vote to the general call for “clocks”. Tighter more reliable clocking across the board would make Norns so much more playable in less experimental contexts. Cheat codes with a start/stop/reset function would be a dream.
3 Likes
I’m seeing some very strange behavior when sending MIDI clock to my norns (201202)
tl;dr: norns system clock works fine, except when being driven by external device’s MIDI over USB. But, when being driven by external MIDI, the clock will be wildly out of time. Sometimes with consistent scaling, sometimes with random drift… kinda hard to pin down. Doesn’t matter which external device (Logic Pro X, Hermod).
I’ve tried it with a few different scripts: Awake, Cyrene, and Foulplay.
With Foulplay:
- Start playback
- Start sending in external clock messages
- Fouplay suddenly speeds up drastically (often up to 2x)
With Awake:
- Start playback (easiest to notice if there’s only one note per loop, and a short loop length)
- Will randomly drop beats
With Cyrene:
- Tempo is roughly steady but approximately 14% faster
Has anyone else seen similar behavior? It’s driving me bananas
It seems relatively similar to Crow/norns/clock question but Crow isn’t connected in any of these test cases. I’ve also tried completely removing all references to Crow from Cyrene and that doesn’t help
2 Likes
I find it syncs to clock ok (I’m sending from an MPC X) but I’m finding that none of the scripts (tried Awake, Meadowphysics midi, Buoys and Arcologies) seem to reset with midi stop/start which makes syncing not great. Anyone know whether these scripts should restart?
1 Like
Ive experienced lots of clocking issues, mostly with crow. For me what the biggest issue is some clock pulses get skipped which messes up timing and no start/stop or reset makes it very difficult to properly sync with my modular or midi gear.
Id ideally like to see a more stable global clock system with start/stop and reset.
1 Like
woof, thanks for the bump. setting some time aside today to try and build the world’s most solid repro cases
5 Likes
ok, here’s some MIDI clock testing. if anyone can verify they’re experiencing the same on their unique hardware, that would be very dope.
test case 1: incoming MIDI clock
load script and run with maiden open: test_case_1-midi.lua (213 Bytes)
setup:
- connect to maiden
- attach a MIDI clock source to norns
- nav to EDIT > CLOCK and choose
midi - ensure the tempo displayed matches the expected tempo
- run the script
script details:
- script starts by truncating the current clock beat number and assigning it to a variable
count - a coroutine is established
- the coroutine uses
clock.sync(1)to sync to each beat - each beat increments the
countvariable by 1 - each beat prints the current beat number
- in theory, these two values should remain the same (understanding that the printed clock beat might be
+0.00xahead)
expected results: in the repl, the integer of the left value (clock beat) matches the right value (count)
control: I ran this script with internal clock and got the following expected output (tested for 500 beats)
2990.0006277402 2990
2991.0005184111 2991
2992.0001214273 2992
2993.0006991944 2993
2994.0003110648 2994
2995.0003726984 2995
2996.0004916714 2996
2997.000117394 2997
2998.000491057 2998
2999.0001529897 2999
3000.0003470107 3000
3001.0005175358 3001
3002.000120727 3002
3003.0002333857 3003
3004.0004611609 3004
3005.0004396816 3005
actual results: clock steps are somehow double-tapping, which double-increments the count value
1181.0002472464 1181
1182.000157767 1182
1183.0018666615 1183
1183.9966417216 1184
1184.0018485279 1185
1185.0002404991 1186
1186.0002296293 1187
1187.0005070127 1188
1188.0003569899 1189
1189.000229808 1190
1190.0024096313 1191
1190.9967660519 1192
1191.0018336364 1193
1192.0001773595 1194
1193.0008779371 1195
1194.0000049084 1196
1195.0005623592 1197
1196.0002397995 1198
impact:
- if a script uses a coroutine to advance a counter to determine a 16-beat bar, then the counter would hit 16 beats at the 14th beat
- if a script is just simply re-triggering a synth voice on a steady pulse, the voice is re-triggered and sounds accented
3 Likes
Hi. Norns shield.
test case 1: incoming MIDI clock
control: internal clock is fine at 130bpm
control data
64.000498784 64
65.001215816333 65
66.000731702833 66
67.000696154333 67
68.000727074833 68
69.001187489333 69
70.000920833333 70
71.000677759333 71
72.000930878 72
73.000338654333 73
74.0013128635 74
75.000600799333 75
76.0007706335 76
77.000330754667 77
78.000923654333 78
79.000335833333 79
80.000931779333 80
81.0010387585 81
82.000322066333 82
83.0006537245 83
84.0011196705 84
85.000334817167 85
86.000709921333 86
87.0003406845 87
88.000933020833 88
89.000879983 89
90.000891943 90
91.000939791667 91
92.0008144175 92
93.001166728333 93
94.000381422167 94
95.000730459167 95
96.001008290833 96
97.000955253 97
98.000445408167 98
99.001171016167 99
actual results: double-tapping on MIDI clock source, an OP-Z ticking along some smooth dub-techno at 130bpm
actual data
215.99951759669 216
217.00161491518 217
218.00020028496 218
219.0020879911 219
220.00085409773 220
221.00047282712 221
222.00186216184 222
223.00012752244 223
224.00130228343 224
225.00066495229 225
225.99878745762 226
226.0007453255 227
227.00168842145 228
228.00113541492 229
229.00085247609 230
229.9995416018 231
231.00054948129 232
232.00091352133 233
233.00115271745 234
234.00159865667 235
235.00090865234 236
236.0008994969 237
237.00078143123 238
238.00110441334 239
239.00069429909 240
240.00128343537 241
240.9973829834 242
241.00069978574 243
242.00021073753 244
243.00192248963 245
244.00065384899 246
245.00071475266 247
245.99589237837 248
246.01530550327 249
247.00152688021 250
248.00027160829 251
249.00100139173 252
250.00093903397 253
251.0006500109 254
252.00071630049 255
253.00120423151 256
254.00120752775 257
255.00092298605 258
256.00092994818 259
An observation is that the second tap comes very close to the next tick, at least in this data, (e.g. below) and that shared by @dan_derks above
229.00085247609 230
229.9995416018 231
and
245.00071475266 247
245.99589237837 248
2 Likes
this is the exact behavior i’m seeing 
the clock reads the correct bpm, but the actual pace of advancement is about 14% faster (16 beats in the span of 14). if you want to have a fun time, try altering the test script to use different BPMs. In my experience, the error is bigger in some places, and smaller in others. I think the error is minimized right at 100 BPM 
which may be a hint as to what’s happening under the hood? Or just random chance
An opportunity for some fun fun fun regression analysis statistics 
I read above that midi clock can be daisy chained. I am wondering though if midi clock is available at more than one usb output? Specifically, I have a usb midi device and a midi din device with a usb to din converting interface so ideally I’d just like to set up Norns clock to output on two ports, or assign two devices to one port. Is this possible (my midi knowledge is basic by the way)
@21echoes + @xmacex, thank you so much for testing + confirming! i’ve also confirmed this same behavior with crow as a clock source. internal and Link seem to test well, so the issues seems specific to those two sources. logged the issue.
up next: testing clock sent out via crow
@yoyosandshoes, multi-device midi clock output is not available through the system menus, no. this could be accomplished with some scripting (or daisy chaining your midi devices), but I agree that it’d be a good feature for the norns system.
6 Likes