[Csnd] Towards the next release

Date	2009-12-22 09:39
From	john ffitch
Subject	[Csnd] Towards the next release
	We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-23 21:54
From	J
Subject	[Csnd] Re: Towards the next release
	This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:01
From	Peiman Khosravi
Subject	[Csnd] Re: Re: Towards the next release
	On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Yes I've had similar results. Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:14
From	Victor Lazzarini
Subject	[Csnd] Re: Re: Re: Towards the next release
	Note that balance does what it says on the tin; it's been there since the first version of Csound and it is a well-known algorithm. It does not make any sense to change it. It contains a parameter to set the lp cutoff frequency which can modify the time constant of the averaging process, which can be used for smoother, but also smeared, results. I recommend reading Dodge & Jerse if you don't understand how the opcode works. Also note that Csound has alternative envelope followers: follow and follow2, which might be used instead of balance in certain applications. Victor On 24 Dec 2009, at 00:01, Peiman Khosravi wrote: On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Yes I've had similar results. Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:26
From	Peiman Khosravi
Subject	[Csnd] Re: Re: Towards the next release
	One thing I mentioned before is the smearing effect of phase loss with pvsbandr and pvsbandp. I don't know what algorithm is being used but I don't think it should be touching the bin's phases as there is no need to change the frequency data. Or am I missing something? Thanks Peiman On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:35
From	Victor Lazzarini
Subject	[Csnd] Re: Re: Re: Towards the next release
	I looked at the code and freqs are not changed, only amps. However, because of the integration involved in the resynthesis process, it might be the case that phases are being smeared because of this. It's only an opinion, as I did not look into the matter in detail. On 24 Dec 2009, at 00:26, Peiman Khosravi wrote: One thing I mentioned before is the smearing effect of phase loss with pvsbandr and pvsbandp. I don't know what algorithm is being used but I don't think it should be touching the bin's phases as there is no need to change the frequency data. Or am I missing something? Thanks Peiman On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:41
From	Peiman Khosravi
Subject	[Csnd] Re: Re: Re: Re: Towards the next release
	I see. Thanks for looking. Interestingly I don't get any smearing when using a UDO to do the same task. Also there is not much smearing when doing a straight pvs resynthesis. The smearing is unfortunately quite drastic with these two opcodes, which makes them unsuitable for transient sounds. Best, Peiman On 24 Dec 2009, at 00:35, Victor Lazzarini wrote: I looked at the code and freqs are not changed, only amps. However, because of the integration involved in the resynthesis process, it might be the case that phases are being smeared because of this. It's only an opinion, as I did not look into the matter in detail. On 24 Dec 2009, at 00:26, Peiman Khosravi wrote: One thing I mentioned before is the smearing effect of phase loss with pvsbandr and pvsbandp. I don't know what algorithm is being used but I don't think it should be touching the bin's phases as there is no need to change the frequency data. Or am I missing something? Thanks Peiman On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 00:57
