Hello ...

All the sc_ opcodes are great. Many thanks to the author. They are helping
me simplify some of my designs ... retriggering phasors has long been a
complicating design issue for me in various forms.

a query however:

the manual suggests that the arate & krate outputs can be retriggered with
either arate or krate inputs 

*
aindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos] 

kindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos] 
*

but i am definitely getting a rejection message when attempting to trigger
the arate version with a krate trigger ... ("no opcode with matching
args"...). no problem if i convert to an arate trigger instead ... (upsamp
or mpulse offering alternatives / workarounds ...)

is this a documentation error? or an error in the implementation of the
opcode?

this is partly a bit of a leading question. i seem to be getting an
intermittent 'downsampling' type effect using the arate sc_phasor, but i
need to dig deeper before trying to report that ... it's possibly me doing a
bad design thing ... it would be good for me however if the krate trigger
option was available, i could keep the retrigger in sync with other krate
things going on, even though the phasor output was / is arate ...






--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Te code for sc_phasor is wrongly specified.  The manual says tat the 5th 
argumet is optional but the code does not reflect that.  Will look more 
closely soonish

Could you provide a test oc please?


On Wed, 6 Sep 2017, Tim Mortimer wrote:

> Hello ...
>
> All the sc_ opcodes are great. Many thanks to the author. They are helping
> me simplify some of my designs ... retriggering phasors has long been a
> complicating design issue for me in various forms.
>
> a query however:
>
> the manual suggests that the arate & krate outputs can be retriggered with
> either arate or krate inputs
>
> *
> aindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos]
>
> kindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos]
> *
>
> but i am definitely getting a rejection message when attempting to trigger
> the arate version with a krate trigger ... ("no opcode with matching
> args"...). no problem if i convert to an arate trigger instead ... (upsamp
> or mpulse offering alternatives / workarounds ...)
>
> is this a documentation error? or an error in the implementation of the
> opcode?
>
> this is partly a bit of a leading question. i seem to be getting an
> intermittent 'downsampling' type effect using the arate sc_phasor, but i
> need to dig deeper before trying to report that ... it's possibly me doing a
> bad design thing ... it would be good for me however if the krate trigger
> option was available, i could keep the retrigger in sync with other krate
> things going on, even though the phasor output was / is arate ...
>
>
>
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I think I have fixed the optional argument and also corrected a number of 
the sc_ opcodes to observe --sample-accurate, but I need a test to be sure

On Wed, 6 Sep 2017, Tim Mortimer wrote:

> Hello ...
>
> All the sc_ opcodes are great. Many thanks to the author. They are helping
> me simplify some of my designs ... retriggering phasors has long been a
> complicating design issue for me in various forms.
>
> a query however:
>
> the manual suggests that the arate & krate outputs can be retriggered with
> either arate or krate inputs
>
> *
> aindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos]
>
> kindex sc_phasor xtrig, xrate, kstart, kend [, kresetPos]
> *
>
> but i am definitely getting a rejection message when attempting to trigger
> the arate version with a krate trigger ... ("no opcode with matching
> args"...). no problem if i convert to an arate trigger instead ... (upsamp
> or mpulse offering alternatives / workarounds ...)
>
> is this a documentation error? or an error in the implementation of the
> opcode?
>
> this is partly a bit of a leading question. i seem to be getting an
> intermittent 'downsampling' type effect using the arate sc_phasor, but i
> need to dig deeper before trying to report that ... it's possibly me doing a
> bad design thing ... it would be good for me however if the krate trigger
> option was available, i could keep the retrigger in sync with other krate
> things going on, even though the phasor output was / is arate ...
>
>
>
>
>
>
> --
> Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

No problem John ...

I have a busy couple of days myself ... 

i did solve the periodic 'downsample' type sound, but i'll will try &
reproduce it for you in the days ahead ...

i believe it may have had to do with specifying the kresetPos (with an init
statement to try & set an initial 'phase'), but then not providing a trigger
to 'set' this as the desired start position (as i was putting my metro
triggers out of phase on initialisation also ... so no initial trigger event
...)

i got around this by making sure i sent a trigger at t = 0 also ... (or on
first kcycle ... however metro achieves this ...) & this seems to have
solved the issue ... (i'm randomising my metro times subsequently anyway
...)

if kresetPos is not optional as you suggest it should be, maybe that could
produce playback issues under certain circumstances (i am also periodically
setting the frequency to negative, running the sc_phasor in reverse ... i'm
using it as an LFO effectively ... roaming up & down over dB values with
occasional random reset, smoothed using sc_lag)

