Csound may be BUILT for any (single) version of Python.

Csound packages are, therefore, built for a specific version of Python.

The current Windows installer is built for Python 2.6.

With the API, you can use any GUI toolkit you like. I have written Csound 
interactive pieces using FLTK, Python's build-in Tkinter, FLTK, and 
wxPython. All methods, believe it or not, are about equally difficult to 
program. But perhaps this is not so surprising, since they all have to do 
the same job of connecting GUI widgets to Csound control variables. So I 
advise you to be guided first by your preference for a GUI toolkit. All the 
toolkits I played with had about the same latency and level of dropouts.

I use Eebuntu on an Acer Aspire One myself in addition to Windows XP on a 
much more powerful machine, and I use both built-in sound and outboard USB 
devices. I find that the choice of audio infrastructure (alsa, oss, 
PulseAudio, etc.) has a big impact on dropouts.

I too have more problems with dropouts on Eebuntu. I have not devoted much 
time to investigating them because real-time performance is a very small 
part of what I do in music, but I may take a harder look at it.

On general principles, I would advise you to:

0. Check the manual on the external interface. Mine has several settings 
that affect performance.

1. Investigate the audio setup on the computer, and use the most performant 
interface, turning all other stuff off. I find alsa "hw" interfaces work 
best, your mileage may vary.

2. Experiment with device names, -b, -K, and ksmps to find an optimum 
balance. This is time-consuming but can really help, on all platforms.

3. Turn other stuff that you don't want interfering off on the computer. 
This is common advice from computer music people on all platforms, including 
especially Windows, but I expect it could work on Eebuntu as well. Maybe 
experiment with different window managers, or a console-only interface to 
Linux that runs only 1 main window?

4. I find that the CsoundPerformanceThread facility is very helpful in 
reducing dropouts.

I do not know what you are saying about lack of examples for GUI interfaces. 
There are half a dozen at least in the Csound examples directory.

Hope this helps,
Mike

----- Original Message ----- 
From: "Aaron Krister Johnson" 
To: 
Sent: Wednesday, November 11, 2009 8:58 PM
Subject: [Csnd] Re: RE: question regarding GUI xruns