From	Victor Lazzarini
Subject	[Csnd] Re: Re: Re: Re: Re: Towards the next release
	Well, with straight resynthesis, smearing should not occur (phases would be reset to start with and then would be correct relatively). However, whenever the PV signal is modified, even it's only amps, it's still possible that smearing would result. But I am interested to hear that the UDO code does not smear it. Perhaps you could prepare a simple CSD comparing the two for John to investigate if there is a bug (since it's his code). I can't see anything wrong with it. Victor On 24 Dec 2009, at 00:41, Peiman Khosravi wrote: I see. Thanks for looking. Interestingly I don't get any smearing when using a UDO to do the same task. Also there is not much smearing when doing a straight pvs resynthesis. The smearing is unfortunately quite drastic with these two opcodes, which makes them unsuitable for transient sounds. Best, Peiman On 24 Dec 2009, at 00:35, Victor Lazzarini wrote: I looked at the code and freqs are not changed, only amps. However, because of the integration involved in the resynthesis process, it might be the case that phases are being smeared because of this. It's only an opinion, as I did not look into the matter in detail. On 24 Dec 2009, at 00:26, Peiman Khosravi wrote: One thing I mentioned before is the smearing effect of phase loss with pvsbandr and pvsbandp. I don't know what algorithm is being used but I don't think it should be touching the bin's phases as there is no need to change the frequency data. Or am I missing something? Thanks Peiman On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 03:22
From	Peiman Khosravi
Subject	[Csnd] Re: Re: Re: Re: Re: Re: Towards the next release
Attachments	testpvsfilt.csd
	Hello, I have attached a CSD to compare the two. It uses the "beats.wav" from the manual's examples folder. Best, Peiman

Date	2009-12-24 03:31
From	Peiman Khosravi
Subject	[Csnd] Re: Re: Re: Re: Re: Re: Towards the next release
	I'm just guessing. The opcode is more complicated than the UDO as it allow defining a trapezium shape. So that part of the algorithm may well be causing the smearing. Peiman On 24 Dec 2009, at 00:57, Victor Lazzarini wrote: Well, with straight resynthesis, smearing should not occur (phases would be reset to start with and then would be correct relatively). However, whenever the PV signal is modified, even it's only amps, it's still possible that smearing would result. But I am interested to hear that the UDO code does not smear it. Perhaps you could prepare a simple CSD comparing the two for John to investigate if there is a bug (since it's his code). I can't see anything wrong with it. Victor On 24 Dec 2009, at 00:41, Peiman Khosravi wrote: I see. Thanks for looking. Interestingly I don't get any smearing when using a UDO to do the same task. Also there is not much smearing when doing a straight pvs resynthesis. The smearing is unfortunately quite drastic with these two opcodes, which makes them unsuitable for transient sounds. Best, Peiman On 24 Dec 2009, at 00:35, Victor Lazzarini wrote: I looked at the code and freqs are not changed, only amps. However, because of the integration involved in the resynthesis process, it might be the case that phases are being smeared because of this. It's only an opinion, as I did not look into the matter in detail. On 24 Dec 2009, at 00:26, Peiman Khosravi wrote: One thing I mentioned before is the smearing effect of phase loss with pvsbandr and pvsbandp. I don't know what algorithm is being used but I don't think it should be touching the bin's phases as there is no need to change the frequency data. Or am I missing something? Thanks Peiman On 23 Dec 2009, at 21:54, J wrote: This is good news indeed. Aside from longer-term improvements I've seen discussed, such as dynamic instrument allocation, I'd like to see as many i-rate controls given the ability to be controlled at k-rate as possible; streson and the vbap and ambisonic opcodes spring to mind, but I'm sure there are dozens more that could benefit from this. Also, I'm not sure it's a bug as such, but I've got widely varying results from the balance opcode, with occasionally a lot of pumping and breathing - perhaps a smoothing or attack/decay parameter would help? Best, Jeremy On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote: We are considering a new release of Csound in mid January. Now is the time to make your requests and bug/oddity reports. Naturally we do not promise to implement them all..... But at last teaching is over and there is a break ==John ffitch Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date

2009-12-24 09:31

From

cameron bobro

Subject

[Csnd] Re: Towards the next release

Great! Opcodes which would be very nice would be odd-order Chebyshevs and a dedicated Chebyshev bandpass opcode with k-rate bandwidth control.

Also, an exponential version of loopseg.

As far as bugs and odd behaviour, the current (both penultimate releases IIRC)combination I have of WinXsoundPro and Csound on my laptop doesn't exhibit any.

And a note about realtime use: I'm running ungodly stuff with virtual midi link to the software sequencer, in realtime (with a big buffer for the heaviest instruments, perfectly fine for working from a sequencer). The CPU usage is interesting- there

is a huge hit at first, like 50+ percent, running even a simple orchestra. From there on though, piling on oscil3's, immense wavetables, exponential and interpolated everything, only adds small amounts of usage, and it will go over 90% CPU usage without glitches. What this works out to be is that the computer (Centrino Duo 1.6, WinXP) becomes a dedicated Csound+audio/midi sequencer synthesizer, running at 192k with a USB ADDA.

And, performance is an on/off kind of thing- an orchestra will either run in realtime, or it won't, so I can literally go off and have a beer when Csound is integrated into an interactive live performance for example. Something of a shock to my Pd colleagues. :-P

On Tue, Dec 22, 2009 at 9:39 AM, john ffitch <jpff@codemist.co.uk> wrote:

