Hi all.

It's very hard to figure out exactly where this problem is
originating, but it only seems to happen on Windows.  Unfortunately,
this little script requires Tix as well as csnd.py.  I tried to remove
as much of the non-Tkinter stuff as I could, but the dropdown lists in
the audio options box are hard to reproduce in pure Tkinter.
So if you run this, you should be able to click once on the empty
window to open the audio options, just in order to set up the sound,
and after that, you can just hit the spacebar to play a series of
noise bursts (turn the speakers down!).  The problem comes after 6
seconds when it ends, or if you hit the spacebar again to end it; in
Windows, I get this error dialog:
---------------------------------------------
python.exe - Application Error
The instruction at "0x7c9104da" referenced memory at "0xfffffffd". The
memory could not be "read".
Click on OK to terminate the program...
---------------------------------------------
The infuriating part is that this only happens at the moment when I
want the #$*! subprocess to close anyway; if it didn't force me to
click the OK button in order to close it I would have no complaints.
I've tried sys.exit(n), os._exit(n), and a few others, but they all
just hang.
I have tried everything I can imagine, and inserted numerous debugging
printouts, but as near as I can tell it just raises this error after
everything is finished, the PerformanceThread is stopped, the other
threads have ended, and I just want to brush everything under the
carpet.  In other words, the subprocess ("wtfrataudio.py") is
completely finished but hits an error closing.
I don't know if this is a Csound thing or a subprocess thing or what.
Google results have been, as usual, a haystack.

I apologize if the scripts are hard to follow, I'm hoping someone will
recognize what I'm trying to do.  I removed 90% of my program to try
to narrow it down.  I bet lots of you can relate to how it feels to
spend a year creating a "cross-platform" app only to have it fail
miserably on other platforms.  Turns out there is also no Tix binary
for OSX Intel, so that'll be another story, straight out of Charles
Dickens, to be posted in chapters to other mailing lists.

Thanks for any suggestions.
-Chuckk

-- 
http://www.badmuthahubbard.com

The scripts.
The command:
"python wtfrationale.py"

I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
that is the reason? So try adding one after calling 'Stop()'.

Regards

Victor
----- Original Message ----- 
From: "Chuckk Hubbard" 
To: "Csound List" 
Sent: Tuesday, March 10, 2009 9:59 PM
Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...


> The scripts.
> The command:
> "python wtfrationale.py"
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

I hadn't considered that, but I can't tell any difference.
One problem I thought I had solved was that, if the score ends, the
engine should tell the GUI to stop, and if the user stops it, the GUI
should tell the engine to stop, but neither should call the other
after being called.  Seems like CsoundPerformanceThread.Join() should
apply more to reaching the end of the score, but maybe I
misunderstand.  If I place it before Stop(), obviously, it doesn't
stop, but after Stop() I don't see any effect.
It occurred to me this could be avoided by using PerformKsmps, and
only proceeding if the score is still active; if it's really necessary
I'll recode it all, but I hope it's not.

-Chuckk

On Wed, Mar 11, 2009 at 12:44 AM, victor  wrote:
> I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
> that is the reason? So try adding one after calling 'Stop()'.
>
> Regards
>
> Victor
> ----- Original Message ----- From: "Chuckk Hubbard"
> 
> To: "Csound List" 
> Sent: Tuesday, March 10, 2009 9:59 PM
> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>
>
>> The scripts.
>> The command:
>> "python wtfrationale.py"
>>
>> 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"
>



-- 
http://www.badmuthahubbard.com

Join() is placed after Stop() because the thread might take a while
to finish, so you join it until it ends, avoiding any possible problems.

But if it doesn't fix it, the problem is elsewhere. I can't check it right
now because I don't have the python interface built on this machine.

Victor
----- Original Message ----- 
From: "Chuckk Hubbard" 
To: 
Sent: Tuesday, March 10, 2009 11:10 PM
Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping Csound...


>I hadn't considered that, but I can't tell any difference.
> One problem I thought I had solved was that, if the score ends, the
> engine should tell the GUI to stop, and if the user stops it, the GUI
> should tell the engine to stop, but neither should call the other
> after being called.  Seems like CsoundPerformanceThread.Join() should
> apply more to reaching the end of the score, but maybe I
> misunderstand.  If I place it before Stop(), obviously, it doesn't
> stop, but after Stop() I don't see any effect.
> It occurred to me this could be avoided by using PerformKsmps, and
> only proceeding if the score is still active; if it's really necessary
> I'll recode it all, but I hope it's not.
>
> -Chuckk
>
> On Wed, Mar 11, 2009 at 12:44 AM, victor  wrote:
>> I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
>> that is the reason? So try adding one after calling 'Stop()'.
>>
>> Regards
>>
>> Victor
>> ----- Original Message ----- From: "Chuckk Hubbard"
>> 
>> To: "Csound List" 
>> Sent: Tuesday, March 10, 2009 9:59 PM
>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>
>>
>>> The scripts.
>>> The command:
>>> "python wtfrationale.py"
>>>
>>> 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"
>>
>
>
>
> -- 
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

I built the interface, but can't run your files because they need
tix and tix can only be built with msvc or borland (according to
their site) and I have only gcc/mingw.

Victor
----- Original Message ----- 
From: "victor" 
To: 
Sent: Tuesday, March 10, 2009 11:15 PM
Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping 
Csound...


> Join() is placed after Stop() because the thread might take a while
> to finish, so you join it until it ends, avoiding any possible problems.
>
> But if it doesn't fix it, the problem is elsewhere. I can't check it right
> now because I don't have the python interface built on this machine.
>
> Victor
> ----- Original Message ----- 
> From: "Chuckk Hubbard" 
> To: 
> Sent: Tuesday, March 10, 2009 11:10 PM
> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping 
> Csound...
>
>
>>I hadn't considered that, but I can't tell any difference.
>> One problem I thought I had solved was that, if the score ends, the
>> engine should tell the GUI to stop, and if the user stops it, the GUI
>> should tell the engine to stop, but neither should call the other
>> after being called.  Seems like CsoundPerformanceThread.Join() should
>> apply more to reaching the end of the score, but maybe I
>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>> stop, but after Stop() I don't see any effect.
>> It occurred to me this could be avoided by using PerformKsmps, and
>> only proceeding if the score is still active; if it's really necessary
>> I'll recode it all, but I hope it's not.
>>
>> -Chuckk
>>
>> On Wed, Mar 11, 2009 at 12:44 AM, victor  
>> wrote:
>>> I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
>>> that is the reason? So try adding one after calling 'Stop()'.
>>>
>>> Regards
>>>
>>> Victor
>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>> 
>>> To: "Csound List" 
>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>
>>>
>>>> The scripts.
>>>> The command:
>>>> "python wtfrationale.py"
>>>>
>>>> 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"
>>>
>>
>>
>>
>> -- 
>> http://www.badmuthahubbard.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" 