>
> Hi Victor, everyone,
>
> Thanks for you fast responses!
>
> As for he API, I figured I would want to get around to working with it at
> some point. My issue, however, is that it seems there is a lack of
> examples/documentation/tutorials out there about how one goes about this.
>
> Also, is there still an issue with the csd.py library only being good for 
> an
> older (I think 2.5) version of Python? Or, have the issues with scons and
> swig been resolved?
>
> Hmmm...it seems to me that FLTK, if it can't do threading correctly, at
> least on *all* platforms, might be superceded by a better default toolkit 
> in
> future versions? :) Just a thought anyway.....
>
> Regarding Ubuntu vs. 64studio, I can't comment, b/c I don't use a 64bit
> platform. I do know that I've done everything possible short of 
> sacrificial
> offerings to the gods of low-latency to tune my eeebuntu system.....I even
> used an outboard USB sound interface (a Lexicon Lambda) to test if the IRQ
> sharing between the video and audio cards was the issue (turns out it
> wasn't, and Csound still gave me crackles on moves and resizes of windows)
>
> Otherwise, solid and beautiful performance from other apps like 
> ZynAddSubFx,
> etc.....
>
> Best,
> AKJ
>
>
> Victor Lazzarini wrote:
>>
>> The problem with the 'fix' is that it is a hack and as hacks go, it
>> does not work everywhere.
>> I studied the code a while ago, it uses an unsupported and unadvisable
>> way of starting a separate thread for GUIs. According to the FLTK
>> developers, it was pure chance it worked (on Windows). It never worked
>> on OSX and there were problems on Linux. For this reason, the FLTK
>> implementation was made single-threaded, and that might have
>> performance issues.
>>
>> As Rory said here, if you can program in Python, it's better to build
>> up your GUI using the API and something like WxWindows, GTK, Qt or
>> even Tkinter.
>>
> -- 
> View this message in context: 
> http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26312162.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"

Hi,

This is a very helpful list...regarding 'lack of examples' I was referring
to usage of the API...but maybe that's what you are saying...I assume by
examples directory you mean the source code tarball? I'll have a look later,
I don't remember what I may have noticed in the past. Can you say more about
'CsoundPerformanceThread'?

I was thinking earlier.....why not use a small TKinter app, bind some OSC
messages to widgets, and send OSC messages to a non-GUI Csound instance? I
wonder, since non-GUI Csound engines don't have these issues, if that might
be the *fastest/easiest* route to GUI interaction with other toolkits?

AKJ



Michael Gogins-2 wrote:
> 
> Csound may be BUILT for any (single) version of Python.
> 
> Csound packages are, therefore, built for a specific version of Python.
> 
> The current Windows installer is built for Python 2.6.
> 
> With the API, you can use any GUI toolkit you like. I have written Csound 
> interactive pieces using FLTK, Python's build-in Tkinter, FLTK, and 
> wxPython. All methods, believe it or not, are about equally difficult to 
> program. But perhaps this is not so surprising, since they all have to do 
> the same job of connecting GUI widgets to Csound control variables. So I 
> advise you to be guided first by your preference for a GUI toolkit. All
> the 
> toolkits I played with had about the same latency and level of dropouts.
> 
> I use Eebuntu on an Acer Aspire One myself in addition to Windows XP on a 
> much more powerful machine, and I use both built-in sound and outboard USB 
> devices. I find that the choice of audio infrastructure (alsa, oss, 
> PulseAudio, etc.) has a big impact on dropouts.
> 
> I too have more problems with dropouts on Eebuntu. I have not devoted much 
> time to investigating them because real-time performance is a very small 
> part of what I do in music, but I may take a harder look at it.
> 
> On general principles, I would advise you to:
> 
> 0. Check the manual on the external interface. Mine has several settings 
> that affect performance.
> 
> 1. Investigate the audio setup on the computer, and use the most
> performant 
> interface, turning all other stuff off. I find alsa "hw" interfaces work 
> best, your mileage may vary.
> 
> 2. Experiment with device names, -b, -K, and ksmps to find an optimum 
> balance. This is time-consuming but can really help, on all platforms.
> 
> 3. Turn other stuff that you don't want interfering off on the computer. 
> This is common advice from computer music people on all platforms,
> including 
> especially Windows, but I expect it could work on Eebuntu as well. Maybe 
> experiment with different window managers, or a console-only interface to 
> Linux that runs only 1 main window?
> 
> 4. I find that the CsoundPerformanceThread facility is very helpful in 
> reducing dropouts.
> 
> I do not know what you are saying about lack of examples for GUI
> interfaces. 
> There are half a dozen at least in the Csound examples directory.
> 
> Hope this helps,
> Mike
> 
> ----- Original Message ----- 
> From: "Aaron Krister Johnson" 
> To: 
> Sent: Wednesday, November 11, 2009 8:58 PM
> Subject: [Csnd] Re: RE: question regarding GUI xruns
> 
> 
>>
>> Hi Victor, everyone,
>>
>> Thanks for you fast responses!
>>
>> As for he API, I figured I would want to get around to working with it at
>> some point. My issue, however, is that it seems there is a lack of
>> examples/documentation/tutorials out there about how one goes about this.
>>
>> Also, is there still an issue with the csd.py library only being good for 
>> an
>> older (I think 2.5) version of Python? Or, have the issues with scons and
>> swig been resolved?
>>
>> Hmmm...it seems to me that FLTK, if it can't do threading correctly, at
>> least on *all* platforms, might be superceded by a better default toolkit 
>> in
>> future versions? :) Just a thought anyway.....
>>
>> Regarding Ubuntu vs. 64studio, I can't comment, b/c I don't use a 64bit
>> platform. I do know that I've done everything possible short of 
>> sacrificial
>> offerings to the gods of low-latency to tune my eeebuntu system.....I
>> even
>> used an outboard USB sound interface (a Lexicon Lambda) to test if the
>> IRQ
>> sharing between the video and audio cards was the issue (turns out it
>> wasn't, and Csound still gave me crackles on moves and resizes of
>> windows)
>>
>> Otherwise, solid and beautiful performance from other apps like 
>> ZynAddSubFx,
>> etc.....
>>
>> Best,
>> AKJ
>>
>>
>> Victor Lazzarini wrote:
>>>
>>> The problem with the 'fix' is that it is a hack and as hacks go, it
>>> does not work everywhere.
>>> I studied the code a while ago, it uses an unsupported and unadvisable
>>> way of starting a separate thread for GUIs. According to the FLTK
>>> developers, it was pure chance it worked (on Windows). It never worked
>>> on OSX and there were problems on Linux. For this reason, the FLTK
>>> implementation was made single-threaded, and that might have
>>> performance issues.
>>>
>>> As Rory said here, if you can program in Python, it's better to build
>>> up your GUI using the API and something like WxWindows, GTK, Qt or
>>> even Tkinter.
>>>
>> -- 
>> View this message in context: 
>> http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26312162.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"
> 
> 

