cv channel refresh

  • what´s the story with only one cv channel update per audio frame? is that a technical limitation or a module design decision?!

  • i believe it's due to the timing of sending SPI data to the DAC on the cv-outputs. there is some propogation delay before the data takes effect so if you try and send all 4 sequentially, packets get lost (or something like that).

    the sample rate is still 12kHz so not terrible if you're doing waveform synthesis. is there a particular use case this is restricting? you could use the 4 main outputs though you'll need a level booster to interface with a modular.

  • its a technical limitation.

    blackfin has to wait for tx to complete on a channel before sending next channel.

    in waves/lines, there is not enough time left in the frame to do this for all channels, every frame. (SPI clock is much slower than core clock.)

    opted for this simple solution instead of a tricky "multithreaded" one. (after considerable hair-pulling.)

    i'd like to make a new set of modules that uses block processing, ameliorating this issue (and others,) while adding a little latency (8 samples or so.) next on my list after bees editor.

  • also, you are welcome to try a full update in each frame if you are making your own module. it could work if you're not doing too much else in the frame.

    in that case you might want to use a different update mode for the cv DAC. (so, using a custom cv.h / cv.c , rather than the ones from bfin_lib.) get your scope and logic analyzer out.

    i'd be super interested to hear any results from this.

  • thanks both of you, it sounds good now again, one full update per channel and frame was the key!

  • awesome!!

    are you sharing the code? i'd love to check it out

  • sure, latest upload is tagged 'beta002': app and module

    hopefully it will turn into a cv sequencer with selectable algorithm per step, time/curve/destination kind of envelopes. just added the curve select functions but the algorithms so far are just dumb. in the todo is improving the sequencer (edit, play modes) and of course, adding the envelope parameters(!) to it, also more/better algorithms, would be cool to try lfo/audio rate too! :)

  • Can't wait to check out this patch. :)

    Loving the sequencer developments, more the merrier.

  • this looks really dope. looking forward to checking it out with some hardware.

    if you ever feel like it's in a good place to share, feel free to put in a pull request and we can put it in the upstream repo, link from the wiki, whatever...

  • just uploaded "003 beta", not ready for a pull request yet but it´s getting there (though functional level is OK if anyone would like to try it out!) :)

    mainly these things:
    fixing the linear curve algorithm with slope as a function of time, will have to educate myself a little on this one before I can get it done, plus do some more tests on looping curves

    adding a "wav-curve", found some libraries in the white whale skeleton that looks interesting, for those moments when it makes perfect sense to go from a dc filter slope on step 3 to a 909 chip sample on step 4 and a digital noise burst on step 5, thru the same output, worth a try anyway...

    tweak the external clocking/play mode, got it to ok again after adding all the curve parameters, basically it´s 6 parameter locks per step now so something(s) needs to be done to get it back up to some serious "SID-thrill" action :)

  • first tests with rec&play curves playing audio rate stuff thru cv outputs, very beta moving rec position only on every 4th frame so it should be possible to get better sample rate still !

    short update:
    added "headroom" to the rec-curve so it does not have to distort like in the video, (shifting >> 10 sounds best to my ears without too much drop in output volume) tried 4 buffers, recording short sounds to each, recording one channel at a time (rendering all channels per frame) works without glitch but playback without glitch only if still one channel/buffer is sounding at a time... a bit of a bummer because the same glitch appear both when rendering one channel and all channels per frame. will do some more tests later!

  • ok, here comes a very silly question but I just can't solve this (it's true!) I´m trying to send a simple parameter value to the bfin but the values jump 0,1,2,3,4,5,6 and then 10,11,12... so how do I send 7,8,9?!

  • hm, that's indeed... surprising!

    can you describe the steps you're taking in a little more detail?

    my guess: you send integers from the avr32 like,

    ctl_param_change(i, 5);
    ctl_param_change(i, 6);
    ctl_param_change(i, 7);
    ctl_param_change(i, 8);

    and then, one hopes, module_set_param() is called with those arguments.

    then what happens? you observe value argument is wrong at this point? how do you observe it?

    in other words, how can i replicate?

  • man, I´m stupid, it was just print_fix16 showing some strange values, I got the bfin to respond as I hoped it would :) I guess firing up that ol' debugger once in a while will do me some good !

  • oh, good!

    one thing i should mention in this thread: you should feel free to try other modes of controlling the CV DAC (AD5686), replacing relevant functions in bfin_lib/src/cv.c, init.c with sources in the module folder. (just don't mess with the core clock config! wrong settings there can smoke the DSP.)

    in bfin_lib/src/init.c:init_sport1() , you can see that i did a whole lot of messing around. strangely, the clock waveform definitions of bfin SPORT, and ad5686, really don't jive. the only way i could get it to work was by setting it to a nominal 25-bit packet to make the clock idle state come out right.

    but anyways... it should be possible to perform the update more efficiently, by using the TX complete interrupt to trigger the next channel.

  • sounds cool, I will check that out! just added an audio output mode too for the sample based "curves" and that works nicely. some tinkering left to do but first beta is getting closer! :)