There is one in Lettuce, there is also another one I came across while
building the one in lettuce but I can't think of it's name right now.
Perhaps someone else can advise?

2009/3/10 Olavo Peres :
> Hi,
>
> I'm searching a visual object (FLTK) for Csound to produce envelopes, like
> an 'envgen' of PureData,
> Does somebody know one?
>
>  thanks,
> olavo
>
>
> ________________________________
> Diversão em dobro: compartilhe fotos enquanto conversa usando o Windows Live
> Messenger.

On a side note, i can give Andres the code I used in lettuce so maybe
he can implement one in QuteCsound. If you're out there Andres let me
know!

2009/3/10 Rory Walsh :
> There is one in Lettuce, there is also another one I came across while
> building the one in lettuce but I can't think of it's name right now.
> Perhaps someone else can advise?
>
> 2009/3/10 Olavo Peres :
>> Hi,
>>
>> I'm searching a visual object (FLTK) for Csound to produce envelopes, like
>> an 'envgen' of PureData,
>> Does somebody know one?
>>
>>  thanks,
>> olavo
>>
>>
>> ________________________________
>> Diversão em dobro: compartilhe fotos enquanto conversa usando o Windows Live
>> Messenger.
>

I'm here =) Yes, let me know where in the sources it is and I'll have
a look. I've been thinking a lot about future directions for
QuteCsound, and this has actually come to mind.

Cheers,
Andrés

On Tue, Mar 10, 2009 at 7:00 PM, Rory Walsh  wrote:
> On a side note, i can give Andres the code I used in lettuce so maybe
> he can implement one in QuteCsound. If you're out there Andres let me
> know!
>
> 2009/3/10 Rory Walsh :
>> There is one in Lettuce, there is also another one I came across while
>> building the one in lettuce but I can't think of it's name right now.
>> Perhaps someone else can advise?
>>
>> 2009/3/10 Olavo Peres :
>>> Hi,
>>>
>>> I'm searching a visual object (FLTK) for Csound to produce envelopes, like
>>> an 'envgen' of PureData,
>>> Does somebody know one?
>>>
>>>  thanks,
>>> olavo
>>>
>>>
>>> ________________________________
>>> Diversão em dobro: compartilhe fotos enquanto conversa usando o Windows Live
>>> Messenger.
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



-- 


Andrés

OK, I downloaded a Tix binary somewhere, but I will try to replace the
Tix parts with Tkinter and repost.
-Chuckk

On Wed, Mar 11, 2009 at 1:29 AM, victor  wrote:
> I built the interface, but can't run your files because they need
> tix and tix can only be built with msvc or borland (according to
> their site) and I have only gcc/mingw.
>
> Victor
> ----- Original Message ----- From: "victor" 
> To: 
> Sent: Tuesday, March 10, 2009 11:15 PM
> Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping
> Csound...
>
>
>> Join() is placed after Stop() because the thread might take a while
>> to finish, so you join it until it ends, avoiding any possible problems.
>>
>> But if it doesn't fix it, the problem is elsewhere. I can't check it right
>> now because I don't have the python interface built on this machine.
>>
>> Victor
>> ----- Original Message ----- From: "Chuckk Hubbard"
>> 
>> To: 
>> Sent: Tuesday, March 10, 2009 11:10 PM
>> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping
>> Csound...
>>
>>
>>> I hadn't considered that, but I can't tell any difference.
>>> One problem I thought I had solved was that, if the score ends, the
>>> engine should tell the GUI to stop, and if the user stops it, the GUI
>>> should tell the engine to stop, but neither should call the other
>>> after being called.  Seems like CsoundPerformanceThread.Join() should
>>> apply more to reaching the end of the score, but maybe I
>>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>>> stop, but after Stop() I don't see any effect.
>>> It occurred to me this could be avoided by using PerformKsmps, and
>>> only proceeding if the score is still active; if it's really necessary
>>> I'll recode it all, but I hope it's not.
>>>
>>> -Chuckk
>>>
>>> On Wed, Mar 11, 2009 at 12:44 AM, victor 
>>> wrote:
>>>>
>>>> I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
>>>> that is the reason? So try adding one after calling 'Stop()'.
>>>>
>>>> Regards
>>>>
>>>> Victor
>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>> 
>>>> To: "Csound List" 
>>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>>
>>>>
>>>>> The scripts.
>>>>> The command:
>>>>> "python wtfrationale.py"
>>>>>
>>>>> 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"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.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"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
http://www.badmuthahubbard.com

very probably overkill, and with a definite learning curve, but if you 
try Surmulot you will have a very powerful envelope editor. see attached 
pictures: an envelope can be drawn with a variety of interpolation 
between breakpoints; it can then be broken as a linseg with arbitrary 
precision.


Surmulot:
http://www.zogotounga.net/surmulot/surmulot.html

regards,

Stef

Stef,

This looks really super.  Will check out soon.

John.... your suggestion to use brkpt?
- for Mac users - this is one of the Missing Utilities that is not  
part of the distribution.

And?

How do we use it - seems to be a tkl-tk util.  I did get a copy from  
Anthony Kozar, but it won't run
from the terminal?

-dB

On Mar 11, 2009, at 8:24 AM, Stéphane Rollandin wrote:

> very probably overkill, and with a definite learning curve, but if  
> you try Surmulot you will have a very powerful envelope editor. see  
> attached pictures: an envelope can be drawn with a variety of  
> interpolation between breakpoints; it can then be broken as a linseg  
> with arbitrary precision.
>
>
> Surmulot:
> http://www.zogotounga.net/surmulot/surmulot.html
>
> regards,
>
> Stef
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Hi again.
Okay, here is a Tkinter version that should run with any recent Python
with only csnd.py and the standard library.
Click the window to open audio options, and press space to start/stop
a 6-second score.  For me, in Windows, I get this error whether it
runs to the end of the score or I hit space to stop it...
Thanks!
-Chuckk