We are considering a new release of Csound in mid January. Now is the
time to make your requests and bug/oddity reports. Naturally we do
not promise to implement them all..... But at last teaching is over
and there is a break
==John ffitch

Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 15:11
From	mark jamerson
Subject	[Csnd] Re: Towards the next release
	> As far as bugs and odd behaviour, the current (both > penultimate releases IIRC)combination I have of WinXsoundPro > and Csound on my laptop doesn't exhibit any. > > I am going to second this!! Outside of my dream opcodes, such as 'makeTop40Hit' and 'superCoolExperimentalMusic', Csound is working perfectly for me. I would like to take this time to thank the developers, as well as the community, for an excellent tool. Keep up the good work, and have Happy Holidays!!! Mark Jamerson Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 15:30
From	Dave Phillips
Subject	[Csnd] Re: Re: Towards the next release
	mark jamerson wrote: > ... Outside of my dream opcodes, such as 'makeTop40Hit' and 'superCoolExperimentalMusic', Csound is working perfectly for me. I would like to take this time to thank the developers, as well as the community, for an excellent tool. Keep up the good work, and have Happy Holidays!!! > > Mark, Christmas is coming soon. Perhaps you'll be lucky enough to find one of these pups underneath your tree: http://www.theinternetnowinhandybookform.com/schmapple/dreamonpro.html Or maybe one of these will fit the bill: http://www.rane.com/pi14.html Good luck ! And Happy Holidays to all Csound users and devs ! Best, dp Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2009-12-24 16:12
From	Michael Gogins
Subject	[Csnd] Re: Re: Re: Towards the next release
	I would like to add to the Csound API samplewise access to spin, spout, and control channels. I have already done part of this work but it is not yet checked in or tested. This would simplify use of the Csound API for developers embedding Csound in other software that is sending and receiving audio to and from Csound. Regards, Mike On 12/24/09, Dave Phillips wrote: > mark jamerson wrote: >> ... Outside of my dream opcodes, such as 'makeTop40Hit' and >> 'superCoolExperimentalMusic', Csound is working perfectly for me. I >> would like to take this time to thank the developers, as well as the >> community, for an excellent tool. Keep up the good work, and have Happy >> Holidays!!! >> >> > > Mark, Christmas is coming soon. Perhaps you'll be lucky enough to find > one of these pups underneath your tree: > > http://www.theinternetnowinhandybookform.com/schmapple/dreamonpro.html > > Or maybe one of these will fit the bill: > > http://www.rane.com/pi14.html > > Good luck ! > > And Happy Holidays to all Csound users and devs ! > > Best, > > dp > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" >

Date	2010-01-07 18:34
From	joachim heintz
Subject	[Csnd] Re: Towards the next release
	Thanks for the question about requests. I'd love to see a new member of the filelen, filesr ... family. Something like itype filetype ilfile itype would for instance return 1 for WAV, 2 for AIFF, 3 for raw, 4 for IRCAM, 5 for MP3, 6 for OGG. I need this for writing an opcode which accepts any soundfile and selects than particulary between soundin and mp3in. Or when I read in a file, make some transformations and want to export in the same type. Ciao - joachim Am 22.12.2009 um 10:39 schrieb john ffitch: > We are considering a new release of Csound in mid January. Now is the > time to make your requests and bug/oddity reports. Naturally we do > not promise to implement them all..... But at last teaching is over > and there is a break > ==John ffitch > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2010-01-07 18:42
From	joachim heintz
Subject	[Csnd] Re: Towards the next release
	I don't know if it has yet been reported: Line count is incorrect when /*/ as comments are used (no problems with ";" comments). For example, this reports "3 lines read" (instead of 6): -n instr 1 / abla soundin 1 out abls */ endin i 1 0 1 e Thanks - joachim Am 22.12.2009 um 10:39 schrieb john ffitch: > We are considering a new release of Csound in mid January. Now is the > time to make your requests and bug/oddity reports. Naturally we do > not promise to implement them all..... But at last teaching is over > and there is a break > ==John ffitch > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2010-01-08 08:36
