Realtime PyTK interface

Realtime PyTK interface - XRUNS

Date	2016-04-26 12:39
From	Christopher Charles
Subject	Realtime PyTK interface - XRUNS
	Hi everyone, I lately revisited one of my old but promising csound projects, a modular synthesizer with graphical interface written in python. * I start the synth via csound, everything audiowise is setup there * python is called from csound to start the (tkinter) GUI main loop and to set up the widgets * update.idletasks to update the gui drawing is run at k-rate So far so good, the synth started out really good, but as the interface grew and there were more and more widgets and bigger areas to draw (dirty rectangle updating can save you only so much if the patch cord spans over the whole interface), the xruns started coming. As for my bad design choices I realize now: * Using tkinter. Does not look like the fastest toolset around * Calling the main loop from csound. Single thread of csound handing over to to tk for redrawing then coming back for audio again and again. * not doing it the other way around: calling the csound audio processing in a thread from python I tried several approaches (short of rewriting the whole thing), but maybe you can help me out: * increase Buffer and/or ksmps -> works only up to a certain audio and patch complexity, realtime input feels sluggish * tried to put the tkinter main loop in its own thread/process. tkinter does not allow that, wants to run in the main thread I have not yet tried using a different TK version (mtTKinter [seems thread-safe], ActiveTCL), do you have any ideas? Can i instruct csound to run python in a separate thread? Thank you, Christopher Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2016-04-26 13:03
From	Tarmo Johannes
Subject	Re: Realtime PyTK interface - XRUNS
	Hi, Making UI calls from csound is bad idea, it leads you to dropouts sooner or later. The usual way is to keep the UI in main thread, start Csound as Csound PerformanceThread independently and use Csound API (channels, events and callbacks, if you need) dor communication. Ie start csound from python, not vice versa. Or sorry if I understood something wrong... Tarmo 26.04.2016 14:49 kirjutas kuupäeval "Christopher Charles" <chr.m.charles@gmail.com>: Hi everyone, I lately revisited one of my old but promising csound projects, a modular synthesizer with graphical interface written in python. * I start the synth via csound, everything audiowise is setup there * python is called from csound to start the (tkinter) GUI main loop and to set up the widgets * update.idletasks to update the gui drawing is run at k-rate So far so good, the synth started out really good, but as the interface grew and there were more and more widgets and bigger areas to draw (dirty rectangle updating can save you only so much if the patch cord spans over the whole interface), the xruns started coming. As for my bad design choices I realize now: * Using tkinter. Does not look like the fastest toolset around * Calling the main loop from csound. Single thread of csound handing over to to tk for redrawing then coming back for audio again and again. * not doing it the other way around: calling the csound audio processing in a thread from python I tried several approaches (short of rewriting the whole thing), but maybe you can help me out: * increase Buffer and/or ksmps -> works only up to a certain audio and patch complexity, realtime input feels sluggish * tried to put the tkinter main loop in its own thread/process. tkinter does not allow that, wants to run in the main thread I have not yet tried using a different TK version (mtTKinter [seems thread-safe], ActiveTCL), do you have any ideas? Can i instruct csound to run python in a separate thread? Thank you, Christopher Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Date	2016-04-26 16:46
From	Victor Lazzarini
Subject	Re: Realtime PyTK interface - XRUNS
Attachments	oscilloscope.py am.csd display.py
	Following from Tarmo, have a look at this example (attached). It’s a very basic oscilloscope that works in the way described. Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here ======================== Dr Victor Lazzarini Dean of Arts, Celtic Studies and Philosophy, Maynooth University, Maynooth, Co Kildare, Ireland Tel: 00 353 7086936 Fax: 00 353 1 7086952 > On 26 Apr 2016, at 13:03, Tarmo Johannes wrote: > > Hi, > > Making UI calls from csound is bad idea, it leads you to dropouts sooner or later. > The usual way is to keep the UI in main thread, start Csound as Csound PerformanceThread independently and use Csound API (channels, events and callbacks, if you need) dor communication. > > Ie start csound from python, not vice versa. > > Or sorry if I understood something wrong... > > Tarmo > > 26.04.2016 14:49 kirjutas kuupäeval "Christopher Charles" : > Hi everyone, > > I lately revisited one of my old but promising csound projects, a modular synthesizer with graphical interface written in python. > > * I start the synth via csound, everything audiowise is setup there > * python is called from csound to start the (tkinter) GUI main loop and to set up the widgets > * update.idletasks to update the gui drawing is run at k-rate > > So far so good, the synth started out really good, but as the interface grew and there were more and more widgets and bigger areas to draw (dirty rectangle updating can save you only so much if the patch cord spans over the whole interface), the xruns started coming. As for my bad design choices I realize now: > > * Using tkinter. Does not look like the fastest toolset around > * Calling the main loop from csound. Single thread of csound handing over to to tk for redrawing then coming back for audio again and again. > * not doing it the other way around: calling the csound audio processing in a thread from python > > I tried several approaches (short of rewriting the whole thing), but maybe you can help me out: > * increase Buffer and/or ksmps -> works only up to a certain audio and patch complexity, realtime input feels sluggish > * tried to put the tkinter main loop in its own thread/process. tkinter does not allow that, wants to run in the main thread > > I have not yet tried using a different TK version (mtTKinter [seems thread-safe], ActiveTCL), do you have any ideas? Can i instruct csound to run python in a separate thread? > > Thank you, > Christopher > > > > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here > Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here