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).
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: 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.
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.
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.
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
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.
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
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.
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.
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