From	joachim heintz
Subject	[Csnd] Re: Re: Towards the next release
	sorry, i meant: i need it for writing a user-defined-opcode, not a usual opcode of course Am 07.01.2010 um 19:34 schrieb joachim heintz: > Thanks for the question about requests. I'd love to see a new member > of the filelen, filesr ... family. Something like > itype filetype ilfile > itype would for instance return 1 for WAV, 2 for AIFF, 3 for raw, 4 > for IRCAM, 5 for MP3, 6 for OGG. > > I need this for writing an opcode which accepts any soundfile and > selects than particulary between soundin and mp3in. > Or when I read in a file, make some transformations and want to > export in the same type. > > Ciao - > > joachim > > > > Am 22.12.2009 um 10:39 schrieb john ffitch: > >> We are considering a new release of Csound in mid January. Now is >> the >> time to make your requests and bug/oddity reports. Naturally we do >> not promise to implement them all..... But at last teaching is over >> and there is a break >> ==John ffitch >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@lists.bath.ac.uk with body >> "unsubscribe csound" >> > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body > "unsubscribe csound" > Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2010-01-12 00:24
From	moleculeColony
Subject	[Csnd] Re: Towards the next release
	Here's my main problem with the schedkwhen öpcode. There is also another one that crops up when you use FLsetValue_i, but maybe it's easier to blame that one on the FLTK. If you run the following program it will activate instrument 2 although it shouldn't do so. sr = 44100 instr 1 ktr init .3 if ktr=1 then schedkwhen ktr,0,0,2,0,1 printks "no",.1 endif endin instr 2 printks "error ",.1 ao oscil 10000,100,1 out ao endin f1 0 1024 10 1 i 1 0 1 e It also does so if you do instr 1 ktr init 0 if ktr=1 then schedkwhen 1,0,0,2,0,1 endif endin Potentially dangerous, as it activates instruments when you don't think it would do so, and hard to find since all the other things inside the if...then keep silent. And now I was having this Opera bug where the right click opens the dialogue for installing the next dictionary for my spell checker when all I wanted was to paste another piece of code. And then I found out I din't have to paste it because I myself was erroneous in another assumption. Strange. Maybe sometimes bugs force us to do the right thing. But anyway, all the imperative programming languages have severe problems with side effects, that's why I'm more and more inclined to abandon all of them (including Csound) and settle with Haskell, not the only, but the one and best language that doesn't allow strange things like these to happen. (Someone wants to help me write an audio DSL there?) Also I found a more human responsible error today: In the documentation for mac the order of variables is reversed. Not a big thing, but it sure made me believe there's another bug in Csound, as you know, people like me extrapolate exponentially any bug they find somewhere into the whole piece of it. -- View this message in context: http://old.nabble.com/Towards-the-next-release-tp26896079p27120443.html Sent from the Csound - General mailing list archive at Nabble.com. Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2010-01-12 01:31
From	Adam Puckett
Subject	[Csnd] Re: Re: Towards the next release
	There seems to be a problem with your code. You have "=" insted of "==". --- On Mon, 1/11/10, moleculeColony wrote: > From: moleculeColony > Subject: [Csnd] Re: Towards the next release > To: csound@lists.bath.ac.uk > Date: Monday, January 11, 2010, 7:24 PM > > Here's my main problem with the schedkwhen öpcode. There > is also another one > that crops up when you use FLsetValue_i, but maybe it's > easier to blame that > one on the FLTK. > > If you run the following program it will activate > instrument 2 although it > shouldn't do so. > > > > > sr = 44100 > > instr 1 > ktr init .3 > if ktr=1 then > schedkwhen ktr,0,0,2,0,1 > printks "no",.1 > endif > endin > > instr 2 > printks "error ",.1 > ao oscil 10000,100,1 > out ao > endin > > > > f1 0 1024 10 1 > i 1 0 1 > e > > > > > It also does so if you do > > > instr 1 > ktr init 0 > if ktr=1 then > schedkwhen 1,0,0,2,0,1 > endif > endin > > > Potentially dangerous, as it activates instruments when you > don't think it > would do so, and hard to find since all the other things > inside the > if...then keep silent. > > And now I was having this Opera bug where the right click > opens the dialogue > for installing the next dictionary for my spell checker > when all I wanted > was to paste another piece of code. And then I found out I > din't have to > paste it because I myself was erroneous in another > assumption. Strange. > Maybe sometimes bugs force us to do the right thing. > > But anyway, all the imperative programming languages have > severe problems > with side effects, that's why I'm more and more inclined to > abandon all of > them (including Csound) and settle with Haskell, not the > only, but the one > and best language that doesn't allow strange things like > these to happen. > (Someone wants to help me write an audio DSL there?) > > Also I found a more human responsible error today: In the > documentation for > mac the order of variables is reversed. Not a big thing, > but it sure made me > believe there's another bug in Csound, as you know, people > like me > extrapolate exponentially any bug they find somewhere into > the whole piece > of it. > > > -- > View this message in context: http://old.nabble.com/Towards-the-next-release-tp26896079p27120443.html > Sent from the Csound - General mailing list archive at > Nabble.com. > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk > with body "unsubscribe csound" Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Date	2010-01-13 00:29
