I'm experimenting with real-time slider inputs, using both QuteCsound and
blue. For test purposes, I'm controlling pitch.

Both programs produce zippering (stair-step artifacts). QuteCsound is five
or ten times quicker in its sliders' response time -- the slider output is
updated more times per second -- but the stair-stepping is still very
audible.

I've written a smoothing function (see code below), but it doesn't work as
well as I'd like. First, with blue, small moves of the pitch slider still
result in audible (though non-glitchy) pitch jumps rather than a smooth
glide. Second, if I use a reasonable glide time to smooth out the pitch, the
slider becomes less responsive to large, swift moves. There's a very
perceptible lag between the mouse move and the pitch change.

Neither program seems to have a user control for the slider output refresh
rate. At least, I haven't been able to find one. Am I just missing something
obvious, or should I not expect any better real-time responsiveness than
this?

--Jim Aikin

; code:
kPitchSlider = 
kPitch init i()

; the maximum cps by which we'll move the pitch in 1 k-cycle:
iPitchMaxMove = 0.01
iPitchMaxMoveDown = -(iPitchMaxMove)

; kPitchInc is the amount by which we will actually move the pitch
; up or down during this k-cycle:
kPitchInc init 0

; measure the difference between the slider value and current pitch --
; if the slider is higher than current pitch, kPitchDiff will be positive:
kPitchDiff = kPitchSlider - kPitch

; calculate kPitchInc based on the difference between the current pitch and
; the latest input from the slider:
if (kPitchDiff == 0) kgoto no_slide
	; if we're sliding up:
	if (kPitchDiff > 0) then
		kPitchInc = ((kPitchDiff > iPitchMaxMove) ? iPitchMaxMove : kPitchDiff)
	; else we must be sliding down:
	else
		kPitchInc = ((kPitchDiff < iPitchMaxMoveDown) ? iPitchMaxMoveDown :
kPitchDiff)
	endif
	; change the pitch:
	kPitch = kPitch + kPitchInc
no_slide:

a1	foscili	 0.3, kPitch, 1, 1, 2, 1
	outs	a1, a1

I normally use tonek for this kind of stuff. Have you tried using it
to smooth out the signal?


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"

I use the port opcode for this.

kspr invalue "slider2"
kspr port kspr, 0.05

Naturally setting ksmps lower helps as well.

Best,

P

On 23 May 2010, at 01:24, Jim Aikin wrote:

>
> I'm experimenting with real-time slider inputs, using both  
> QuteCsound and
> blue. For test purposes, I'm controlling pitch.
>
> Both programs produce zippering (stair-step artifacts). QuteCsound  
> is five
> or ten times quicker in its sliders' response time -- the slider  
> output is
> updated more times per second -- but the stair-stepping is still very
> audible.
>
> I've written a smoothing function (see code below), but it doesn't  
> work as
> well as I'd like. First, with blue, small moves of the pitch slider  
> still
> result in audible (though non-glitchy) pitch jumps rather than a  
> smooth
> glide. Second, if I use a reasonable glide time to smooth out the  
> pitch, the
> slider becomes less responsive to large, swift moves. There's a very
> perceptible lag between the mouse move and the pitch change.
>
> Neither program seems to have a user control for the slider output  
> refresh
> rate. At least, I haven't been able to find one. Am I just missing  
> something
> obvious, or should I not expect any better real-time responsiveness  
> than
> this?
>
> --Jim Aikin
>
> ; code:
> kPitchSlider = 
> kPitch init i()
>
> ; the maximum cps by which we'll move the pitch in 1 k-cycle:
> iPitchMaxMove = 0.01
> iPitchMaxMoveDown = -(iPitchMaxMove)
>
> ; kPitchInc is the amount by which we will actually move the pitch
> ; up or down during this k-cycle:
> kPitchInc init 0
>
> ; measure the difference between the slider value and current pitch --
> ; if the slider is higher than current pitch, kPitchDiff will be  
> positive:
> kPitchDiff = kPitchSlider - kPitch
>
> ; calculate kPitchInc based on the difference between the current  
> pitch and
> ; the latest input from the slider:
> if (kPitchDiff == 0) kgoto no_slide
> 	; if we're sliding up:
> 	if (kPitchDiff > 0) then
> 		kPitchInc = ((kPitchDiff > iPitchMaxMove) ? iPitchMaxMove :  
> kPitchDiff)
> 	; else we must be sliding down:
> 	else
> 		kPitchInc = ((kPitchDiff < iPitchMaxMoveDown) ? iPitchMaxMoveDown :
> kPitchDiff)
> 	endif
> 	; change the pitch:
> 	kPitch = kPitch + kPitchInc
> no_slide:
>
> a1	foscili	 0.3, kPitch, 1, 1, 2, 1
> 	outs	a1, a1
> -- 
> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28646850.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> 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"

