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

Re: [sc-dev] Ringz+Dust issue

To: sc-dev@xxxxxxxxxxxxxxxx
Subject: Re: [sc-dev] Ringz+Dust issue
From: "Dan Stowell" <danstowell@xxxxxxxxx>
Date: Mon, 15 Dec 2008 08:34:27 +0000
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=qhCWuorrCNW88RoSSEnGP92cnE6CDgTw04fQnYie74c=; b=rVq3MvUuzpJWfPzhbRAI3RxRPcTYF5nKMQ1nit0ao3wFPAppI1tXDwqUsoiXxPXqE/ fNrAcaO0GunKiJyMT/lbc9iYRc79Db7NmwuY9qyV3k7K6GyCKZ+dZMCOS6cOrjlQ7Cug 7Z9tVUZf30CtjAXxRBPNbXjJiItC+7hbmvJqI=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UtdCMPBvTE815G7Bv6Z6rVR5EI6NXZfzTArA0tAv4+NKcNqXLRNr+QZ8ynJKZMnUN3 cRBKOXTD18bcZl/YfZ39CNGhD7Nyz46gPHNXGot6jZHQ0cbAULEY10Sa1IUQQ0wP/2QR ZtepWT0/yEOrYwbwqzHg03ChgnmC2BeatTU+4=
In-reply-to: <524BD864-09D1-49FA-A697-CFC0569A4312@xxxxxxxxxxxxxxxxx>
List-id: SuperCollider developers mailing list <sc-devel.create.ucsb.edu>
References: <286e6b7c0812141209m6d018b77xf70007ed986f7980@xxxxxxxxxxxxxx> <50F5DF5C-EF4C-4B83-859F-4C82399050BB@xxxxxxxxxxxxxxxxx> <286e6b7c0812141353o68c9654ax9d88fea45a4c6429@xxxxxxxxxxxxxx> <D81B49CB-0524-45F3-9C90-6E04900ABEDC@xxxxxxxxxxxxxxxxx> <286e6b7c0812141442g60f986fy430337979f2d87a4@xxxxxxxxxxxxxx> <130A7CF5-8B8F-4B2E-BB1D-0E8CA803C56A@xxxxxxxxxxxxxxxxx> <286e6b7c0812142338q2df58cdcsd6fd8ad426de187@xxxxxxxxxxxxxx> <E57C58AF-C034-4915-BF20-833214094110@xxxxxxxxxxxxxxxxx> <286e6b7c0812142349p3e83c437p30d4b1aad2c5d1cb@xxxxxxxxxxxxxx> <524BD864-09D1-49FA-A697-CFC0569A4312@xxxxxxxxxxxxxxxxx>
Reply-to: sc-dev@xxxxxxxxxxxxxxxx
Sender: owner-sc-dev@xxxxxxxxxxxxxxxx

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 ;)

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?

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/

Follow-Ups:
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter

References:
- [sc-dev] Ringz+Dust issue
  - From: Dan Stowell
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter
- Re: [sc-dev] Ringz+Dust issue
  - From: Dan Stowell
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter
- Re: [sc-dev] Ringz+Dust issue
  - From: Dan Stowell
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter
- Re: [sc-dev] Ringz+Dust issue
  - From: Dan Stowell
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter
- Re: [sc-dev] Ringz+Dust issue
  - From: Dan Stowell
- Re: [sc-dev] Ringz+Dust issue
  - From: Josh Parmenter

Prev by Date: Re: [sc-dev] SF.net SVN: supercollider:[8135] trunk/Source/plugins/FilterUGens.cpp
Next by Date: [sc-dev] SF.net SVN: supercollider:[8137] trunk/build/Help/GUI
Previous by thread: Re: [sc-dev] Ringz+Dust issue
Next by thread: Re: [sc-dev] Ringz+Dust issue
Index(es):
- Date
- Thread