On Wed, Mar 11, 2009 at 1:29 AM, victor  wrote:
> I built the interface, but can't run your files because they need
> tix and tix can only be built with msvc or borland (according to
> their site) and I have only gcc/mingw.
>
> Victor
> ----- Original Message ----- From: "victor" 
> To: 
> Sent: Tuesday, March 10, 2009 11:15 PM
> Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping
> Csound...
>
>
>> Join() is placed after Stop() because the thread might take a while
>> to finish, so you join it until it ends, avoiding any possible problems.
>>
>> But if it doesn't fix it, the problem is elsewhere. I can't check it right
>> now because I don't have the python interface built on this machine.
>>
>> Victor
>> ----- Original Message ----- From: "Chuckk Hubbard"
>> 
>> To: 
>> Sent: Tuesday, March 10, 2009 11:10 PM
>> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping
>> Csound...
>>
>>
>>> I hadn't considered that, but I can't tell any difference.
>>> One problem I thought I had solved was that, if the score ends, the
>>> engine should tell the GUI to stop, and if the user stops it, the GUI
>>> should tell the engine to stop, but neither should call the other
>>> after being called.  Seems like CsoundPerformanceThread.Join() should
>>> apply more to reaching the end of the score, but maybe I
>>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>>> stop, but after Stop() I don't see any effect.
>>> It occurred to me this could be avoided by using PerformKsmps, and
>>> only proceeding if the score is still active; if it's really necessary
>>> I'll recode it all, but I hope it's not.
>>>
>>> -Chuckk
>>>
>>> On Wed, Mar 11, 2009 at 12:44 AM, victor 
>>> wrote:
>>>>
>>>> I don't see a call to CsoundPerformanceThread.Join() in your code. Maybe
>>>> that is the reason? So try adding one after calling 'Stop()'.
>>>>
>>>> Regards
>>>>
>>>> Victor
>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>> 
>>>> To: "Csound List" 
>>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>>
>>>>
>>>>> The scripts.
>>>>> The command:
>>>>> "python wtfrationale.py"
>>>>>
>>>>> 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"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.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"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
http://www.badmuthahubbard.com

Awesome.  It doesn't look like overkill, but the website is daunting
so far!  I must try it.
-Chuckk

On Wed, Mar 11, 2009 at 2:24 PM, Stéphane Rollandin
 wrote:
> very probably overkill, and with a definite learning curve, but if you try
> Surmulot you will have a very powerful envelope editor. see attached
> pictures: an envelope can be drawn with a variety of interpolation between
> breakpoints; it can then be broken as a linseg with arbitrary precision.
>
>
> Surmulot:
> http://www.zogotounga.net/surmulot/surmulot.html
>
> regards,
>
> Stef
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"



-- 
http://www.badmuthahubbard.com

how is it suppose to sound? No crashes here running to the end of the
score or hitting the space bar, I am afraid. But I just get noise bursts.
This is Vista (or bust!)

Victor
----- Original Message ----- 
From: "Chuckk Hubbard" 
To: 
Sent: Wednesday, March 11, 2009 1:53 PM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Python crashing in Windows on 
stopping Csound...


> Hi again.
> Okay, here is a Tkinter version that should run with any recent Python
> with only csnd.py and the standard library.
> Click the window to open audio options, and press space to start/stop
> a 6-second score.  For me, in Windows, I get this error whether it
> runs to the end of the score or I hit space to stop it...
> Thanks!
> -Chuckk
>
> On Wed, Mar 11, 2009 at 1:29 AM, victor  wrote:
>> I built the interface, but can't run your files because they need
>> tix and tix can only be built with msvc or borland (according to
>> their site) and I have only gcc/mingw.
>>
>> Victor
>> ----- Original Message ----- From: "victor" 
>> To: 
>> Sent: Tuesday, March 10, 2009 11:15 PM
>> Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping
>> Csound...
>>
>>
>>> Join() is placed after Stop() because the thread might take a while
>>> to finish, so you join it until it ends, avoiding any possible problems.
>>>
>>> But if it doesn't fix it, the problem is elsewhere. I can't check it 
>>> right
>>> now because I don't have the python interface built on this machine.
>>>
>>> Victor
>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>> 
>>> To: 
>>> Sent: Tuesday, March 10, 2009 11:10 PM
>>> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping
>>> Csound...
>>>
>>>
>>>> I hadn't considered that, but I can't tell any difference.
>>>> One problem I thought I had solved was that, if the score ends, the
>>>> engine should tell the GUI to stop, and if the user stops it, the GUI
>>>> should tell the engine to stop, but neither should call the other
>>>> after being called.  Seems like CsoundPerformanceThread.Join() should
>>>> apply more to reaching the end of the score, but maybe I
>>>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>>>> stop, but after Stop() I don't see any effect.
>>>> It occurred to me this could be avoided by using PerformKsmps, and
>>>> only proceeding if the score is still active; if it's really necessary
>>>> I'll recode it all, but I hope it's not.
>>>>
>>>> -Chuckk
>>>>
>>>> On Wed, Mar 11, 2009 at 12:44 AM, victor 
>>>> wrote:
>>>>>
>>>>> I don't see a call to CsoundPerformanceThread.Join() in your code. 
>>>>> Maybe
>>>>> that is the reason? So try adding one after calling 'Stop()'.
>>>>>
>>>>> Regards
>>>>>
>>>>> Victor
>>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>>> 
>>>>> To: "Csound List" 
>>>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>>>
>>>>>
>>>>>> The scripts.
>>>>>> The command:
>>>>>> "python wtfrationale.py"
>>>>>>
>>>>>> 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"
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> http://www.badmuthahubbard.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"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> -- 
> http://www.badmuthahubbard.com
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

That's a relief.  That's what it's supposed to be, just the simplest
instrument I could throw together for a quick test.
I suppose that means there's a problem with either my Python or my
Csound installation.
What versions were you using, by the way?  I'm using downloaded
binaries of both, Python 2.5.4 and Csound 5.10, the "f" version.

-Chuckk

