{"action":"created","issue":{"url":"https://api.github.com/repos/monome/aleph/issues/271","repository_url":"https://api.github.com/repos/monome/aleph","labels_url":"https://api.github.com/repos/monome/aleph/issues/271/labels{/name}","comments_url":"https://api.github.com/repos/monome/aleph/issues/271/comments","events_url":"https://api.github.com/repos/monome/aleph/issues/271/events","html_url":"https://github.com/monome/aleph/issues/271","id":187215692,"number":271,"title":"SVF topology review","user":{"login":"catfact","id":94855,"avatar_url":"https://avatars.githubusercontent.com/u/94855?v=3","gravatar_id":"","url":"https://api.github.com/users/catfact","html_url":"https://github.com/catfact","followers_url":"https://api.github.com/users/catfact/followers","following_url":"https://api.github.com/users/catfact/following{/other_user}","gists_url":"https://api.github.com/users/catfact/gists{/gist_id}","starred_url":"https://api.github.com/users/catfact/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/catfact/subscriptions","organizations_url":"https://api.github.com/users/catfact/orgs","repos_url":"https://api.github.com/users/catfact/repos","events_url":"https://api.github.com/users/catfact/events{/privacy}","received_events_url":"https://api.github.com/users/catfact/received_events","type":"User","site_admin":false},"labels":[{"id":51138197,"url":"https://api.github.com/repos/monome/aleph/labels/%23dsp","name":"#dsp","color":"aa0044","default":false},{"id":74409474,"url":"https://api.github.com/repos/monome/aleph/labels/OPTIMIZE/IMPROVE","name":"OPTIMIZE/IMPROVE","color":"0052cc","default":false}],"state":"open","locked":false,"assignee":{"login":"catfact","id":94855,"avatar_url":"https://avatars.githubusercontent.com/u/94855?v=3","gravatar_id":"","url":"https://api.github.com/users/catfact","html_url":"https://github.com/catfact","followers_url":"https://api.github.com/users/catfact/followers","following_url":"https://api.github.com/users/catfact/following{/other_user}","gists_url":"https://api.github.com/users/catfact/gists{/gist_id}","starred_url":"https://api.github.com/users/catfact/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/catfact/subscriptions","organizations_url":"https://api.github.com/users/catfact/orgs","repos_url":"https://api.github.com/users/catfact/repos","events_url":"https://api.github.com/users/catfact/events{/privacy}","received_events_url":"https://api.github.com/users/catfact/received_events","type":"User","site_admin":false},"assignees":[{"login":"catfact","id":94855,"avatar_url":"https://avatars.githubusercontent.com/u/94855?v=3","gravatar_id":"","url":"https://api.github.com/users/catfact","html_url":"https://github.com/catfact","followers_url":"https://api.github.com/users/catfact/followers","following_url":"https://api.github.com/users/catfact/following{/other_user}","gists_url":"https://api.github.com/users/catfact/gists{/gist_id}","starred_url":"https://api.github.com/users/catfact/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/catfact/subscriptions","organizations_url":"https://api.github.com/users/catfact/orgs","repos_url":"https://api.github.com/users/catfact/repos","events_url":"https://api.github.com/users/catfact/events{/privacy}","received_events_url":"https://api.github.com/users/catfact/received_events","type":"User","site_admin":false}],"milestone":null,"comments":4,"created_at":"2016-11-03T23:18:21Z","updated_at":"2016-11-07T19:17:34Z","closed_at":null,"body":"i'm taking another careful look at the topology for `filter_svf` after noticing some weird behavior, most prominent when given DC signals. \r\n\r\nhere's the [supercollider patch](https://gist.github.com/catfact/1b7b7fa9f4c82602b03b9ed405aff7ef) generating the excitation signals. there are 5 varieties:\r\n\r\n    continuous white noise\r\n    white noise with 1ms exponential decay envelope\r\n    white noise with 0.1-1ms pulse rectangular envelope\r\n    DC with 1ms exponential decay envelope\r\n    DC with 0.1-1ms pulse rectangular envelope\r\n\r\nif the rq is set to 0 and the filter is pinged with an envelope, sending it into oscillation, and the corner frequency subsequently swept, the frequency response is actually quite flat. the sine wave becomes distorted as CF approaches nyquist/2, as expected for this topology.\r\n\r\nfor RQ slightly >0, repeatedly sending a \"decay DC\" excitation has a predictable, smooth \"ping\". but repeatedly sending any of the others creates inconsistent amplitudes in the resulting sound. it is as if the system is not really LTI... feedback terms cancelling out new input. or something. i had noticed this before but attributed it to saturation during one or both of the summation steps.\r\n\r\nhowever, softclipping isn't helping this particular issue (though it does i think improve the sound for typical uses cases when the input signal is hot.)\r\n\r\nso i think you're right that it might be something totally wrong with the topology, event though it gives plausible results with most input. probably with the fixed-point implementation in particular.\r\ni'm going to try redoing it. i've come across a couple of improved methods since 2012 or whatever anyway."},"comment":{"url":"https://api.github.com/repos/monome/aleph/issues/comments/258933786","html_url":"https://github.com/monome/aleph/issues/271#issuecomment-258933786","issue_url":"https://api.github.com/repos/monome/aleph/issues/271","id":258933786,"user":{"login":"catfact","id":94855,"avatar_url":"https://avatars.githubusercontent.com/u/94855?v=3","gravatar_id":"","url":"https://api.github.com/users/catfact","html_url":"https://github.com/catfact","followers_url":"https://api.github.com/users/catfact/followers","following_url":"https://api.github.com/users/catfact/following{/other_user}","gists_url":"https://api.github.com/users/catfact/gists{/gist_id}","starred_url":"https://api.github.com/users/catfact/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/catfact/subscriptions","organizations_url":"https://api.github.com/users/catfact/orgs","repos_url":"https://api.github.com/users/catfact/repos","events_url":"https://api.github.com/users/catfact/events{/privacy}","received_events_url":"https://api.github.com/users/catfact/received_events","type":"User","site_admin":false},"created_at":"2016-11-07T19:17:34Z","updated_at":"2016-11-07T19:17:34Z","body":"> c->c3 = sub_fr1x32(add_fr1x32(c->c0, c->c0z), mult_fr1x32x32(0x7fffffff, c->c2z));\r\n\r\nthat line seems not qute right? `mult_fr1x32x32(0x7fffffff, x)` returns `x` unchanged?\r\nmaybe should be\r\n`c->c3 = sub_fr1x32(add_fr1x32(c->c0, c->c0z), shl_fr1x32(c->c2z, 1));`\r\nand of course make sure the input is always small. maybe right shift 1 or 2 places and left shift the filter output. or use a different radix for all the calculations... \r\n\r\nanother thing that might be worth trying is using the blackfin's fast-float library. there are intrinsics for non-IEEE floats that use 16b mantissas and should actually be pretty fast.\r\n(here's an appnote) [http://www.analog.com/media/en/technical-documentation/application-notes/EE.185.Rev.4.08.07.pdf]\r\n\r\nthe appnote uses VDSP intrinsics, but they exist in the gcc toolchain too under slightly different names\r\ne.g. `fract16_to_ff16` in VDSP is  `fr16_to_fl16` ... place to look is `bfin-elf/include/float16.h` in your toolchain directory."}}
{"actor":{"display_login":"catfact"}}