• Nicolas Danet

    @whale-av I think you are right. IIRC [vline~] accept a list of breakpoint that could be used to make multiple ramps inside the 64 sample range. Need to be tested. Anyway i'm not very confident with that since i removed that object in my fork (it has no sense in a parallelized world).

    posted in technical issues read more
  • Nicolas Danet

    So every object with a [v ...] will be sampleaccurate on point in upcoming audio-blocks, as long as it is not needed more often then 64 samples later!??? i.e. as long it is not starting several times in a smaller interval then 64 samples?

    I guess, but i'm not 100% sure (tests are required). I didn't remenber precisely how [vline~] is implemented thus its behaviour in reblocked cases. IMHO if you want sample accurate operations, everything should be stay in the DSP context as far as possible. I mean use only DSP objects and all is always in synch.

    posted in technical issues read more
  • Nicolas Danet

    The tricky stuff with real time audio is not to do the things fast, but do things fast at the right time. Wait the sound in, deliver the sound out, compute the next sound and wait. When i benchmark my fork for instance, most of the time is spent in sleeping!

    posted in technical issues read more
  • Nicolas Danet

    As already noticed, proceed the control messages and compute audio vectors of the DSP graph are interleaved operations. The internal audio vector size is 64.

    [64][control][64][control][64][control][64][control]
    

    What's happen in a 1 sample reblocked subpatch? In short, instead of compute 1 vector of 64 samples, it computes 64 times following a vector of 1 sample.

     [1][1][1]...[1][1][1][control][1][1][1]...[1][1][1][control]
    

    AFAIK, no messages is trigger faster than (very) roughly 1 ms (and that is true for the metro object also).

    posted in technical issues read more
  • Nicolas Danet

    @lacuna

    How could you close the source of a running patch?

    Somebody could make an external to do that.
    For fun i thought about various approaches (but TBH none really perfect).
    Anyway even if i could do one, i would not do it!

    posted in Off topic read more
  • Nicolas Danet

    @ingox (IMHO + IANAL) (for two above cases) you are right! ;-)

    posted in Off topic read more
  • Nicolas Danet

    I never said i'll do the job! Of course i could help but i don't have the time to be the fearless leader. :-)

    posted in technical issues read more
  • Nicolas Danet

    If the 2.0 version "will be a complete rewrite and overhaul" < https://llllllll.co/t/karma-1-0-sampler-looper-external-for-max/481/73 > IMHO it is probably best to manage Pd compatibility directly in the rewrite? Instead of doing the work again and again.

    posted in technical issues read more
  • Nicolas Danet

    @ingox Nobody really knows! @Rannug Yes you can.

    posted in Off topic read more

Internal error.

Oops! Looks like something went wrong!