On Wed, Mar 11, 2009 at 4:40 PM, victor  wrote:
> how is it suppose to sound? No crashes here running to the end of the
> score or hitting the space bar, I am afraid. But I just get noise bursts.
> This is Vista (or bust!)
>
> Victor
> ----- Original Message ----- From: "Chuckk Hubbard"
> 
> To: 
> Sent: Wednesday, March 11, 2009 1:53 PM
> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Python crashing in Windows on
> stopping Csound...
>
>
>> Hi again.
>> Okay, here is a Tkinter version that should run with any recent Python
>> with only csnd.py and the standard library.
>> Click the window to open audio options, and press space to start/stop
>> a 6-second score.  For me, in Windows, I get this error whether it
>> runs to the end of the score or I hit space to stop it...
>> Thanks!
>> -Chuckk
>>
>> On Wed, Mar 11, 2009 at 1:29 AM, victor  wrote:
>>>
>>> I built the interface, but can't run your files because they need
>>> tix and tix can only be built with msvc or borland (according to
>>> their site) and I have only gcc/mingw.
>>>
>>> Victor
>>> ----- Original Message ----- From: "victor" 
>>> To: 
>>> Sent: Tuesday, March 10, 2009 11:15 PM
>>> Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping
>>> Csound...
>>>
>>>
>>>> Join() is placed after Stop() because the thread might take a while
>>>> to finish, so you join it until it ends, avoiding any possible problems.
>>>>
>>>> But if it doesn't fix it, the problem is elsewhere. I can't check it
>>>> right
>>>> now because I don't have the python interface built on this machine.
>>>>
>>>> Victor
>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>> 
>>>> To: 
>>>> Sent: Tuesday, March 10, 2009 11:10 PM
>>>> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping
>>>> Csound...
>>>>
>>>>
>>>>> I hadn't considered that, but I can't tell any difference.
>>>>> One problem I thought I had solved was that, if the score ends, the
>>>>> engine should tell the GUI to stop, and if the user stops it, the GUI
>>>>> should tell the engine to stop, but neither should call the other
>>>>> after being called.  Seems like CsoundPerformanceThread.Join() should
>>>>> apply more to reaching the end of the score, but maybe I
>>>>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>>>>> stop, but after Stop() I don't see any effect.
>>>>> It occurred to me this could be avoided by using PerformKsmps, and
>>>>> only proceeding if the score is still active; if it's really necessary
>>>>> I'll recode it all, but I hope it's not.
>>>>>
>>>>> -Chuckk
>>>>>
>>>>> On Wed, Mar 11, 2009 at 12:44 AM, victor 
>>>>> wrote:
>>>>>>
>>>>>> I don't see a call to CsoundPerformanceThread.Join() in your code.
>>>>>> Maybe
>>>>>> that is the reason? So try adding one after calling 'Stop()'.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Victor
>>>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>>>> 
>>>>>> To: "Csound List" 
>>>>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>>>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>>>>
>>>>>>
>>>>>>> The scripts.
>>>>>>> The command:
>>>>>>> "python wtfrationale.py"
>>>>>>>
>>>>>>> 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"
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> http://www.badmuthahubbard.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"
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>>
>> --
>> http://www.badmuthahubbard.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"
>



-- 
http://www.badmuthahubbard.com

CVS csound and python2.5 from python.org
----- Original Message ----- 
From: "Chuckk Hubbard" 
To: 
Sent: Wednesday, March 11, 2009 2:48 PM
Subject: [Csnd] Re: Re: Re: Re: Re: Re: Re: Re: Python crashing in Windows 
on stopping Csound...


> That's a relief.  That's what it's supposed to be, just the simplest
> instrument I could throw together for a quick test.
> I suppose that means there's a problem with either my Python or my
> Csound installation.
> What versions were you using, by the way?  I'm using downloaded
> binaries of both, Python 2.5.4 and Csound 5.10, the "f" version.
>
> -Chuckk
>
> On Wed, Mar 11, 2009 at 4:40 PM, victor  wrote:
>> how is it suppose to sound? No crashes here running to the end of the
>> score or hitting the space bar, I am afraid. But I just get noise bursts.
>> This is Vista (or bust!)
>>
>> Victor
>> ----- Original Message ----- From: "Chuckk Hubbard"
>> 
>> To: 
>> Sent: Wednesday, March 11, 2009 1:53 PM
>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Python crashing in Windows on
>> stopping Csound...
>>
>>
>>> Hi again.
>>> Okay, here is a Tkinter version that should run with any recent Python
>>> with only csnd.py and the standard library.
>>> Click the window to open audio options, and press space to start/stop
>>> a 6-second score.  For me, in Windows, I get this error whether it
>>> runs to the end of the score or I hit space to stop it...
>>> Thanks!
>>> -Chuckk
>>>
>>> On Wed, Mar 11, 2009 at 1:29 AM, victor  
>>> wrote:
>>>>
>>>> I built the interface, but can't run your files because they need
>>>> tix and tix can only be built with msvc or borland (according to
>>>> their site) and I have only gcc/mingw.
>>>>
>>>> Victor
>>>> ----- Original Message ----- From: "victor" 
>>>> To: 
>>>> Sent: Tuesday, March 10, 2009 11:15 PM
>>>> Subject: [Csnd] Re: Re: Re: Re: Python crashing in Windows on stopping
>>>> Csound...
>>>>
>>>>
>>>>> Join() is placed after Stop() because the thread might take a while
>>>>> to finish, so you join it until it ends, avoiding any possible 
>>>>> problems.
>>>>>
>>>>> But if it doesn't fix it, the problem is elsewhere. I can't check it
>>>>> right
>>>>> now because I don't have the python interface built on this machine.
>>>>>
>>>>> Victor
>>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>>> 
>>>>> To: 
>>>>> Sent: Tuesday, March 10, 2009 11:10 PM
>>>>> Subject: [Csnd] Re: Re: Re: Python crashing in Windows on stopping
>>>>> Csound...
>>>>>
>>>>>
>>>>>> I hadn't considered that, but I can't tell any difference.
>>>>>> One problem I thought I had solved was that, if the score ends, the
>>>>>> engine should tell the GUI to stop, and if the user stops it, the GUI
>>>>>> should tell the engine to stop, but neither should call the other
>>>>>> after being called.  Seems like CsoundPerformanceThread.Join() should
>>>>>> apply more to reaching the end of the score, but maybe I
>>>>>> misunderstand.  If I place it before Stop(), obviously, it doesn't
>>>>>> stop, but after Stop() I don't see any effect.
>>>>>> It occurred to me this could be avoided by using PerformKsmps, and
>>>>>> only proceeding if the score is still active; if it's really 
>>>>>> necessary
>>>>>> I'll recode it all, but I hope it's not.
>>>>>>
>>>>>> -Chuckk
>>>>>>
>>>>>> On Wed, Mar 11, 2009 at 12:44 AM, victor 
>>>>>> wrote:
>>>>>>>
>>>>>>> I don't see a call to CsoundPerformanceThread.Join() in your code.
>>>>>>> Maybe
>>>>>>> that is the reason? So try adding one after calling 'Stop()'.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Victor
>>>>>>> ----- Original Message ----- From: "Chuckk Hubbard"
>>>>>>> 
>>>>>>> To: "Csound List" 
>>>>>>> Sent: Tuesday, March 10, 2009 9:59 PM
>>>>>>> Subject: [Csnd] Re: Python crashing in Windows on stopping Csound...
>>>>>>>
>>>>>>>
>>>>>>>> The scripts.
>>>>>>>> The command:
>>>>>>>> "python wtfrationale.py"
>>>>>>>>
>>>>>>>> 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"
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.badmuthahubbard.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"
>>>>
>>>>
>>>>
>>>> Send bugs reports to this list.
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>>>> "unsubscribe
>>>> csound"
>>>>
>>>
>>>
>>>
>>> --
>>> http://www.badmuthahubbard.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"
>>
>
>
>
> -- 
> http://www.badmuthahubbard.com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Hi,

