It appears as if the PhISEM opcodes (guiro, cabasa, crunch, etc) never
got some parameters scaled properly when things were converted to work
with 0db scaling.

The doc page suggest a value 0-1, however even relatively small values
create a runaway condition.  But if you use a range of 0-(1/32767) the
opcodes appear to work as intended.

Can anyone confirm if this is a permanent intended change, or is this
a bug in the behavior that will eventually be fixed?

Thanks for the fix & followup jpff!

Sorry, I shouldn't have implied that *all* of the PhISEM opcodes were
affected, I had tested a few and noticed the odd results.  Since many
opcodes shared similar parameters and modeling techniques, I figured
there was likely shared code between them and worded that poorly.

On Fri, Aug 8, 2014 at 10:31 AM,   wrote:
> Found errors in cabasa and sekere (which is same code as crunch,sandpaper
> and stix.  Fixed in git
>
>
> Quoting jpff@cs.bath.ac.uk:
>
>> Sounds like a bug; will look
>> ==John ff
>>
>> Quoting Kevin Welsh :
>>
>>> It appears as if the PhISEM opcodes (guiro, cabasa, crunch, etc) never
>>> got some parameters scaled properly when things were converted to work
>>> with 0db scaling.
>>>
>>> The doc page suggest a value 0-1, however even relatively small values
>>> create a runaway condition.  But if you use a range of 0-(1/32767) the
>>> opcodes appear to work as intended.
>>>
>>> Can anyone confirm if this is a permanent intended change, or is this
>>> a bug in the behavior that will eventually be fixed?
>>>
>>>
>>> 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"
>>
>>
>>
>>
>>
>>
>> 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"
>
>
>
>
>
>
> 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"
>
>
>

John, I did some extensive testing with the PhISEM opcodes last night.
My csound version was built from the dev branch on Aug 16th, and
appears to have the fixes for a few other bugs I had tested/reported
(ftgenonce, pset, flooper2).  I'm not sure if your changes to phisem
opcodes were included in this build or not, but I still figured my
findings could be useful.

I still see a lot of unexpected behavior with the phisem opcodes.
Some of these might be intended behavior, but I don't think so.  If
anything I reported here is working as intended, please let me know so
I can change my instruments and tests.  I tried to to test all
parameters on all phisem opcodes that I could find listed in the
manual and document it as best as I could.

Opcodes tested: bamboo, cabasa, crunch, dripwater, guiro, sandpaper,
sekere, sleighbells, stix, tambourine.  Let me know if I missed any.

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

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

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

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

guiro maxshake seems to do nothing, even when nonsense values are put
in.  is it supposed to, or should it be called nonfunctional in docs
(like damp is for guiro)?

The bug with some values only affecting one note seems strange.  I see
how it might possibly (but still unlikely) be an intended behavior for
maxshake on some of the other opcodes, but I definitely don't think
it's intended for guiro's freq values.  Here's an example csd:



; Select audio/midi flags here according to platform
-odac     ;;;realtime audio out
;-iadc    ;;;uncomment -iadc if realtime audio input is needed too
; For Non-realtime ouput leave only the line below:
; -o guiro.wav -W ;;; for file output any platform



sr = 44100
ksmps = 32
nchnls = 2
0dbfs  = 1

instr 1
inum = 0
idamp = 0
imaxshake = 0
a1  guiro .8, p4, inum, idamp, imaxshake, 8000
    outs a1, a1

endin



i1 0 1 1
i1 + 1 1
e




If you want me to put any of these in github as bugs, I'll be glad to.

On Fri, Aug 8, 2014 at 7:09 AM, Kevin Welsh  wrote:
> It appears as if the PhISEM opcodes (guiro, cabasa, crunch, etc) never
> got some parameters scaled properly when things were converted to work
> with 0db scaling.
>
> The doc page suggest a value 0-1, however even relatively small values
> create a runaway condition.  But if you use a range of 0-(1/32767) the
> opcodes appear to work as intended.
>
> Can anyone confirm if this is a permanent intended change, or is this
> a bug in the behavior that will eventually be fixed?