i'll see what i can do to reproduce with a simple example. otherwise it
appears to be functioning AOK for the moment ... i will be using this quite
a bit going forward, so if there are issues i will probably come across them
again sooner or later ...

if the internals can be tightened up, great ... 

many thanks for looking into it.








--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I fixed sc_phasor to comply with documentation, making the resetpos 
argument optional and added sample-accurate audio loops. Code is part of a 
previous PR: 

https://github.com/csound/csound/pull/847

On Mittwoch, 6. September 2017 22:15:19 CEST, jpff wrote:
> Te code for sc_phasor is wrongly specified.  The manual says 
> tat the 5th argumet is optional but the code does not reflect 
> that.  Will look more closely soonish
>
> Could you provide a test oc please?
>
>
> On Wed, 6 Sep 2017, Tim Mortimer wrote:
>
>> Hello ...
>> 
>> All the sc_ opcodes are great. Many thanks to the author. They are helping
>> me simplify some of my designs ... retriggering phasors has long been a
>> complicating design issue for me in various forms.
>> 
>> a query however: ...
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks, I think i am reading that this is now fixed for the next release ...

the 'scrapey' downsampling noise seems (seemed ...) to occur when the metro
doesn't send an initial bang in the below example, but an initial reset
position is supplied ... (but not 'enforced' as it were ...)

apologies if this is a little long winded, but it does give the context in
which the effect is most pronounced ... & is simplified from my initial
example (which has a more complex timing mechanism driving the retrigger
...)

i am overcoming the problem by supplying a bang on initialisation, i.e. no
metro phase offset ...

it also isn't necessarily audible on every initialisation of performance ...
i'm happy with the workaround ('bang on start up', & maybe the issue is
fixed now anyway, but in the interests of completion, i supply the example
that produced the issue as promised ...

i may inadvertently learn something in the process ...



-odac0




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

seed 0

opcode Resettable_phasor_as_dBtide_a, a,iiiiik

idBrate_mean, idBfloor, idBcieling, igaussexp_depth, igauss_rate, kretrig
xin

	;;; ****************
	;;; if iphase0flag == 1 then set phase to 0 ...
	
	istartphase random idBfloor+0.2, idBcieling-0.2
	itarget random idBfloor+0.2, idBcieling-0.2
	
	idir = itarget-istartphase
	
	if idir < 0 then
		idir = -1
	else
		idir = 1
	endif
	
	kstartphase init istartphase
	
	kdir init idir
	ktarget init itarget
	
	;;; *** speed & randomisation thereof ***
	
	;;; gauss rand of the freq ...
	idBrate_mean_exp = log2(idBrate_mean)
	kdBrate_exp_gauss gaussi igaussexp_depth,1,igauss_rate
	kdBrate_exp = idBrate_mean_exp+kdBrate_exp_gauss
	kplayr = powoftwo(kdBrate_exp)
	kplayr /= sr

	;;; **********
	;;; the retrigger
	
	if kretrig == 1 then
	
		kstartphase random idBfloor+0.2, idBcieling-0.2
		ktarget random idBfloor+0.2, idBcieling-0.2
		
		if ktarget < kstartphase then
			kdir = -1
		else
			kdir = 1
		endif
		
	endif
	
	;;; ***************************
	
	kplayr *= kdir
	
	aretrig upsamp kretrig
	
	aphase sc_phasor aretrig,kplayr,idBfloor,idBcieling,kstartphase
	
	kphase downsamp aphase
	
	;;; ****************
	;;; direction changes ...
	
	if kdir == 1 then
		if kphase >= ktarget then
			ktarget random idBfloor+0.2, idBcieling-0.2
			if ktarget < kphase then
				kdir = -1
			else
				kdir = 1
			endif
		endif
	else
		if kphase <= ktarget then
			ktarget random idBfloor+0.2, idBcieling-0.2
			if ktarget < kphase then
				kdir = -1
			else
				kdir = 1
			endif
		endif
	endif

	aamp = ampdbfs(aphase)
	aamp sc_lag aamp,0.005
	
	xout aamp

endop


instr 01

	kbang metro 0.2,0.8
	
	aamp1 Resettable_phasor_as_dBtide_a 3,-24,0,0.5,1.7,kbang

	asin1 oscil 0.25,440
	asin1 *= aamp1
	
	outs asin1,asin1

endin



i 1 0 360







--
Sent from: http://csound.1045644.n5.nabble.com/Csound-General-f1093014.html

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here