Recent versions of QuteCsound require Csound 5.10 (5.2 is the API
version which was increased in 5.10).

Cheers,
Andrés

On Wed, Mar 11, 2009 at 4:28 AM, Olavo Peres  wrote:
> hi all,
> thanks for your ideas!
> I download QuteCsound for Windows (he don't find Csound64.dll.5.2, what
> shall I do?) and I'll try the version Linux too.
> it will be cool if you implement this object!
>  thanks!
> olavo
>
>> Date: Tue, 10 Mar 2009 19:43:23 -0500
>> From: mantaraya36@gmail.com
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: Re: visual envelopes
>>
>> I'm here =) Yes, let me know where in the sources it is and I'll have
>> a look. I've been thinking a lot about future directions for
>> QuteCsound, and this has actually come to mind.
>>
>> Cheers,
>> Andrés
>>
>> On Tue, Mar 10, 2009 at 7:00 PM, Rory Walsh  wrote:
>> > On a side note, i can give Andres the code I used in lettuce so maybe
>> > he can implement one in QuteCsound. If you're out there Andres let me
>> > know!
>> >
>> > 2009/3/10 Rory Walsh :
>> >> There is one in Lettuce, there is also another one I came across while
>> >> building the one in lettuce but I can't think of it's name right now.
>> >> Perhaps someone else can advise?
>> >>
>> >> 2009/3/10 Olavo Peres :
>> >>> Hi,
>> >>>
>> >>> I'm searching a visual object (FLTK) for Csound to produce envelopes,
>> >>> like
>> >>> an 'envgen' of PureData,
>> >>> Does somebody know one?
>> >>>
>> >>>  thanks,
>> >>> olavo
>> >>>
>> >>>
>> >>> ________________________________
>> >>> Diversão em dobro: compartilhe fotos enquanto conversa usando o
>> >>> Windows Live
>> >>> Messenger.
>> >>
>> >
>> >
>> > Send bugs reports to this list.
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
> ________________________________
> Notícias direto do New York Times, gols do Lance, videocassetadas e muitos
> outros vídeos no MSN Videos! Confira já!



-- 


Andrés

Balls. I have to have a look at the source code! If I can't find the
source I'll send you the files I think you might need.

Rory.


2009/3/11 Olavo Peres :
> thanks everybody,
>
> Stef, I'll try Surmulot, it looks good!
> Rory, I've downloaded your breakpoint.exe but it doesn't find 'vcl60.bpl',
> have you got that?
>
> cheers,
> Olavo
>
>> Date: Wed, 11 Mar 2009 15:58:31 +0200
>> From: badmuthahubbard@gmail.com
>> To: csound@lists.bath.ac.uk
>> Subject: [Csnd] Re: Re: visual envelopes
>>
>> Awesome. It doesn't look like overkill, but the website is daunting
>> so far! I must try it.
>> -Chuckk
>>
>> On Wed, Mar 11, 2009 at 2:24 PM, Stéphane Rollandin
>>  wrote:
>> > very probably overkill, and with a definite learning curve, but if you
>> > try
>> > Surmulot you will have a very powerful envelope editor. see attached
>> > pictures: an envelope can be drawn with a variety of interpolation
>> > between
>> > breakpoints; it can then be broken as a linseg with arbitrary precision.
>> >
>> >
>> > Surmulot:
>> > http://www.zogotounga.net/surmulot/surmulot.html
>> >
>> > regards,
>> >
>> > Stef
>> >
>> > Send bugs reports to this list.
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>>
>>
>>
>> --
>> http://www.badmuthahubbard.com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
> ________________________________
> Conheça já o Windows Live Spaces, o site de relacionamentos do Messenger!
> Crie já o seu!

Hello,

I've been wishing for long time for an FLTK envelope graphic editor to
be added to Csound. One that can be used in realtime to directly
modify the contents of a table and not to generate text strings with
the values. Would something like this be possible?

Cheers,

Hector


On Wed, Mar 11, 2009 at 8:24 AM, Stéphane Rollandin
 wrote:
> very probably overkill, and with a definite learning curve, but if you try
> Surmulot you will have a very powerful envelope editor. see attached
> pictures: an envelope can be drawn with a variety of interpolation between
> breakpoints; it can then be broken as a linseg with arbitrary precision.
>
>
> Surmulot:
> http://www.zogotounga.net/surmulot/surmulot.html
>
> regards,
>
> Stef
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

It is possible to edit function tables graphically in Surmolot. It
also is possible to edit Csound orchestras graphically as opcode
blocks connected with wires. This all appears to be cross-platform.
There is much to like in Surmolot - it incorporates what used to be
GeoMaestro and other stuff too.

What I do not like about it is that it is a melange of several
languages glued together with elisp and sockets. The block diagrams,
for example, are stored in csd files as encoded binary Squeak
SmallTalk images. Over time, I wonder if pieces done in Surmolot might
become difficult to maintain. If this does not bother you, I would
rank Surmolot up there with blue, Grace with sndlib, and
Csound/CsoundAC/Python as powerful open source environments for
combined algorithmic composition and software synthesis.

Regards,
Mike

