aleph as cv clock - timing issues

  • okay, when I make a simple clock such as:

    METRO -> TOG -> CVn

    occasionally I'll hear a skip in the timing. i.e. I don't always get a straight clk out, the timing is more like

    da da da da da da dada da da da da

    is this caused by aleph calculating cv or is there another reason? normally I'm not doing straight 4/4, so it's not a big deal. still, I'm curious...

  • do you find the timing is generally solid and it skips a beat occasionally, or is it generally inconsistent? if the former, does the 'skip' happen at a regular interval or is it more sporadic?

  • it's generally solid with sporadic skips, metro period seems to have some effect, but I haven't noticed any obviously repeating pattern

  • what rate is the METRO at?

    are you in PLAY mode? are there a lot of screen refreshes happening?

  • I'll do some precise METRO rate tests tomorrow...

    but, yeah, I'm in play mode and yes all the cv out action shows up on the screen, so lots of refresh

  • idk I can't reproduce anything consistently

    sometimes it's consistent across a lot of METRO period, sometimes not. right now I'm getting a weird pattern at 236, before that I scrolled through a wide range of speeds without much problem

    although I'm noticing that if I change the period in edit mode everything is very solid, but I'm in play mode with an encoder mapped to the period thing get weird.

    I'm also noticing that if I split an encoder to two different METRO->TOGS they don't stay synced

  • EDIT: had one clock running in edit mode (nothing updating on the screen) while I typed the above. METRO period at 130. it's 'skipped' maybe three times in last 4-5mins. weird

  • thanks for the feedback. screen updates definitely can bog the timing, we've been discussing a prioritization system.

  • So I figured out what the problem is and have already been in contact with tehn about it, but I'd thought I'd post here anyways.

    The problem is noise present at the cv input in lines giving me an arbitrary on/off value of 1.

  • ok good to know

    wish i had better 0-10v environment to test with right now.

    in the meantime, we can surely narrow it down a bit.

    do you mean that there "indeterminate" CV input value when no CV input connected? i guess if that's the case it's not super surprising to me and in general i wouldn't use a CV input patch without an actual source of voltage potential (including, in the most trivial case, a connection from ground to - or whatever.)

    anyways, contact me directly too, i'm curious: emb@catfact.net

  • "indeterminate" CV input value when no CV input connected

    Yes, exactly. Although it's there when input is connected as well, it's just added to the value. That's why it was messing me up with triggers and not continuous values.

    The weirdest thing is it's only present in lines. I can't reproduce it in waves.

  • "it's just added to the value"

    Actually maybe that's not true. I need to go back and test now. Could just be present when the clock is low like when nothing is connected.

  • Okay it definitely behaves normally if a sine lfo is present.

  • I just wanted to update update this thread:

    I still have not been able to get a consistent METRO pulse out of the aleph using the following METRO -> TOG -> MUL -> CVout

    issues with noise at cv inputs have been sufficiently resolved, but even with cv-in disabled output pulses will occasionally skip a beat. there is no repeatable pattern that I can notice

  • an idea would be to add a separate "empty" SPI message for trig/metro duties only and a separate trig function (needs to be added to each module too) If this is called inside adc polling directly, and if the adc polling is set to 1 it is possible to trig the bfin up into audio rate, about 500 hz. one potential issue is that it lives outside the event buffer but it works... I have some code in the prgm project that maybe could be added into bees or act as an embryo to something...

  • man, @Test2 I am not good enough at this to do any of that :)

  • I could try to mess with the metro to have it send a separate trig message, but it would go outside the other operators/the network, it would be a fixed connection: custom metro -> spi -> custom module function -> cv output trig. would that be useful?!

  • hmm... ideally I would want it within the network to be able to clock internal parameters and other bees things as well. essentially I'm building sequencer like scenes that send cv and gate out

    an easier workaround is just to clock the aleph from outside, but having a single master metro just seems so much more eloquent

    plus I would still like to know what's going on, the metro never seems to skip when it's routed to anything other than the cv outs

  • ah, well the thing with the cv outputs is that only one channel is calculated per frame, so maybe it would be more useful to look at that, I guess you want to be able to use all cv outs, I could try and just modify the module cv calculation a bit to see if that can improve things, that won't affect the network/connectivity. Is this just "lines" still or is it waves too!?

  • Just lines. But I will double check waves as well. In a perfect world I would want to generate cv and use the aleph as a delay, so getting it solid in lines is more important

  • have something (lines) that compiles, just need to do a basic test with audio/cv, will post if it works on a basic level.

  • Thanks! Any luck yet?

  • heya sorry for lag

    i think the reason for this is that avr32 waits on bfin for processing. in other words, from avr32 perspective sending control signals is a blocking operation. and: on the blackfin side, sending CV out is done at the end of each audio sample. so sending a METRO to cv out is the worst scenario.

    i'm curious as to what actual bad situations you encounter, though. i regularly use Aleph as a 10v cv output source, while testing testing development for 10 v modules , and i have no problems there.

    but, i'm not typically using it for other simultaneous stuff. more data would mean better focus, whenever i get around to rewriting everything.

    (and: this will surely happen sooner or later unless someone beats me to it.)

  • the only bad situation is that I can't use the aleph to generate rhythm, especially 4/4, without some extra unpredictable beats sneaking in. so it cant be a master timing device

    unless I clock it from outside. that seems stable

    basically I've been experimenting with replacing my sequencers with just the aleph, so as to slim down the gear I travel with

    using it as a 2 x cv-gate source at the same time as a cool delay seems really economically exciting, but maybe I'll just have to settle with using it as one or the other

  • added it here at the top of the page temporarily:
    http://monome.org/docs/aleph:bees:sharing:tracker

    it´s not optimized but meant as a test version, I don´t know how well it will play with existing scenes, but audio is hardwired to output1,2 (audio 3,4 are off) and cv to cv-output3,4 (cv 1,2 are off), there are parameters for this but changing them is not supported yet, I just wanted to be able to confirm their settings when running a test. sorry it took so long, I accidentally named the module file to "lines", apparently it needs to have the same file name as the "module-name", saved you some trouble at least!

    anyway you are most welcome to try it out when you find the time!

  • rhythm wise i'm still really lusting after the ability to clock a delay time to a METRO or TIMER object accurately, still a bit hit and miss with the divide by 2 option. but we have to wait for a direct ms input value option on Lines for that :) fingers crossed

  • an idea, an event operator that would output its own spi message to the bfin, an empty message that calls a module_trig_event function directly, so it would be limited to a specific use at a time, but then it would be possible to have a parameter that selects different possible "uses", like delay time, output cv clock etc... I'm not sure about this but the thinking is that it would give faster response between sending and receiving (less data size), it would not battle with other parameter changes, maybe adding some kind of priority filter on this message to always stay on top before any parameter changes...