Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

server plugins: Gendy*: fix initialization bug #2331

Merged
merged 1 commit into from
Sep 14, 2016

Conversation

nhthn
Copy link
Contributor

@nhthn nhthn commented Sep 10, 2016

The original bug is described here: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/Gendy-instability-td7627785.html

This is kind of an odd way of fixing the bug, and we should discuss it. The standard method would be to write Gendy*_next_k(unit, 1), but that results in a behavior change that removes the first sample of output. Try running {Gendy1.ar}.plot(1e-3) and you'll see what I mean.

The standard is Gendy*_next_k(unit, 1), but that results in a behavior change that removes the first sample of output.
@nhthn nhthn added this to the 3.8 milestone Sep 10, 2016
@danstowell
Copy link
Member

It's fine. It doesn't matter for a synthesis UGen, it can do what it wants. It would be a wrong fix if this were a filter UGen because it would be dropping data from the inputs. Here it's fine

@nhthn
Copy link
Contributor Author

nhthn commented Sep 10, 2016

Can you comment on whether this is a correct mathematical model of how the Ctor sample works? #2322 (comment)

@crucialfelix
Copy link
Member

Original bug confirmed, fix confirmed.

s.record; 

{ LPF.ar(Gendy1.ar) }.plot(0.01); 

Deadly bug that kills speakers and ear drums:

screen shot 2016-09-14 at 08 22 42

Nice work @snappizz !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants