#77 bug in shuffle makes the cpu go into 100%

externals (234)
João Pais

due to a bug on [shuffle], after a value is sent to the
2nd inlet, at the end of each cycle the cpu will go
into 100%. I don't know exactly what's the relation
between the parameter values to bring the bug (if
there's any), but the bug seems to be consistent. no
special patch is necessary, it happens also on the help

XP, Pd-Ext 0.39-2-t3.



  • IOhannes m zmölnig

    Logged In: YES

    even though no "special" patch is necessary, could you give
    an example patch that reliably triggers the bug.
    (i never used [shuffle] before and i don't know what to do
    to make it behave as you describe)

  • João Pais

    João Pais - 2006-09-19

    Logged In: YES

    Sure, here it is. But I just noticed that the following
    conditions should be met to trigger the bug:
    the new "upper" value must be lower than the previous one,
    and, possibly, also lower as the present output of shuffle.
    it works for sure with extreme values (change from 0-20 to
    0-5, f.e.), but not always with subtler changes (0-5 to 0-

  • João Pais

    João Pais - 2006-09-19
  • Martin Peach

    Martin Peach - 2006-09-19

    Logged In: YES

    This seems to happen because shuffle_bang() doesn't know
    that the end point has changed. Only sending a float to the
    first inlet updates the arrays to match the new begin.
    Probably shuffle_ft1() and shuffle_ft2() should set a
    'dirty' flag so shuffle_bang() can redo the pointers if
    shuffle_ft1() or shuffle_ft2() have changed a parameter.
    The shuffle_update() routine would be the same code as
    shuffle_float() except for the first line, so I would
    propose taking that code out of shuffle_float() and calling
    it shuffle_update().



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks