[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Ringz+Dust issue



On Dec 15, 2008, at 12:34 AM, Dan Stowell wrote:

2008/12/15, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
OK - the Ringz fix and macros are added. Quick test with your Ringz example
is pretty now.

Yep. And Batuhan's example too - fixed after only a few months ;)

Yes... good catch on the problem!

2008/12/15, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
Hmmm... I wonder if this needs to be altered as well:

unit->mRate->mFilterSlope

Hmm, I'm not sure - looking at the code of Ringz and friends, it looks
like actually the mFilterSlope value is only really used inside the
mFilterLoops loops, whereas our recent workaround stops those from
running. So no change may be needed to that val?

No, it doesn't need changing.

Best,

Josh

Dan


On Dec 14, 2008, at 11:49 PM, Dan Stowell wrote:


Go for it.

Do you happen to remember, eg for BEQ suite, was ClearUnitOutputs an
explicit decision?

Dan

2008/12/15, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:

yep! looks great! I can commit to Ringz tonight and add the macros...
then
let's see what can get done in the next day or two.

Best,

Josh


On Dec 14, 2008, at 11:38 PM, Dan Stowell wrote:



Josh,

Yes, this is like what I was thinking of. Two thoughts:

* The mFilterRemain should also be explicitly handled - if blocksize
changes, we can't guarantee it stays at 1
* It's probably worth putting this in a macro, since many other
filters use this loop syntax and so probably need the same fix...? (In fact, lots of filters seem to init by using ClearUnitOutputs, which
probably means they're vulnerable to the Impulse.ar gotcha?)

Something like

#define PUSH_LOOPVALS \
    int tmp_floops = unit->mRate->mFilterLoops; \
    int tmp_fremain = unit->mRate->mFilterRemain; \
    unit->mRate->mFilterLoops = 0; \
    unit->mRate->mFilterRemain = 1;
#define POP_LOOPVALS \
    unit->mRate->mFilterLoops = tmp_floops; \
    unit->mRate->mFilterRemain = tmp_fremain;

Seem OK?
Dan


2008/12/15, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:


Ooops... left out a line:

   int tmp = unit->mRate->mFilterLoops;
   unit->mRate->mFilterLoops = 0;
   Ringz_next(unit, 1);
   unit->mRate->mFilterLoops = tmp;


Josh

On Dec 14, 2008, at 2:42 PM, Dan Stowell wrote:




Ah, I see, the old Impulse.ar(1) gotcha!




it should probably do everything next does, except output




Creating output is not a problem, in fact I think it *should*
create
output (so that things further down the chain initialise
properly). A
workaround/solution could be to *temporarily* change the
mFilterLoops
and mFilterRemain values in the unit->mRate struct to represent a
1-sample blocksize, which would allow the calculations in
Ringz_next()
all to drop through correctly without requiring large amounts of
extra/duplicated code.

I'm going to bed now but can look at this in the morning, that is
if
someone else doesn't get to it first ;)

Dan


2008/12/14, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:



I am remembering parts of this now... Below creates the problem




where




Impulse.ar(1) misses that first sample.

Dan - I think the solution may be to create another next (or




'first')




function that calculates the first sample. Basically, it should




probably








do




everything next does, except output. This way, the initial
sample




and








filter




state is still calculated, but the mFilterRemain is avoided. My




guess








is,




when called with one sample (after the Ctor) the pointers are




accessing








junk




in the server memory.


Josh


On Dec 14, 2008, at 1:53 PM, Dan Stowell wrote:






2008/12/14, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:




On Dec 14, 2008, at 1:26 PM, Batuhan Bozkurt wrote:




Somehow Ringz.ar remembers its past state...






Like I said, this would indicate to me that some memory
isn't






being












init'd






correctly.

I'll look it it later.





Josh, I had the same feeling as you, but as JH points out
Ringz
doesn't use RTAlloc. It correctly initialises all its
variables,





as





far as I can tell.

I think I have found the problem. When the Ringz ugen is
created,





it





calls Ringz_next() but with a blocksize of 1 (this is standard





ugen





init procedure). However, the iterations which look like

LOOP(unit->mRate->mFilterLoops,
...
);
LOOP(unit->mRate->mFilterRemain,
...
);

assume that the blocksize is what it normally is (i.e. 64, for





most





people). This causes the looping to write outside the memory
that





it





should do (and probably therefore leaves garbage around to





"remember"





inappropriately).

I'm not sure how best to fix this. One way is that the
constructor
could call ClearUnitOutputs() rather than trying to run





Ringz_next(),





which from my testing does prevent the nasties. Not sure if
this
change would have bad side-effects...? What do you think?

Dan


_______________________________________________
sc-dev mailing list

info (subscription, etc.):












http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml









archive:






https://listarc.bham.ac.uk/marchives/sc-dev/






search:




https://listarc.bham.ac.uk/lists/sc-dev/search/








******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

"Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether
actively




or




passively, consciously or unconsciously, he makes choices in
this




regard. He




may be conservative or he may subject himself to continual
renewal;




or








he




may strive for a revolutionary, historical or social
palingenesis."




-








Luigi




Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.):









http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml






archive:




https://listarc.bham.ac.uk/marchives/sc-dev/




search:




https://listarc.bham.ac.uk/lists/sc-dev/search/










--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.):






http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml




archive:



https://listarc.bham.ac.uk/marchives/sc-dev/



search:


https://listarc.bham.ac.uk/lists/sc-dev/search/






******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

"Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively
or
passively, consciously or unconsciously, he makes choices in this


regard. He


may be conservative or he may subject himself to continual renewal;
or


he


may strive for a revolutionary, historical or social palingenesis."
-


Luigi


Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.):




http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml


archive:


https://listarc.bham.ac.uk/marchives/sc-dev/


search:


https://listarc.bham.ac.uk/lists/sc-dev/search/







--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.):


http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml

archive:
https://listarc.bham.ac.uk/marchives/sc-dev/
search:

https://listarc.bham.ac.uk/lists/sc-dev/search/




******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

"Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively or
passively, consciously or unconsciously, he makes choices in this
regard. He
may be conservative or he may subject himself to continual renewal; or
he
may strive for a revolutionary, historical or social palingenesis." -
Luigi
Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.):

http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive:
https://listarc.bham.ac.uk/marchives/sc-dev/
search:
https://listarc.bham.ac.uk/lists/sc-dev/search/




--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search:
https://listarc.bham.ac.uk/lists/sc-dev/search/


******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

"Every composer – at all times and in all cases – gives his own
interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi
Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.):
http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/



--
http://www.mcld.co.uk

_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/