On Thu, Mar 12, 2009 at 10:12 AM, Hector Centeno  wrote:
> Hello,
>
> I've been wishing for long time for an FLTK envelope graphic editor to
> be added to Csound. One that can be used in realtime to directly
> modify the contents of a table and not to generate text strings with
> the values. Would something like this be possible?
>
> Cheers,
>
> Hector
>
>
> On Wed, Mar 11, 2009 at 8:24 AM, Stéphane Rollandin
>  wrote:
>> very probably overkill, and with a definite learning curve, but if you try
>> Surmulot you will have a very powerful envelope editor. see attached
>> pictures: an envelope can be drawn with a variety of interpolation between
>> breakpoints; it can then be broken as a linseg with arbitrary precision.
>>
>>
>> Surmulot:
>> http://www.zogotounga.net/surmulot/surmulot.html
>>
>> regards,
>>
>> Stef
>>
>> 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"



-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

Michael Gogins a écrit :
> What I do not like about it is that it is a melange of several
> languages glued together with elisp and sockets. 

yes, I understand it may look ugly and bloated. there are other examples 
of such architecture though. see SAGE for example:
http://www.sagemath.org/

the main motivation here is: let's not reinvent the wheel, just have 
existing software talk together


The block diagrams,
> for example, are stored in csd files as encoded binary Squeak
> SmallTalk images. Over time, I wonder if pieces done in Surmolot might
> become difficult to maintain. 

in my view it is quite the opposite: all functionality is eventually a 
script of some sort (be it smalltalk or elisp code), always human 
readable, and all code is open and available within the distro.

also note that the distro (at least the windows distro) also includes 
the underlying programming environment themselves. even 50 years from 
now, you will just have to emulate some old winXP system of dubious fame 
in any virtual environment to have your old Surmulot system spring to 
life immediately (I guess it will be possible to get winXP from internet 
museums in 2059 :)

so I think a composer has no much risk of loosing its work with 
surmulot. the actual problem I see (and I have no answer to it yet) is 
how, in the general case, transfer a full composition from one release 
of surmulot to the next one. that is, backward compatibility.

this is where your example is right to the point: the CSD section 
describing an orchestra block diagram is not guaranteed to be read back 
in a future version of surmulot.

at the moment, I would recommend to either keep a composition into the 
version you started it in (since any number of surmulot installations 
can happily live side by side), and/or migrate the critical components 
of your composition from one version to the next using formats such as 
MIDI file, CSD files and text dumps. unfortunately block diagrams do not 
provide such a format at the moment.

I'm very interested into this topic, as I see it as one of the most 
difficult to deal with: how can a software based musical composition 
structure and components be durably described and maintained ?


regards,

Stef

Hector Centeno a écrit :
> I've been wishing for long time for an FLTK envelope graphic editor to
> be added to Csound. One that can be used in realtime to directly
> modify the contents of a table and not to generate text strings with
> the values. Would something like this be possible?

I'm working on this kind of realtime interaction in Surmulot. it is very 
rudimentary at the moment. the idea is to drive the orchestra via OSC 
messages which follow the envelope(s). I would be glad to know of any 
better way of passing a full envelope to csound in real time.

Stef

Csound~ also enables realtime table editing, where you can access each
index in realtime (read and write).

Best
Peiman


2009/3/12 Stéphane Rollandin :
> Hector Centeno a écrit :
>>
>> I've been wishing for long time for an FLTK envelope graphic editor to
>> be added to Csound. One that can be used in realtime to directly
>> modify the contents of a table and not to generate text strings with
>> the values. Would something like this be possible?
>
> I'm working on this kind of realtime interaction in Surmulot. it is very
> rudimentary at the moment. the idea is to drive the orchestra via OSC
> messages which follow the envelope(s). I would be glad to know of any better
> way of passing a full envelope to csound in real time.
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

First, Stephane, thanks for your quick response to my comments. I'm
glad to see you taking this issue of compatibility seriously.

In my view, this is one of the most serious faults of computer music
in general - both in the academic or open source worlds, and in the
commercial or project studio environment using proprietary software.
For us, software is our form of music notation, indeed it is the most
powerful of all forms of notation; but if backwards compatibility
breaks, that is the same as forgetting how to read music. This is, I
think, one of the main, if not THE main, reasons that computer music
has not become a more important part of music in general. Without a
common basis of musical literacy and historical continuity, there can
be no large community and there can be no deep musical tradition.

Assuming this for the sake of argument, what to do about it?

I have been doing computer music since 1984 and working as a
professional programmer since 1989. I have observed that the most
stable pieces of software are the tools themselves: the programming
languages. Therefore, if one's work exists exclusively in the form of
source code in some programming language, it is going to last longer
before breaking (it will of course break eventually). On top of that,
the more widely used and standardized the programming language, the
better. It is, I think, another fault of computer music in relying on
languages that are not widely used. For this reason, I favor C, C++,
and Python as languages of choice for writing music. Lisp has of
course also been around for a long time, but frankly it has a small
user base and does not have a standardized package system or a
standard set of system libraries. There are newer languages that have
the potential for long-term musical use: Lua, Scala, and Ruby.

Of course, for sound synthesis, dynamic languages are not efficient
enough for real-time performance, and therefore customized languages
and synthesis systems must be developed, such as Csound or Max/MSP. Of
all these, Csound has lasted the longest and as a consequence, has
developed the deepest "tradition."

Emacs has of course been around for a long time and will probably last
well into the future, but the number of people who are comfortable as
elisp developers is, I think, fairly small. I'm afraid I think the
same is true of Smalltalk, which is a really excellent language and
very well suited for music in many ways.

At any rate, to wind down my digressions and get back to the point, is
there any way you can store your Smalltalk stuff in CSDs as source
code without slowing things down?

Also, is there some kind of elisp foreign function interface so that
elisp code can call Smalltalk libraries directly?

For that matter, does elisp support Lisp CFFI? If so, elisp can call
into the Csound API directly.

Anyway, thanks for your comments, and thanks for Surmolot, which I
will continue to investigate.

Regards,
Mike

On Thu, Mar 12, 2009 at 12:18 PM, Stéphane Rollandin
 wrote:
> Hector Centeno a écrit :
>>
>> I've been wishing for long time for an FLTK envelope graphic editor to
>> be added to Csound. One that can be used in realtime to directly
>> modify the contents of a table and not to generate text strings with
>> the values. Would something like this be possible?
>
> I'm working on this kind of realtime interaction in Surmulot. it is very
> rudimentary at the moment. the idea is to drive the orchestra via OSC
> messages which follow the envelope(s). I would be glad to know of any better
> way of passing a full envelope to csound in real time.
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