RoryWalsh wrote:
> 
> I normally use tonek for this kind of stuff. Have you tried using it
> to smooth out the signal?
> 

I knew there was an opcode that would do that, but I couldn't remember the
name (that's how often I use Csound, I'm afraid), so I did it by hand.

What I'm finding, though, is that tonek doesn't solve the problem ... and in
fact, it doesn't seem to perform as well in my little test scenario as a
hand-rolled algorithm, because with tonek the pitch always glides up from 0
at the beginning of a new note. In my algorithm, the current value of the
slider (whatever that happens to be) is where the pitch starts at the
beginning of the note.

on 2010-05-23 at 01:34 Rory Walsh wrote:

>I normally use tonek for this kind of stuff. Have you tried using it
>to smooth out the signal?

or port? i tried to do something similar once, and i think to remember
that i found port to be very appropriate for this.


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"

port and tonek both work, but they both start each new note with a pitch of
0, which is not desirable. Aside from this, either of them does give a
smooth slider response in QuteCsound. However, blue's slider refresh rate
(unless there's a UI feature I haven't yet spotted) is not fast enough to
produce responsive real-time sliders.

--JA

Yes I believe blue's api mode is experimental at this time and not  
really meant for reliable real-time performance. It is more for  
tweaking purposes (I'm sure it will improve in the future), Steven  
please correct me if I'm wrong.

I have also noticed the problem of a slide at the start of the note  
when using port. I guess the workaround would be to have the  
controller (and the port opcode) in a different instrument that is  
initialised before the actual note, or else have an internal mechanism  
of triggering the sound after the note has been initialised. But  
that's too much hassle really, it would be nice if there was an opcode  
that somehow managed to do this by itself. After all we don't have  
this problem in SC3!

Best,

P

On 23 May 2010, at 03:13, Jim Aikin wrote:

>
> port and tonek both work, but they both start each new note with a  
> pitch of
> 0, which is not desirable. Aside from this, either of them does give a
> smooth slider response in QuteCsound. However, blue's slider refresh  
> rate
> (unless there's a UI feature I haven't yet spotted) is not fast  
> enough to
> produce responsive real-time sliders.
>
> --JA
> -- 
> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> 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"

Hi Jim,

I haven't done tests for speed of slider response in blue, as most of
my usage has been to configure an instrument's params to find a
setting for a patch, rather than using it to perform with the sliders.
 It may be well that the sliders implementation differs between the
two programs, and it may also be a performance difference between
using Java's Swing library and C++ with QT.

Also, are you using the same ksmps between testing in blue and
QuteCsound?  I believe both programs are updating values at ksmps
intervals. I know blue uses a value cache rather than direct querying
of value from widgets; this may end up being slower but I think has
less chance of causing a dropout.  If blue's performance really is
slower that QuteCsound, then maybe it is worth investigating another
strategy internally in blue.

I think up until now, blue's view of live parameter manipulation may
be more focused on configuration to find a setting rather than live
performance. Also, automation in blue is sample accurate, so when it
comes to rendering a piece, the values will be spot on.  For those
purposes, the parameter system in blue has been satisfactory for me.

I'll try out a quick experiment here with blue to see about performance.

Thanks!
steven


On Sat, May 22, 2010 at 10:13 PM, Jim Aikin  wrote:
>
> port and tonek both work, but they both start each new note with a pitch of
> 0, which is not desirable. Aside from this, either of them does give a
> smooth slider response in QuteCsound. However, blue's slider refresh rate
> (unless there's a UI feature I haven't yet spotted) is not fast enough to
> produce responsive real-time sliders.
>
> --JA
> --
> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> 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"

Hi Peiman,

That's mostly correct, though I think API mode should be considered
somewhat stable at this point (minus the issue on OSX and message
callbacks that needs to be sorted out). But yes, the focus has been
more on configuration and automation versus realtime performance.

As for port, it makes sense to have it slide at the start, as the
contents of the filter is initialized with 0 unless isig is given. If
port is used per-note, you might be able to get the current value of
the slider and initialize port with it using i(ksig), but it may
depend on implementation.  blue uses a global ksig to handle parameter
values and automation, so that value would be there, but I think
QuteCsound uses invalue, which I don't know its implementation to know
if it will have the ksig ready at init time to grab to give to port.

Since sliders are used in a global way, it should be filtered on a
global level as well.  Perhaps SC3 has the widgets themselves doing
the signal smoothing?  Maybe QuteCsound and blue should both offer a
way to have signal smoothing done in the host program rather than have
to deal within Csound. (If that's of interest for blue, please file a
request!)

Thanks!
steven

On Sat, May 22, 2010 at 10:26 PM, Peiman Khosravi
 wrote:
> Yes I believe blue's api mode is experimental at this time and not really
> meant for reliable real-time performance. It is more for tweaking purposes
> (I'm sure it will improve in the future), Steven please correct me if I'm
> wrong.
>
> I have also noticed the problem of a slide at the start of the note when
> using port. I guess the workaround would be to have the controller (and the
> port opcode) in a different instrument that is initialised before the actual
> note, or else have an internal mechanism of triggering the sound after the
> note has been initialised. But that's too much hassle really, it would be
> nice if there was an opcode that somehow managed to do this by itself. After
> all we don't have this problem in SC3!
>
> Best,
>
> P
>
> On 23 May 2010, at 03:13, Jim Aikin wrote:
>
>>
>> port and tonek both work, but they both start each new note with a pitch
>> of
>> 0, which is not desirable. Aside from this, either of them does give a
>> smooth slider response in QuteCsound. However, blue's slider refresh rate
>> (unless there's a UI feature I haven't yet spotted) is not fast enough to
>> produce responsive real-time sliders.
>>
>> --JA
>> --
>> View this message in context:
>> http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> 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"
>
>


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"

Thank Steven, it all makes sense.

I don't know about the SC3 implementation of widgets to answer your  
question. But it certainly makes sense for blue and QuteCsound to do  
this smoothing internally.

Best,

Peiman

On 23 May 2010, at 03:40, Steven Yi wrote:

> Hi Peiman,
>
> That's mostly correct, though I think API mode should be considered
> somewhat stable at this point (minus the issue on OSX and message
> callbacks that needs to be sorted out). But yes, the focus has been
> more on configuration and automation versus realtime performance.
>
> As for port, it makes sense to have it slide at the start, as the
> contents of the filter is initialized with 0 unless isig is given. If
> port is used per-note, you might be able to get the current value of
> the slider and initialize port with it using i(ksig), but it may
> depend on implementation.  blue uses a global ksig to handle parameter
> values and automation, so that value would be there, but I think
> QuteCsound uses invalue, which I don't know its implementation to know
> if it will have the ksig ready at init time to grab to give to port.
>
> Since sliders are used in a global way, it should be filtered on a
> global level as well.  Perhaps SC3 has the widgets themselves doing
> the signal smoothing?  Maybe QuteCsound and blue should both offer a
> way to have signal smoothing done in the host program rather than have
> to deal within Csound. (If that's of interest for blue, please file a
> request!)
>
> Thanks!
> steven
>
> On Sat, May 22, 2010 at 10:26 PM, Peiman Khosravi
>  wrote:
>> Yes I believe blue's api mode is experimental at this time and not  
>> really
>> meant for reliable real-time performance. It is more for tweaking  
>> purposes
>> (I'm sure it will improve in the future), Steven please correct me  
>> if I'm
>> wrong.
>>
>> I have also noticed the problem of a slide at the start of the note  
>> when
>> using port. I guess the workaround would be to have the controller  
>> (and the
>> port opcode) in a different instrument that is initialised before  
>> the actual
>> note, or else have an internal mechanism of triggering the sound  
>> after the
>> note has been initialised. But that's too much hassle really, it  
>> would be
>> nice if there was an opcode that somehow managed to do this by  
>> itself. After
>> all we don't have this problem in SC3!
>>
>> Best,
>>
>> P
>>
>> On 23 May 2010, at 03:13, Jim Aikin wrote:
>>
>>>
>>> port and tonek both work, but they both start each new note with a  
>>> pitch
>>> of
>>> 0, which is not desirable. Aside from this, either of them does  
>>> give a
>>> smooth slider response in QuteCsound. However, blue's slider  
>>> refresh rate
>>> (unless there's a UI feature I haven't yet spotted) is not fast  
>>> enough to
>>> produce responsive real-time sliders.
>>>
>>> --JA
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> 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"
>>
>>
>
>
> 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"

Hi Jim,

I use the following kludge to prevent slides up from zero:

iporttime = 0.1
kporttime linseg 0,0.001,iporttime,1,iporttime
kvar portk kvar, kporttime

Byr,
Iain

----------------------------------------
> Date: Sat, 22 May 2010 19:13:26 -0700
> From: midiguru23@sbcglobal.net
> To: csound@lists.bath.ac.uk
> Subject: [Csnd] Re: Re al-Time Mouse Sliders (Zippering)
>
>
> port and tonek both work, but they both start each new note with a pitch of
> 0, which is not desirable. Aside from this, either of them does give a
> smooth slider response in QuteCsound. However, blue's slider refresh rate
> (unless there's a UI feature I haven't yet spotted) is not fast enough to
> produce responsive real-time sliders.
>
> --JA
> --
> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
>
>
> 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"
>
 		 	   		  
_________________________________________________________________
http://clk.atdmt.com/UKM/go/197222280/direct/01/
Do you have a story that started on Hotmail? Tell us now

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"

I would have thought that by doing

kvar init  0.1

kvar portk kvar, kporttime

your variable would not start at 0.



On 23 May 2010, at 19:33, Iain McCurdy wrote:

>
> Hi Jim,
>
> I use the following kludge to prevent slides up from zero:
>
> iporttime = 0.1
> kporttime linseg 0,0.001,iporttime,1,iporttime
> kvar portk kvar, kporttime
>
> Byr,
> Iain
>
> ----------------------------------------
>> Date: Sat, 22 May 2010 19:13:26 -0700
>> From: midiguru23@sbcglobal.net
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: Re al-Time Mouse Sliders (Zippering)
>>
>>
>> port and tonek both work, but they both start each new note with a  
>> pitch of
>> 0, which is not desirable. Aside from this, either of them does  
>> give a
>> smooth slider response in QuteCsound. However, blue's slider  
>> refresh rate
>> (unless there's a UI feature I haven't yet spotted) is not fast  
>> enough to
>> produce responsive real-time sliders.
>>
>> --JA
>> --
>> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>>
>>
>> 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"
>>
> 		 	   		
> _________________________________________________________________
> http://clk.atdmt.com/UKM/go/197222280/direct/01/
> Do you have a story that started on Hotmail? Tell us now
>
> 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"

Unfortunately not Victor. Also, the variable in question should be initialized to that currently held by the GUI widget.
Iain 

----------------------------------------
> From: Victor.Lazzarini@nuim.ie
> To: csound@lists.bath.ac.uk
> Date: Sun, 23 May 2010 19:48:26 +0100
> Subject: [Csnd] Re: RE: Re: Re al-Time Mouse Sliders (Zippering)
>
> I would have thought that by doing
>
> kvar init 0.1
>
> kvar portk kvar, kporttime
>
> your variable would not start at 0.
>
>
>
> On 23 May 2010, at 19:33, Iain McCurdy wrote:
>
>>
>> Hi Jim,
>>
>> I use the following kludge to prevent slides up from zero:
>>
>> iporttime = 0.1
>> kporttime linseg 0,0.001,iporttime,1,iporttime
>> kvar portk kvar, kporttime
>>
>> Byr,
>> Iain
>>
>> ----------------------------------------
>>> Date: Sat, 22 May 2010 19:13:26 -0700
>>> From: midiguru23@sbcglobal.net
>>> To: csound@lists.bath.ac.uk
>>> Subject: [Csnd] Re: Re al-Time Mouse Sliders (Zippering)
>>>
>>>
>>> port and tonek both work, but they both start each new note with a
>>> pitch of
>>> 0, which is not desirable. Aside from this, either of them does
>>> give a
>>> smooth slider response in QuteCsound. However, blue's slider
>>> refresh rate
>>> (unless there's a UI feature I haven't yet spotted) is not fast
>>> enough to
>>> produce responsive real-time sliders.
>>>
>>> --JA
>>> --
>>> View this message in context: http://old.nabble.com/Real-Time-Mouse-Sliders-%28Zippering%29-tp28646850p28647196.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> 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"
>>>
>>
>> _________________________________________________________________
>> http://clk.atdmt.com/UKM/go/197222280/direct/01/
>> Do you have a story that started on Hotmail? Tell us now
>>
>> 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"
>
 		 	   		  
_________________________________________________________________
http://clk.atdmt.com/UKM/go/195013117/direct/01/
We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now

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"