Hi,

I think QuteCsound offers a nice alternative to FLTK widgets. If you
run Csound in a separate thread from the QuteCsound GUI, you should
get very good performance (if anyone doesn't I'd like to know).

There is a new CsoundPerformanceThread example in the csound sources
in interfaces/csPerfThread.hpp which can be the base for a program in
C++ that uses Csound in a separate thread.

Cheers,
Andrés

On Thu, Nov 12, 2009 at 4:30 AM, Aaron Krister Johnson
 wrote:
>
>
> Hi,
>
> This is a very helpful list...regarding 'lack of examples' I was referring
> to usage of the API...but maybe that's what you are saying...I assume by
> examples directory you mean the source code tarball? I'll have a look later,
> I don't remember what I may have noticed in the past. Can you say more about
> 'CsoundPerformanceThread'?
>
> I was thinking earlier.....why not use a small TKinter app, bind some OSC
> messages to widgets, and send OSC messages to a non-GUI Csound instance? I
> wonder, since non-GUI Csound engines don't have these issues, if that might
> be the *fastest/easiest* route to GUI interaction with other toolkits?
>
> AKJ
>
>
>
> Michael Gogins-2 wrote:
>>
>> Csound may be BUILT for any (single) version of Python.
>>
>> Csound packages are, therefore, built for a specific version of Python.
>>
>> The current Windows installer is built for Python 2.6.
>>
>> With the API, you can use any GUI toolkit you like. I have written Csound
>> interactive pieces using FLTK, Python's build-in Tkinter, FLTK, and
>> wxPython. All methods, believe it or not, are about equally difficult to
>> program. But perhaps this is not so surprising, since they all have to do
>> the same job of connecting GUI widgets to Csound control variables. So I
>> advise you to be guided first by your preference for a GUI toolkit. All
>> the
>> toolkits I played with had about the same latency and level of dropouts.
>>
>> I use Eebuntu on an Acer Aspire One myself in addition to Windows XP on a
>> much more powerful machine, and I use both built-in sound and outboard USB
>> devices. I find that the choice of audio infrastructure (alsa, oss,
>> PulseAudio, etc.) has a big impact on dropouts.
>>
>> I too have more problems with dropouts on Eebuntu. I have not devoted much
>> time to investigating them because real-time performance is a very small
>> part of what I do in music, but I may take a harder look at it.
>>
>> On general principles, I would advise you to:
>>
>> 0. Check the manual on the external interface. Mine has several settings
>> that affect performance.
>>
>> 1. Investigate the audio setup on the computer, and use the most
>> performant
>> interface, turning all other stuff off. I find alsa "hw" interfaces work
>> best, your mileage may vary.
>>
>> 2. Experiment with device names, -b, -K, and ksmps to find an optimum
>> balance. This is time-consuming but can really help, on all platforms.
>>
>> 3. Turn other stuff that you don't want interfering off on the computer.
>> This is common advice from computer music people on all platforms,
>> including
>> especially Windows, but I expect it could work on Eebuntu as well. Maybe
>> experiment with different window managers, or a console-only interface to
>> Linux that runs only 1 main window?
>>
>> 4. I find that the CsoundPerformanceThread facility is very helpful in
>> reducing dropouts.
>>
>> I do not know what you are saying about lack of examples for GUI
>> interfaces.
>> There are half a dozen at least in the Csound examples directory.
>>
>> Hope this helps,
>> Mike
>>
>> ----- Original Message -----
>> From: "Aaron Krister Johnson" 
>> To: 
>> Sent: Wednesday, November 11, 2009 8:58 PM
>> Subject: [Csnd] Re: RE: question regarding GUI xruns
>>
>>
>>>
>>> Hi Victor, everyone,
>>>
>>> Thanks for you fast responses!
>>>
>>> As for he API, I figured I would want to get around to working with it at
>>> some point. My issue, however, is that it seems there is a lack of
>>> examples/documentation/tutorials out there about how one goes about this.
>>>
>>> Also, is there still an issue with the csd.py library only being good for
>>> an
>>> older (I think 2.5) version of Python? Or, have the issues with scons and
>>> swig been resolved?
>>>
>>> Hmmm...it seems to me that FLTK, if it can't do threading correctly, at
>>> least on *all* platforms, might be superceded by a better default toolkit
>>> in
>>> future versions? :) Just a thought anyway.....
>>>
>>> Regarding Ubuntu vs. 64studio, I can't comment, b/c I don't use a 64bit
>>> platform. I do know that I've done everything possible short of
>>> sacrificial
>>> offerings to the gods of low-latency to tune my eeebuntu system.....I
>>> even
>>> used an outboard USB sound interface (a Lexicon Lambda) to test if the
>>> IRQ
>>> sharing between the video and audio cards was the issue (turns out it
>>> wasn't, and Csound still gave me crackles on moves and resizes of
>>> windows)
>>>
>>> Otherwise, solid and beautiful performance from other apps like
>>> ZynAddSubFx,
>>> etc.....
>>>
>>> Best,
>>> AKJ
>>>
>>>
>>> Victor Lazzarini wrote:
>>>>
>>>> The problem with the 'fix' is that it is a hack and as hacks go, it
>>>> does not work everywhere.
>>>> I studied the code a while ago, it uses an unsupported and unadvisable
>>>> way of starting a separate thread for GUIs. According to the FLTK
>>>> developers, it was pure chance it worked (on Windows). It never worked
>>>> on OSX and there were problems on Linux. For this reason, the FLTK
>>>> implementation was made single-threaded, and that might have
>>>> performance issues.
>>>>
>>>> As Rory said here, if you can program in Python, it's better to build
>>>> up your GUI using the API and something like WxWindows, GTK, Qt or
>>>> even Tkinter.
>>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26312162.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/question-regarding-GUI-xruns-tp26309243p26313285.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"
>



