User Details
| Username: |
jholden |
| Website: |
None provided |
| Facebook: |
None provided |
| Twitter: |
None provided |
| Soundcloud: |
None provided |
| Account Status: |
enabled |
| Member since: |
Jan 13 2010 |
| About jholden: |
|
| (report this profile) |
|
Devices by jholden
No devices have been posted by this user.
Comments by jholden
Comments
This website uses cookies.
Clicking “Accept” means you consent to your data being processed and you’ll let us use cookies and other technologies to process your personal information to personalize and enhance your experience.
Click “Close” to deny consent and continue with technically required cookies that are essential for the website to function.
also i made the choice to use a buffered recording of pink noise as a workaround so that when notes arrive simultaneously (ie a chord) they can be given different delay values. this was a behaviour i desired for musical reasons, rather than something that the research justified, but the slight sacrifices made in achieving it don't spoil the coherence that makes the timing errors 'human'.
i put the range-related calculations before the buffer for simplicity / because i hadn't considered your use case, but it would be trivial for you to move those objects to a point after the buffer read in the signal chain. also: to get it to behave how you want you should make it add (100 - range) to every delay value to keep the mean delay fixed as you turn the knob.