I forgot my second point. If you can call the Csound API directly,
then you can create and/or modify function tables in a running
orchestra using the API, just as csound~ does.

Regards,
Mike

On Thu, Mar 12, 2009 at 1:46 PM, Michael Gogins
 wrote:
> First, Stephane, thanks for your quick response to my comments. I'm
> glad to see you taking this issue of compatibility seriously.
>
> In my view, this is one of the most serious faults of computer music
> in general - both in the academic or open source worlds, and in the
> commercial or project studio environment using proprietary software.
> For us, software is our form of music notation, indeed it is the most
> powerful of all forms of notation; but if backwards compatibility
> breaks, that is the same as forgetting how to read music. This is, I
> think, one of the main, if not THE main, reasons that computer music
> has not become a more important part of music in general. Without a
> common basis of musical literacy and historical continuity, there can
> be no large community and there can be no deep musical tradition.
>
> Assuming this for the sake of argument, what to do about it?
>
> I have been doing computer music since 1984 and working as a
> professional programmer since 1989. I have observed that the most
> stable pieces of software are the tools themselves: the programming
> languages. Therefore, if one's work exists exclusively in the form of
> source code in some programming language, it is going to last longer
> before breaking (it will of course break eventually). On top of that,
> the more widely used and standardized the programming language, the
> better. It is, I think, another fault of computer music in relying on
> languages that are not widely used. For this reason, I favor C, C++,
> and Python as languages of choice for writing music. Lisp has of
> course also been around for a long time, but frankly it has a small
> user base and does not have a standardized package system or a
> standard set of system libraries. There are newer languages that have
> the potential for long-term musical use: Lua, Scala, and Ruby.
>
> Of course, for sound synthesis, dynamic languages are not efficient
> enough for real-time performance, and therefore customized languages
> and synthesis systems must be developed, such as Csound or Max/MSP. Of
> all these, Csound has lasted the longest and as a consequence, has
> developed the deepest "tradition."
>
> Emacs has of course been around for a long time and will probably last
> well into the future, but the number of people who are comfortable as
> elisp developers is, I think, fairly small. I'm afraid I think the
> same is true of Smalltalk, which is a really excellent language and
> very well suited for music in many ways.
>
> At any rate, to wind down my digressions and get back to the point, is
> there any way you can store your Smalltalk stuff in CSDs as source
> code without slowing things down?
>
> Also, is there some kind of elisp foreign function interface so that
> elisp code can call Smalltalk libraries directly?
>
> For that matter, does elisp support Lisp CFFI? If so, elisp can call
> into the Csound API directly.
>
> Anyway, thanks for your comments, and thanks for Surmolot, which I
> will continue to investigate.
>
> Regards,
> Mike
>
> On Thu, Mar 12, 2009 at 12:18 PM, Stéphane Rollandin
>  wrote:
>> Hector Centeno a écrit :
>>>
>>> I've been wishing for long time for an FLTK envelope graphic editor to
>>> be added to Csound. One that can be used in realtime to directly
>>> modify the contents of a table and not to generate text strings with
>>> the values. Would something like this be possible?
>>
>> I'm working on this kind of realtime interaction in Surmulot. it is very
>> rudimentary at the moment. the idea is to drive the orchestra via OSC
>> messages which follow the envelope(s). I would be glad to know of any better
>> way of passing a full envelope to csound in real time.
>>
>> Stef
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> Michael dot Gogins at gmail dot com
>



-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

Michael Gogins a écrit :
> I forgot my second point. If you can call the Csound API directly,
> then you can create and/or modify function tables in a running
> orchestra using the API, just as csound~ does.

could you provide an (rough) example using the Python bindings to the 
API ? Python programming could very easily be integrated with Surmulot, 
only I have no experience in this domain.

regards,

Stef

I encourage you to add Python. First there is CsoundAC whose
capabilities for algorithmic composition would become available to
Surmolot, and then there is Christopher Ariza's athenaCL Python system
for algorithmic composition.

I will try to email you a working example of such table manipulation
in a day or so.

Regards,
Mike

On Thu, Mar 12, 2009 at 2:20 PM, Stéphane Rollandin
 wrote:
> Michael Gogins a écrit :
>>
>> I forgot my second point. If you can call the Csound API directly,
>> then you can create and/or modify function tables in a running
>> orchestra using the API, just as csound~ does.
>
> could you provide an (rough) example using the Python bindings to the API ?
> Python programming could very easily be integrated with Surmulot, only I
> have no experience in this domain.
>
> regards,
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

> For us, software is our form of music notation, indeed it is the most
> powerful of all forms of notation; but if backwards compatibility
> breaks, that is the same as forgetting how to read music.

that's very true.

what I do about this is keep different forms of a piece of music, from 
the programming environment itself (big, hard to maintain) to the 
eventual FLAC files, with intermediary steps whenever possible (midi 
files, the soundfonts that were used, etc.)


> It is, I think, another fault of computer music in relying on
> languages that are not widely used. For this reason, I favor C, C++,
> and Python as languages of choice for writing music. Lisp has of
> course also been around for a long time, but frankly it has a small
> user base and does not have a standardized package system or a
> standard set of system libraries. There are newer languages that have
> the potential for long-term musical use: Lua, Scala, and Ruby.

to me, about any langage will do if the aim is to keep an archival 
version of the work. thanks to virtualization, no (decent) langage can 
rely die in the internet era. at times I am playing with the same Atari 
ST games I used to 25 years ago, only now the Atari ST itself is a program !

it is really a personal matter of what kind of data do we want to keep 
around so that we "stay in touch" with what we have done in the past.

very personally, I mostly care about two extrema: either the composition 
mechanism or algorithm (in which case I want to keep a program working, 
but the platform can change: see GeoMaestro/Keykit to 
Surmulot/Emacs/squeak) or the music file itself (for example the 
compositions in http://www.zogotounga.net/TGG/iii_ogg.htm were made with 
custom Reaktor instruments which I deliberately erased right after 
having played them once, so I could not even explain how they were made).


> Of course, for sound synthesis, dynamic languages are not efficient
> enough for real-time performance, and therefore customized languages
> and synthesis systems must be developed, such as Csound or Max/MSP. Of
> all these, Csound has lasted the longest and as a consequence, has
> developed the deepest "tradition."