-- 


Andrés


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

Cvs has every thing, tarballs or installers may not.

Osc would be like thread plus network plus extra buffers. Just use threads.

Mkg

On Nov 11, 2009 11:31 PM, "Aaron Krister Johnson" <aaron@akjmusic.com> wrote:



Hi,

This is a very helpful list...regarding 'lack of examples' I was referring
to usage of the API...but maybe that's what you are saying...I assume by
examples directory you mean the source code tarball? I'll have a look later,
I don't remember what I may have noticed in the past. Can you say more about
'CsoundPerformanceThread'?

I was thinking earlier.....why not use a small TKinter app, bind some OSC
messages to widgets, and send OSC messages to a non-GUI Csound instance? I
wonder, since non-GUI Csound engines don't have these issues, if that might
be the *fastest/easiest* route to GUI interaction with other toolkits?

AKJ

Michael Gogins-2 wrote: > > Csound may be BUILT for any (single) version of Python. > > Csound ...

View this message in context: http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26313285.html

Sent from the Csound - General mailing list archive at Nabble.com. Send bugs reports to this list...

I didn't say it would not work well.

I did say it is not as good, because it does NOT work BETTER and it is
more COMPLEX.

Regards,
Mike

On 11/12/09, Victor Lazzarini  wrote:
> The OSC idea is very good and it works well; it's actually being used
> by a frontend (Ounk) and it is the basis of RT communication in the
> new Cecilia.
>
> Regards
>
> Victor
>
>
> On 12 Nov 2009, at 12:43, Michael Gogins wrote:
>
>> Cvs has every thing, tarballs or installers may not.
>>
>> Osc would be like thread plus network plus extra buffers. Just use
>> threads.
>>
>> Mkg
>>
>>
>>> On Nov 11, 2009 11:31 PM, "Aaron Krister Johnson"
>>>  wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>> This is a very helpful list...regarding 'lack of examples' I was
>>> referring
>>> to usage of the API...but maybe that's what you are saying...I
>>> assume by
>>> examples directory you mean the source code tarball? I'll have a
>>> look later,
>>> I don't remember what I may have noticed in the past. Can you say
>>> more about
>>> 'CsoundPerformanceThread'?
>>>
>>> I was thinking earlier.....why not use a small TKinter app, bind
>>> some OSC
>>> messages to widgets, and send OSC messages to a non-GUI Csound
>>> instance? I
>>> wonder, since non-GUI Csound engines don't have these issues, if
>>> that might
>>> be the *fastest/easiest* route to GUI interaction with other
>>> toolkits?
>>>
>>> AKJ
>>> Michael Gogins-2 wrote: > > Csound may be BUILT for any (single)
>>> version of Python. > > Csound ...
>>>
>>> View this message in context:
>>> http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26313285.html
>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>> Send bugs reports to this list...
>>>
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

