[PD-dev] [ pure-data-Bugs-1540259 ] bug in shuffle makes the cpu go into 100%

[SourceForge.net]

Bugs item #1540259, was opened at 2006-08-14 18:21
Message generated for change (Comment added) made by mrpeach
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1540259&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: João Miguel Pais (jmmmp)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in shuffle makes the cpu go into 100%

Initial Comment:
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 
patch.

XP, Pd-Ext 0.39-2-t3.

Joao

----------------------------------------------------------------------

Comment By: Martin Peach (mrpeach)
Date: 2006-09-19 11:20

Message:
Logged In: YES 
user_id=919007

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


----------------------------------------------------------------------

Comment By: João Miguel Pais (jmmmp)
Date: 2006-09-19 09:23

Message:
Logged In: YES 
user_id=1523458

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

----------------------------------------------------------------------

Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-09-18 13:19

Message:
Logged In: YES 
user_id=564396

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)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1540259&group_id=55736