yes, but how sure are we that Csound will keep being backward compatible ?


> Emacs has of course been around for a long time and will probably last
> well into the future, but the number of people who are comfortable as
> elisp developers is, I think, fairly small. I'm afraid I think the
> same is true of Smalltalk, which is a really excellent language and
> very well suited for music in many ways.

right, but as a composer I am only concerned about the sustainability of 
my tools; it does not matter to me how popular those tools are.


> At any rate, to wind down my digressions and get back to the point, is
> there any way you can store your Smalltalk stuff in CSDs as source
> code without slowing things down?

well the Smalltalk stuff you are talking about is actually Smalltalk 
source code, only base64 encoded. the problem is not in the textual 
representation, it is in the mutability of the implementation on the 
Squeak side. to say it differently, Surmulot simply serializes an 
Smalltalk object into the CSD; so as long as the object structure do not 
change then the CSD can be read properly.


> Also, is there some kind of elisp foreign function interface so that
> elisp code can call Smalltalk libraries directly?

no, because Squeak Smalltalk is just a big image, so invoking any part 
of it (a "library") involves starting the whole thing anyway. so in 
Surmulot Emacs communicates directly with Squeak via local TCP/IP and I 
believe it amounts to the same thing.


> For that matter, does elisp support Lisp CFFI? If so, elisp can call
> into the Csound API directly.

Squeak has a FFI support, but I am not familiar with it. Emacs has none 
AFAIK. I think Python would be a good candidate for a layer between 
Emacs and the Csound API, and if I can get a few hints about the way to 
do it I am willing to implement Csound API access in Surmulot.

regards,


Stef

Thanks again for your response.

About languages with more users, I favor them not because I like them
personally, but because if they are more widely known, it is like
having a few systems of music notation instead of many systems. It
fosters musical community and tradition.

I hope you are right about virtual machines and emulators!

Yes, it is a deliberate and rigorous commitment of the Csound
developers to always maintain backward compatibility. This is one of
the strengths of Csound.

In the Csound examples/directory there are Python and Java examples of
how to use the Csound API.

Regards,
Mike

On Thu, Mar 12, 2009 at 2:58 PM, Stéphane Rollandin
 wrote:
>
>> For us, software is our form of music notation, indeed it is the most
>> powerful of all forms of notation; but if backwards compatibility
>> breaks, that is the same as forgetting how to read music.
>
> that's very true.
>
> what I do about this is keep different forms of a piece of music, from the
> programming environment itself (big, hard to maintain) to the eventual FLAC
> files, with intermediary steps whenever possible (midi files, the soundfonts
> that were used, etc.)
>
>
>> It is, I think, another fault of computer music in relying on
>> languages that are not widely used. For this reason, I favor C, C++,
>> and Python as languages of choice for writing music. Lisp has of
>> course also been around for a long time, but frankly it has a small
>> user base and does not have a standardized package system or a
>> standard set of system libraries. There are newer languages that have
>> the potential for long-term musical use: Lua, Scala, and Ruby.
>
> to me, about any langage will do if the aim is to keep an archival version
> of the work. thanks to virtualization, no (decent) langage can rely die in
> the internet era. at times I am playing with the same Atari ST games I used
> to 25 years ago, only now the Atari ST itself is a program !
>
> it is really a personal matter of what kind of data do we want to keep
> around so that we "stay in touch" with what we have done in the past.
>
> very personally, I mostly care about two extrema: either the composition
> mechanism or algorithm (in which case I want to keep a program working, but
> the platform can change: see GeoMaestro/Keykit to Surmulot/Emacs/squeak) or
> the music file itself (for example the compositions in
> http://www.zogotounga.net/TGG/iii_ogg.htm were made with custom Reaktor
> instruments which I deliberately erased right after having played them once,
> so I could not even explain how they were made).
>
>
>> Of course, for sound synthesis, dynamic languages are not efficient
>> enough for real-time performance, and therefore customized languages
>> and synthesis systems must be developed, such as Csound or Max/MSP. Of
>> all these, Csound has lasted the longest and as a consequence, has
>> developed the deepest "tradition."
>
> yes, but how sure are we that Csound will keep being backward compatible ?
>
>
>> Emacs has of course been around for a long time and will probably last
>> well into the future, but the number of people who are comfortable as
>> elisp developers is, I think, fairly small. I'm afraid I think the
>> same is true of Smalltalk, which is a really excellent language and
>> very well suited for music in many ways.
>
> right, but as a composer I am only concerned about the sustainability of my
> tools; it does not matter to me how popular those tools are.
>
>
>> At any rate, to wind down my digressions and get back to the point, is
>> there any way you can store your Smalltalk stuff in CSDs as source
>> code without slowing things down?
>
> well the Smalltalk stuff you are talking about is actually Smalltalk source
> code, only base64 encoded. the problem is not in the textual representation,
> it is in the mutability of the implementation on the Squeak side. to say it
> differently, Surmulot simply serializes an Smalltalk object into the CSD; so
> as long as the object structure do not change then the CSD can be read
> properly.
>
>
>> Also, is there some kind of elisp foreign function interface so that
>> elisp code can call Smalltalk libraries directly?
>
> no, because Squeak Smalltalk is just a big image, so invoking any part of it
> (a "library") involves starting the whole thing anyway. so in Surmulot Emacs
> communicates directly with Squeak via local TCP/IP and I believe it amounts
> to the same thing.
>
>
>> For that matter, does elisp support Lisp CFFI? If so, elisp can call
>> into the Csound API directly.
>
> Squeak has a FFI support, but I am not familiar with it. Emacs has none
> AFAIK. I think Python would be a good candidate for a layer between Emacs
> and the Csound API, and if I can get a few hints about the way to do it I am
> willing to implement Csound API access in Surmulot.
>
> regards,
>
>
> Stef
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>



-- 
Michael Gogins
Irreducible Productions
Michael dot Gogins at gmail dot com

Michael Gogins a écrit :
> I forgot my second point. If you can call the Csound API directly,
> then you can create and/or modify function tables in a running
> orchestra using the API, just as csound~ does.

ok I tried to understand how this works, and the first thing I had 
problem with is just

from csnd import *

I couldn't get this to work from Python 2.6.1, only from Python 2.5
I guess this comes from _csnd.pyd, so my first question is: how can I 
get a _csnd.pyd which is not dependent of a specific Python version 
(leaving aside Python 3.0 which is not backward compatible AFAIK) ?


Stef