I didn't really disagree with you, I prefer the API approach. But if  
you have a better idea of OSC and does not want to learn the ins and  
outs of the API, is surely something worth trying.

Victor


On 12 Nov 2009, at 13:07, Michael Gogins wrote:

> I didn't say it would not work well.
>
> I did say it is not as good, because it does NOT work BETTER and it is
> more COMPLEX.
>
> Regards,
> Mike
>
> On 11/12/09, Victor Lazzarini  wrote:
>> The OSC idea is very good and it works well; it's actually being used
>> by a frontend (Ounk) and it is the basis of RT communication in the
>> new Cecilia.
>>
>> Regards
>>
>> Victor
>>
>>
>> On 12 Nov 2009, at 12:43, Michael Gogins wrote:
>>
>>> Cvs has every thing, tarballs or installers may not.
>>>
>>> Osc would be like thread plus network plus extra buffers. Just use
>>> threads.
>>>
>>> Mkg
>>>
>>>
>>>> On Nov 11, 2009 11:31 PM, "Aaron Krister Johnson"
>>>>  wrote:
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> This is a very helpful list...regarding 'lack of examples' I was
>>>> referring
>>>> to usage of the API...but maybe that's what you are saying...I
>>>> assume by
>>>> examples directory you mean the source code tarball? I'll have a
>>>> look later,
>>>> I don't remember what I may have noticed in the past. Can you say
>>>> more about
>>>> 'CsoundPerformanceThread'?
>>>>
>>>> I was thinking earlier.....why not use a small TKinter app, bind
>>>> some OSC
>>>> messages to widgets, and send OSC messages to a non-GUI Csound
>>>> instance? I
>>>> wonder, since non-GUI Csound engines don't have these issues, if
>>>> that might
>>>> be the *fastest/easiest* route to GUI interaction with other
>>>> toolkits?
>>>>
>>>> AKJ
>>>> Michael Gogins-2 wrote: > > Csound may be BUILT for any (single)
>>>> version of Python. > > Csound ...
>>>>
>>>> View this message in context:
>>>> http://old.nabble.com/question-regarding-GUI-xruns-tp26309243p26313285.html
>>>> Sent from the Csound - General mailing list archive at Nabble.com.
>>>> Send bugs reports to this list...
>>>>
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe
>> csound"
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot 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"