Dear list,

in a setup where audio signals and i-rate signals are passed with  
Signal Flow Graph Opcodes there seem to be two different ways to  
invocate the following instruments. One can use schedule or alwayson.  
In contradiction to the advice in the manual, I have to use alwayson  
within the instrument to be able to pass other i-rate statements  
safely to the following instruments, even if it comes to thousands of  
soundgrains which do partly overlap.

Now what I did experienced was this: Although the instruments get  
invocated at the same time and for the same duration (as far as I can  
see), they have totally different  output in amplitude. If you use  
schedwhen (same with event_i b.t.w.), the amplitude is summed  
*somehow* differently and tends to clip easily and massively. Actually  
one could use alwayson instead, but there are two little drawbacks on  
that scenario

1. Using alwayson in the header-block  makes impossible to pass  
different i-statements along to the following instruments
2. Using alwayson in the instrument block may produce clicks at init-  
time in Sean Costellos Reverb (see second mail  on that different topic)

What I do wonder now is how and why the amplitudes are summed so  
strange using schedwhen. If I knew why, I might find a workaround. I  
would prefer using schedwhen, as the reverbs do make some problems if  
I do use alwayson within the instrument. The other possibility would  
surely be to solve the clicks.

I would be most delighted to receive any idea on that. The test- 
instrument is below.

Best regards,

Jan Jacob




-n


giprint		init		0

		connect		"1", "audio_out",		"2", "audio_in"		; connecting a-rate  
output from instr 1 to instr 2
		;alwayson	2, giprint						; putting alwayson in the header section  
will not pass giprint to the other instruments

instr 1		; source instrument

giprint		=		giprint	+ 1
ifreq		=		p4


asig		oscil		0dbfs * 0.2, ifreq, 1		; creating an audio signal
		outleta		"audio_out", asig		; sending the audio signal to channel  
"audio_out"
		schedule	2, 0, p3, giprint		; starting instr 2 to play  
simultaneously - comment this out instead of the line below
		;alwayson	2, giprint			; starting instr 2 to play simultaneously -  
comment this out instead of the line above
		;event_i	"i", 2, 0, p3, giprint		; starting instr 2 to play  
simultaneously - comment this out instead of the line above
endin



instr 2		; sink instrument

iprint		=		p4
asig		inleta		"audio_in"			; reading channel "audio_in"
		outc 		asig				; output the sound
		schedule	3, 0, p3, iprint		; starting instr 3 to play simultaneously

endin



instr 3		; printing instrument
iprint		=		p4				; receive variable from isntr. 2
		print		iprint				; print iprint
endin






f1	0	8192	10	1				/*	sine */
i1	0	5	220
i1	1	4	440
i1	2	3	880
i1	3	2	1760
i1	4	1	3520






sound         |         movement          |          object          
|          space
sonic architecture       |        site: http://www.sonicarchitecture.de
spatial electronic composition     |    2nd order ambisonic music






Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Hi Jan Jacob,

I'm not sure I quite understand what's going on.  With alwayson, it
means it schedules an instance of that instrument to run and it's
always running.  Once you do that in the header, you shouldn't use
that instrument directly, such as using event or schedule. As for
instr 3 in your project, I'd recommend doing this kind of per-note in
instr 1 or wherever else you are actually doing per-note work.

Does that help or have I misunderstood something?

Thanks,
steven

On Thu, Mar 31, 2011 at 6:21 AM, Jan Jacob Hofmann
 wrote:
> Dear list,
>
> in a setup where audio signals and i-rate signals are passed with Signal
> Flow Graph Opcodes there seem to be two different ways to invocate the
> following instruments. One can use schedule or alwayson. In contradiction to
> the advice in the manual, I have to use alwayson within the instrument to be
> able to pass other i-rate statements safely to the following instruments,
> even if it comes to thousands of soundgrains which do partly overlap.
>
> Now what I did experienced was this: Although the instruments get invocated
> at the same time and for the same duration (as far as I can see), they have
> totally different  output in amplitude. If you use schedwhen (same with
> event_i b.t.w.), the amplitude is summed *somehow* differently and tends to
> clip easily and massively. Actually one could use alwayson instead, but
> there are two little drawbacks on that scenario
>
> 1. Using alwayson in the header-block  makes impossible to pass different
> i-statements along to the following instruments
> 2. Using alwayson in the instrument block may produce clicks at init- time
> in Sean Costellos Reverb (see second mail  on that different topic)
>
> What I do wonder now is how and why the amplitudes are summed so strange
> using schedwhen. If I knew why, I might find a workaround. I would prefer
> using schedwhen, as the reverbs do make some problems if I do use alwayson
> within the instrument. The other possibility would surely be to solve the
> clicks.
>
> I would be most delighted to receive any idea on that. The test-instrument
> is below.
>
> Best regards,
>
> Jan Jacob
>
>
> 
> 
> -n
> 
> 
> giprint         init            0
>
>                connect         "1", "audio_out",               "2",
> "audio_in"         ; connecting a-rate output from instr 1 to instr 2
>                ;alwayson       2, giprint
>            ; putting alwayson in the header section will not pass giprint to
> the other instruments
>
> instr 1         ; source instrument
>
> giprint         =               giprint + 1
> ifreq           =               p4
>
>
> asig            oscil           0dbfs * 0.2, ifreq, 1           ; creating
> an audio signal
>                outleta         "audio_out", asig               ; sending the
> audio signal to channel "audio_out"
>                schedule        2, 0, p3, giprint               ; starting
> instr 2 to play simultaneously - comment this out instead of the line below
>                ;alwayson       2, giprint                      ; starting
> instr 2 to play simultaneously - comment this out instead of the line above
>                ;event_i        "i", 2, 0, p3, giprint          ; starting
> instr 2 to play simultaneously - comment this out instead of the line above
> endin
>
>
>
> instr 2         ; sink instrument
>
> iprint          =               p4
> asig            inleta          "audio_in"                      ; reading
> channel "audio_in"
>                outc            asig                            ; output the
> sound
>                schedule        3, 0, p3, iprint                ; starting
> instr 3 to play simultaneously
>
> endin
>
>
>
> instr 3         ; printing instrument
> iprint          =               p4                              ; receive
> variable from isntr. 2
>                print           iprint                          ; print
> iprint
> endin
>
>
>
>
> 
> 
> f1      0       8192    10      1                               /*      sine
> */
> i1      0       5       220
> i1      1       4       440
> i1      2       3       880
> i1      3       2       1760
> i1      4       1       3520
>
>
> 
> 
>
>
> sound         |         movement          |          object         |
>    space
> sonic architecture       |        site: http://www.sonicarchitecture.de
> spatial electronic composition     |    2nd order ambisonic music
>
>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> 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 the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"