Re: [sc-dev] Ringz+Dust issue

["Dan Stowell" <danstowell@xxxxxxxxx>]

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/