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

Re: [sc-dev] Ringz+Dust issue

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/