I have looked at these.  Current state is


DONE        value only affects one note per change:
            bamboo(maxshake), guiro(freq, freq2, freq3),
            sleighbells(maxshake), tambourine(maxshake)

DONE        num=0 doesn't create expected default:
            dripwater(10), stix(30)

DONE        unpredictable amps when changing sandpaper num to anything
            other than default (128)

Possibly FIXED: guiro maxshake seems to do nothing, even when nonsense
                values are put in.

Not sure what to do about
values off by scale of 32768: cabasa(maxshake), crunch(maxshake),
sandpapder(maxshake), sekere(maxshake), stix(maxshake)
value off by unknown scale: bamboo(damp, maybe scale by 10?)

My test has bamboo Ok, and cabasa seems right.  I think I do not
understand the issue.

Fixes in GIT now
==John ffitch

Awesome!  Sorry I didn't get the tests to you in time to be any help,
I was having a surprisingly hard time designing a test that showed
these behaviors statically, most of my tests were conducted using real
time input from blue widgets, and it's much easier to notice the
changes as I tweak the knob.  I ran out of time and had to move on
before I had a usable test.

It looks like your newest code is checked into the dev branch, I'll do
a rebuild later this evening and test them again.

Perhaps the remaining issues were fixed unknowingly?  I'll test it
tonight and see, but I'll try describing the problem again here in
case that helps too.

Here is my raw blue instrument.  Maxshake is taking a value passed
from a widget that is between 0 and 1 (documented as the expected
values for maxshake).  If I remove the "/32768", and just use the raw
0-1 values, the instrument will explode with the slightest increase in
value.  For example, .1 results in a ridiculous amount of amps out of
range and sounds almost like white noise.  But if I divide that value
by 32768, the output seems reasonable and usable, allowing me to
extend maxshake all the way to 1.

idur = p3
iamp = p4

idettack = i()*idur
inum = i()
idamp = i()
imaxshake = i()/32768

asig cabasa iamp, idettack, inum, idamp, imaxshake

; postgain snippet
kpostgain=
asig = asig*kpostgain

; mono pan snippet
kpan=
aoutL = asig*abs(kpan-1)
aoutR = asig*(kpan+1)

blueMixerOut aoutL, aoutR


On Wed, Aug 27, 2014 at 8:51 AM, john ffitch  wrote:
> I have looked at these.  Current state is
>
>
> DONE        value only affects one note per change:
>             bamboo(maxshake), guiro(freq, freq2, freq3),
>             sleighbells(maxshake), tambourine(maxshake)
>
> DONE        num=0 doesn't create expected default:
>             dripwater(10), stix(30)
>
> DONE        unpredictable amps when changing sandpaper num to anything
>             other than default (128)
>
> Possibly FIXED: guiro maxshake seems to do nothing, even when nonsense
>                 values are put in.
>
> Not sure what to do about
> values off by scale of 32768: cabasa(maxshake), crunch(maxshake),
> sandpapder(maxshake), sekere(maxshake), stix(maxshake)
> value off by unknown scale: bamboo(damp, maybe scale by 10?)
>
> My test has bamboo Ok, and cabasa seems right.  I think I do not
> understand the issue.
>
> Fixes in GIT now
> ==John ffitch
>
>
> Send bugs reports to
>         https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>

And by the way, I pulled the number 32768 out of a hat... I don't know
if that's *actually* the correct scale, but it's giving me usable
results.  It was a guess on my part that perhaps 0dbfs wasn't being
applied properly to the variable... but since I've now tested the same
behavior with 0dbfs=32768 that might not be the case.

On Wed, Aug 27, 2014 at 1:48 PM, Kevin Welsh  wrote:
> Awesome!  Sorry I didn't get the tests to you in time to be any help,
> I was having a surprisingly hard time designing a test that showed
> these behaviors statically, most of my tests were conducted using real
> time input from blue widgets, and it's much easier to notice the
> changes as I tweak the knob.  I ran out of time and had to move on
> before I had a usable test.
>
> It looks like your newest code is checked into the dev branch, I'll do
> a rebuild later this evening and test them again.
>
> Perhaps the remaining issues were fixed unknowingly?  I'll test it
> tonight and see, but I'll try describing the problem again here in
> case that helps too.
>
> Here is my raw blue instrument.  Maxshake is taking a value passed
> from a widget that is between 0 and 1 (documented as the expected
> values for maxshake).  If I remove the "/32768", and just use the raw
> 0-1 values, the instrument will explode with the slightest increase in
> value.  For example, .1 results in a ridiculous amount of amps out of
> range and sounds almost like white noise.  But if I divide that value
> by 32768, the output seems reasonable and usable, allowing me to
> extend maxshake all the way to 1.
>
> idur = p3
> iamp = p4
>
> idettack = i()*idur
> inum = i()
> idamp = i()
> imaxshake = i()/32768
>
> asig cabasa iamp, idettack, inum, idamp, imaxshake
>
> ; postgain snippet
> kpostgain=
> asig = asig*kpostgain
>
> ; mono pan snippet
> kpan=
> aoutL = asig*abs(kpan-1)
> aoutR = asig*(kpan+1)
>
> blueMixerOut aoutL, aoutR
>
>
> On Wed, Aug 27, 2014 at 8:51 AM, john ffitch  wrote:
>> I have looked at these.  Current state is
>>
>>
>> DONE        value only affects one note per change:
>>             bamboo(maxshake), guiro(freq, freq2, freq3),
>>             sleighbells(maxshake), tambourine(maxshake)
>>
>> DONE        num=0 doesn't create expected default:
>>             dripwater(10), stix(30)
>>
>> DONE        unpredictable amps when changing sandpaper num to anything
>>             other than default (128)
>>
>> Possibly FIXED: guiro maxshake seems to do nothing, even when nonsense
>>                 values are put in.
>>
>> Not sure what to do about
>> values off by scale of 32768: cabasa(maxshake), crunch(maxshake),
>> sandpapder(maxshake), sekere(maxshake), stix(maxshake)
>> value off by unknown scale: bamboo(damp, maybe scale by 10?)
>>
>> My test has bamboo Ok, and cabasa seems right.  I think I do not
>> understand the issue.
>>
>> Fixes in GIT now
>> ==John ffitch
>>
>>
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>>
>>