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:
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.
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.
- Start playback
- Start sending in external clock messages
- Fouplay suddenly speeds up drastically (often up to 2x)
- Start playback (easiest to notice if there’s only one note per loop, and a short loop length)
- Will randomly drop beats
- 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
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?
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.
I think this is the same issue I have been dealing with here: Crow/norns/clock question
woof, thanks for the bump. setting some time aside today to try and build the world’s most solid repro cases
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)
- connect to maiden
- attach a MIDI clock source to norns
- nav to EDIT > CLOCK and choose
- ensure the tempo displayed matches the expected tempo
- run the script
- script starts by truncating the current clock beat number and assigning it to a variable
- 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
expected results: in the repl, the integer of the left value (clock beat) matches the right value (
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
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
- 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
Hi. Norns shield.
test case 1: incoming MIDI clock
control: internal clock is fine at 130bpm
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
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
245.00071475266 247 245.99589237837 248
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.
Thanks @dan_derks Would scripting this be a beginner task?
And/or would this post be considered a feature suggestion. Or should be done elsewhere?
Edit to say I will add it to the Norns Ideas thread
it’d for sure be a great intro to learning the menus and the heuristics of system-level features. i recently did some work on extending MIDI device management to 16 devices, which did take a little bit of time poking and cross-referencing – much of the challenge for me was learning the dependencies across different files – but is 1000% doable and will really highlight the moving parts of norns
all to say, it’d be great to have feedback on the feature request ticket either way. if you’re interested in working on the problem, @csboling’s guides to contributing to the main norns codebase (compiling + extending) are excellent and the community can help fill in the gaps
Thanks for the reply and opening the feature request Dan. I will investigate this over the coming week but given some life matters atm I actually can’t see me getting anywhere with it. Thanks for the encouragement though
Just cross posting this to see if anyone here has a solution?
I noticed it still seems like an open issue on the github page. I’m having more sync issues with the latest update. It may have been like this for a while as I normally make slower ambient sounds, which make sync issues harder to hear, but yesterday I wrote some more rhythmic/percussive based stuff and could clearly hear sync issues between norns and ansible being clocked by PNW.
Really hoping this can be resolved.
Id love to see a more solid external sync and access to a global transport with some sort of reset.
hey sorry, i saw this and then we emailed and i totally spaced on replying here
i know this one is frustrating. essentially, investigation is still underway – there was a change released in december 2020 which didn’t end up solving all cases. a solid set of repro cases have been logged and we’ll definitely keep folks updated as work develops! for now, clocking from norns (if possible) is the best approach. this has been logged, tho, and won’t get lost (it’s part of feasibility scoping for norns 3.0) – thanks for the patience + bump
(script authors can also bypass the norns system clock and listen directly for incoming crow pulses or midi clock messages when using those clocking methods – this is a workaround until the core library has been addressed)
as far as transport goes, methods are now outlined in the clock studies for script authors: clocks - docs. this is pretty much the method i used to add a global transport to cheat codes. if you have a favorite script that you want to talk to the transport, it’d be best to raise as a feature request with that author.
Thats all good, I didn’t want to bog down our emails with Norns clock issues
Good to hear things are still in the works. Cant wait for this to be fixed properly.
I do try to keep my sync set up the same for studio to live performances which means running Norns as master isn’t ideal. I do love having a dedicated start/stop button as well as using all crow outputs for sequencing but i’ll give it a shot and see if its any better as a work around for now.
Quick question: Is sync via Link solid and can I send out clock from crow?
Your transport implementation in Cheat Codes is awesome!
Would love to see it in all scripts but I’ll make a few requests to the authors of my favourite scripts ad see what they say.
Thanks for continuing to work on this, very much appreciated
Sync via link is super solid. Norns always takes the lead and changes the ableton clock when it first connects but no other issues. Haven’t tried crow yet in this format. I’m Just sending clock from ableton straight to eurorack via midi and to Norns.