From	moleculeColony
Subject	[Csnd] Re: Re: Towards the next release
	The effect is the same. Even if you use brackets. And the next bug I encountered is this one. The second schedkwhen blocks the first one. Here: sr = 44100 instr 1 schedkwhen 1,.1,0,3,0,-1,1 endin instr 2 schedkwhen 1,.1,0,3,0,-1,2 endin instr 3 print p4 schedkwhen 1,0,0,4,0,0,p4 turnoff endin instr 4 print p4 endin i1 0 1 i2 0 1 e It doesn't do so when you call i4 with a finite duration, or just initialize it. Seems like later instances overwrite the pointer for previous ones, since if you extend this chain only the latest of them will come through. Maybe some relation to the other bug where the pointer of the schedkwhen gets set too early, at init time, before the if...then is evaluated, and here also, where all the init time pointers overwrite each other until only one of them is remaining.

Date	2010-01-13 00:31
From	moleculeColony
Subject	[Csnd] Re: Re: Towards the next release
	sorry, forgot the quote (always am deleting these things for aesthetical reasons, but probably they're necessary for some of you to ge the context) adam puckett wrote: > > There seems to be a problem with your code. You have "=" insted of "==". > > --- On Mon, 1/11/10, moleculeColony wrote: > >> From: moleculeColony >> Subject: [Csnd] Re: Towards the next release >> To: csound@lists.bath.ac.uk >> Date: Monday, January 11, 2010, 7:24 PM >> >> Here's my main problem with the schedkwhen öpcode. There >> is also another one >> that crops up when you use FLsetValue_i, but maybe it's >> easier to blame that >> one on the FLTK. >> >> If you run the following program it will activate >> instrument 2 although it >> shouldn't do so. >> >> >> >> >> sr = 44100 >> >> instr 1 >> ktr init .3 >> if ktr=1 then >> schedkwhen ktr,0,0,2,0,1 >> printks "no",.1 >> endif >> endin >> >> instr 2 >> printks "error ",.1 >> ao oscil 10000,100,1 >> out ao >> endin >> >> >> >> f1 0 1024 10 1 >> i 1 0 1 >> e >> >> >> >> >> It also does so if you do >> >> >> instr 1 >> ktr init 0 >> if ktr=1 then >> schedkwhen 1,0,0,2,0,1 >> endif >> endin >> >> >> Potentially dangerous, as it activates instruments when you >> don't think it >> would do so, and hard to find since all the other things >> inside the >> if...then keep silent. >> >> And now I was having this Opera bug where the right click >> opens the dialogue >> for installing the next dictionary for my spell checker >> when all I wanted >> was to paste another piece of code. And then I found out I >> din't have to >> paste it because I myself was erroneous in another >> assumption. Strange. >> Maybe sometimes bugs force us to do the right thing. >> >> But anyway, all the imperative programming languages have >> severe problems >> with side effects, that's why I'm more and more inclined to >> abandon all of >> them (including Csound) and settle with Haskell, not the >> only, but the one >> and best language that doesn't allow strange things like >> these to happen. >> (Someone wants to help me write an audio DSL there?) >> >> Also I found a more human responsible error today: In the >> documentation for >> mac the order of variables is reversed. Not a big thing, >> but it sure made me >> believe there's another bug in Csound, as you know, people >> like me >> extrapolate exponentially any bug they find somewhere into >> the whole piece >> of it. >> >> >> -- >> View this message in context: >> http://old.nabble.com/Towards-the-next-release-tp26896079p27120443.html >> Sent from the Csound - General mailing list archive at >> Nabble.com. >> >> >> >> Send bugs reports to this list. >> To unsubscribe, send email sympa@lists.bath.ac.uk >> with body "unsubscribe csound" > > > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" > -- View this message in context: http://old.nabble.com/Towards-the-next-release-tp26896079p27137627.html Sent from the Csound - General mailing list archive at Nabble.com. Send bugs reports to this list. To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"