Thread: [Audacity-devel] Scripting improvements committed
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Dan H. <da...@go...> - 2009-05-30 05:20:02
|
Hi all, I've committed some of what I've been working on for GSoC so far: allowing the script plugin to pass commands to the main thread for execution. For those less familiar with the experimental scripting support ('mod-script-pipe'), it allows Audacity to be controlled via commands sent along a named pipe - for example, by a Perl script. These commands are received in a separate thread to the main app, and if that thread attempts to call any wxWidgets functions while the main thread is running then there's a high chance of a crash. Unfortunately most of the commands that one would like to be able to tell Audacity to perform do involve wxWidgets - even applying an effect will typically require displaying a progress bar, which can be enough to make the whole thing crash. So it is necessary to allow the script thread to send commands to the main thread to be executed when it is safe. This can be done via the wxwidgets events system. I have created a custom wxevent (AppCommandEvent) which derives from wxCommandEvent but can also store a pointer to a Command object inside it. The Command object is constructed by the script thread (in ScriptCommandRelay) via a CommandBuilder. Command is a base class which by default does nothing when Apply is called - the idea is that different types of command subclass Command and override Apply to do whatever it is they need to . For the moment, however, the CommandBuilder always creates a BatchEvalCommand. This command simply uses the existing BatchCommands system to do the execution. Hopefully this will allow parts of BatchCommand to be gradually moved out into separate classes, and will make it possible to eliminate the distinction between Effect, Menu and 'Special' commands at least on a high level. As well as making the code a bit clearer, this is to some extent necessary in order to allow scripting of many of the parts of the program that people want to be able to script - otherwise BatchCommand would become even more unwieldy. I've had to temporarily disable support for getting any responses or error messages back to the script from Audacity, since the previous system doesn't work easily with the GUI delegation. Getting this working is one of the next things on my list, along with working towards useful things like automated screenshot capture. I've added a makefile (based on one of Leland's) for the mod-script-pipe plugin. It needs the Audacity path filling in, and it's completely separate from the rest of the build system. It works for me, but I can't guarantee anything much beyond that! Please could somebody else update the MSVC solution/project and Mac equivalent with the new files? I have compiled and tested on Windows as well as Linux, but my solution file has some other modifications which I don't want to commit. Thanks! There's also a basic Perl script for trying out the scripting: scripts/pipe-test.pl. It's based on one from the audacity-extra website but with some changes. In particular, it now works properly on Linux. To try it, you need to run Audacity first (with the script plugin loaded), select some audio, and then run the script. This is all still very experimental, but any feedback or ideas are welcome. Hope I didn't break it for anybody! Thanks, Dan |
From: James C. <cr...@in...> - 2009-05-30 12:46:50
|
Dan, I'm hoping your mentor will have a chance to look at this real soon. I've meanwhile added these files to the MSVC solution as requested: ScriptCommandRelay.cpp CommandHandler.cpp CommandBuilder.cpp AppCommandEvent.cpp I notice that some of the new files are licensed under GPL. I'm thinking that the ability to script a wxWidgets application is something that is useful to wxWidgets. I personally would like it if the new command files were wxWidgets licensed so they could in principle be used in other projects. Some of them should perhaps live in lib-widget-extra - but this can be done later. The method for multi-line results was a hack. It's non-standard. If you see a better or more robust way to delimit the response results you're welcome to change it. Looks promising. Pleased that you have adapted the solution to linux too. --James. Dan Horgan wrote: > Hi all, > > I've committed some of what I've been working on for GSoC so far: > allowing the script plugin to pass commands to the main thread for > execution. For those less familiar with the experimental scripting > support ('mod-script-pipe'), it allows Audacity to be controlled via > commands sent along a named pipe - for example, by a Perl script. > > These commands are received in a separate thread to the main app, and if > that thread attempts to call any wxWidgets functions while the main > thread is running then there's a high chance of a crash. Unfortunately > most of the commands that one would like to be able to tell Audacity to > perform do involve wxWidgets - even applying an effect will typically > require displaying a progress bar, which can be enough to make the whole > thing crash. So it is necessary to allow the script thread to send > commands to the main thread to be executed when it is safe. > > This can be done via the wxwidgets events system. I have created a > custom wxevent (AppCommandEvent) which derives from wxCommandEvent but > can also store a pointer to a Command object inside it. The Command > object is constructed by the script thread (in ScriptCommandRelay) via a > CommandBuilder. Command is a base class which by default does nothing > when Apply is called - the idea is that different types of command > subclass Command and override Apply to do whatever it is they need to . > For the moment, however, the CommandBuilder always creates a > BatchEvalCommand. This command simply uses the existing BatchCommands > system to do the execution. > > Hopefully this will allow parts of BatchCommand to be gradually moved > out into separate classes, and will make it possible to eliminate the > distinction between Effect, Menu and 'Special' commands at least on a > high level. As well as making the code a bit clearer, this is to some > extent necessary in order to allow scripting of many of the parts of the > program that people want to be able to script - otherwise BatchCommand > would become even more unwieldy. > > I've had to temporarily disable support for getting any responses or > error messages back to the script from Audacity, since the previous > system doesn't work easily with the GUI delegation. Getting this working > is one of the next things on my list, along with working towards useful > things like automated screenshot capture. > > I've added a makefile (based on one of Leland's) for the mod-script-pipe > plugin. It needs the Audacity path filling in, and it's completely > separate from the rest of the build system. It works for me, but I can't > guarantee anything much beyond that! > > Please could somebody else update the MSVC solution/project and Mac > equivalent with the new files? I have compiled and tested on Windows as > well as Linux, but my solution file has some other modifications which I > don't want to commit. Thanks! > > There's also a basic Perl script for trying out the scripting: > scripts/pipe-test.pl. It's based on one from the audacity-extra website > but with some changes. In particular, it now works properly on Linux. To > try it, you need to run Audacity first (with the script plugin loaded), > select some audio, and then run the script. > > This is all still very experimental, but any feedback or ideas are > welcome. Hope I didn't break it for anybody! > > Thanks, > Dan > |
From: Dan H. <da...@go...> - 2009-05-31 13:01:00
|
On Sat, May 30, 2009 at 01:30:57PM +0100, James Crook wrote: > Dan, > > I'm hoping your mentor will have a chance to look at this real soon. > I've meanwhile added these files to the MSVC solution as requested: > ScriptCommandRelay.cpp > CommandHandler.cpp > CommandBuilder.cpp > AppCommandEvent.cpp > > I notice that some of the new files are licensed under GPL. I'm > thinking that the ability to script a wxWidgets application is something > that is useful to wxWidgets. I personally would like it if the new > command files were wxWidgets licensed so they could in principle be used > in other projects. Some of them should perhaps live in lib-widget-extra > - but this can be done later. Thanks, and good point about the licenses - I'd forgotten about that. > > The method for multi-line results was a hack. It's non-standard. If > you see a better or more robust way to delimit the response results > you're welcome to change it. Maybe send an empty line between each command response? It's unlikely that an empty line will ever need to be sent itself as a response, and it makes it easy for a script to get all of the response lines for a command. What I imagine is that the commands are input as they are currently, but since they are now sent to the main thread for execution, the response might not be available to send until some time after the command was received from the script. Once it is available, the main thread needs to get the response back to the script somehow. Rather than sending the data back to the script thread (awkward since the events system can't be used) I think it makes sense to let the main thread do the output, by calling a function in the plugin. Since this would be done before the event handler returns, commands would still be executed one at a time and in the right order even if the script ignores the responses. > Looks promising. Pleased that you have adapted the solution to linux too. > > --James. > > > > > Dan Horgan wrote: > > Hi all, > > > > I've committed some of what I've been working on for GSoC so far: > > allowing the script plugin to pass commands to the main thread for > > execution. For those less familiar with the experimental scripting > > support ('mod-script-pipe'), it allows Audacity to be controlled via > > commands sent along a named pipe - for example, by a Perl script. > > > > These commands are received in a separate thread to the main app, and if > > that thread attempts to call any wxWidgets functions while the main > > thread is running then there's a high chance of a crash. Unfortunately > > most of the commands that one would like to be able to tell Audacity to > > perform do involve wxWidgets - even applying an effect will typically > > require displaying a progress bar, which can be enough to make the whole > > thing crash. So it is necessary to allow the script thread to send > > commands to the main thread to be executed when it is safe. > > > > This can be done via the wxwidgets events system. I have created a > > custom wxevent (AppCommandEvent) which derives from wxCommandEvent but > > can also store a pointer to a Command object inside it. The Command > > object is constructed by the script thread (in ScriptCommandRelay) via a > > CommandBuilder. Command is a base class which by default does nothing > > when Apply is called - the idea is that different types of command > > subclass Command and override Apply to do whatever it is they need to . > > For the moment, however, the CommandBuilder always creates a > > BatchEvalCommand. This command simply uses the existing BatchCommands > > system to do the execution. > > > > Hopefully this will allow parts of BatchCommand to be gradually moved > > out into separate classes, and will make it possible to eliminate the > > distinction between Effect, Menu and 'Special' commands at least on a > > high level. As well as making the code a bit clearer, this is to some > > extent necessary in order to allow scripting of many of the parts of the > > program that people want to be able to script - otherwise BatchCommand > > would become even more unwieldy. > > > > I've had to temporarily disable support for getting any responses or > > error messages back to the script from Audacity, since the previous > > system doesn't work easily with the GUI delegation. Getting this working > > is one of the next things on my list, along with working towards useful > > things like automated screenshot capture. > > > > I've added a makefile (based on one of Leland's) for the mod-script-pipe > > plugin. It needs the Audacity path filling in, and it's completely > > separate from the rest of the build system. It works for me, but I can't > > guarantee anything much beyond that! > > > > Please could somebody else update the MSVC solution/project and Mac > > equivalent with the new files? I have compiled and tested on Windows as > > well as Linux, but my solution file has some other modifications which I > > don't want to commit. Thanks! > > > > There's also a basic Perl script for trying out the scripting: > > scripts/pipe-test.pl. It's based on one from the audacity-extra website > > but with some changes. In particular, it now works properly on Linux. To > > try it, you need to run Audacity first (with the script plugin loaded), > > select some audio, and then run the script. > > > > This is all still very experimental, but any feedback or ideas are > > welcome. Hope I didn't break it for anybody! > > > > Thanks, > > Dan > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: James C. <cr...@in...> - 2009-05-31 20:01:00
|
Dan Horgan wrote: > I notice that the latest wxwidgets has a wxMessageQueue<T> class > designed for this very purpose. Is it worth trying to use this with > the stable wxwidgets? > When we were using MSVC 6.0 we avoided templates because they were buggy, but that's history now. Templates are fine in MSVC 2005. It's your call whether to use wxMessageQueue<T>. Be prepared for needing care if using wxStrings if mallocs and frees could be happening in different threads. Using wxMessageQueue<T> is unlikely to save us work later on. Our experience with wxTreeBook is that the design changed enough between pre-release and and stable that it didn't help a lot having taken it on early. I'd say use wxMessageQueue<T> if you're motivate and interested to try it out for its own sake, or if you like the design and think it will be cleaner/easier to develop that way. Don't use it just for the principle. I'd really be as happy with a clean simple roll-your-own method, possibly with a 'queue of size one' if that is what you choose. --James. |
From: Michael C. <mc...@gm...> - 2009-06-01 03:40:13
|
Hi Dan, I'm building as I type this message. My first thought is about wxEvents. I think you've delved into the wx event system further than I have, but I do remember something about wxCommandEvent being slightly not threadsafe, and causing certain operations to fail. This comes from the fact that wxCommandEvent contains a wxString, which is NOT thread safe. This apparently does not cause an issue for some event usage, but if you get strange crashes, this is something to consider: As recently as 2008 Vadim Zetlin explains this: http://www.archivum.info/comp.soft-sys.wxwindows/2008-04/msg00456.html So I would also recommend not using any wxStrings in your shared script-main thread data. About where to block: On Sun, May 31, 2009 at 1:55 PM, Dan Horgan <da...@go...> wrote: On Sun, May 31, 2009 at 03:52:36PM +0100, James Crook wrote: > Dan Horgan wrote: > > Rather than sending the > > data back to the script thread (awkward since the events system can't be > > used) I think it makes sense to let the main thread do the output, by > > calling a function in the plugin. Since this would be done before the > > event handler returns, commands would still be executed one at a time > > and in the right order even if the script ignores the responses. > > > I don't think that is a good solution. Audacity GUI could hang waiting > on the script in that case. For example if the script has been killed > during processing the command. I'm not sure that is the case for pipes, > but for TCP/IP it could be doing retries and so on that could go on for > minutes. > > I think that doing the 'awkward thing' is necessary. You do need to get > data back from the gui thread to the non gui thread. You'd use a mutex > to protect an object or pointer used to share data between the two > threads, and that would be picked up on the next poll from the non-gui > thread, or pause and resume the non gui thread if the non gui thread > needs to wait. > I'd think the non GUI thread usually does need to wait - for the > majority of operations that it invokes (play and record are possible > exceptions that may need something more advanced). > > It is quite possible I've got things wrong here. If that's the case > please argue it until it is clearer. There are other advantages to letting the main thread execute the entire command - If you use the main thread for the user input only, and then do the command execution on the script thread, you will be a TON more resources that are currently non-threadsafe in audacity. It seems to me like you might want to pass some info back to the scripting thread - but maybe this should just be data about the scripting itself (e.g. %completed, user hits cancel). Is there an example that makes this difficult? I may be misunderstanding something - if so, please clarify. Looks good overall, I'm excited about playing around with it. I hope to give test results back on tuesday. I have finals mon and tues morning, but will keep an eye on this thread. Best, Michael |
From: James C. <cr...@in...> - 2009-06-01 13:05:52
|
Michael Chinen wrote: > There are other advantages to letting the main thread execute the > entire command - If you use the main thread for the user input only, > and then do the command execution on the script thread, you will be a > TON more resources that are currently non-threadsafe in audacity. It > seems to me like you might want to pass some info back to the > scripting thread - but maybe this should just be data about the > scripting itself (e.g. %completed, user hits cancel). I think that is the plan, i.e. that GUI thread executes the commands, non GUI thread is only responsible for comms, but is (subject to discussion) now responsible for both directions i.e both in and out. > Is there an example that makes this difficult? I may be > misunderstanding something - if so, please clarify. In my view the first cut should not attempt to pass progress indications back, just a completion status (if that). Progress indication is the kind of thing one might want a script to explicitly opt in to - in many cases handling a progress indicator in a script will complicate the script. > Looks good overall, I'm excited about playing around with it. I hope > to give test results back on tuesday. I have finals mon and tues > morning, but will keep an eye on this thread. > All the best with your exams, Michael. Hope they go well. --James. |
From: Dan H. <da...@go...> - 2009-06-01 16:22:08
|
On Sun, May 31, 2009 at 11:39:51PM -0400, Michael Chinen wrote: > Hi Dan, > > I'm building as I type this message. My first thought is about wxEvents. I > think you've delved into the wx event system further than I have, but I do > remember something about wxCommandEvent being slightly not threadsafe, and > causing certain operations to fail. This comes from the fact that > wxCommandEvent contains a wxString, which is NOT thread safe. > This apparently does not cause an issue for some event usage, but if you > get strange crashes, this is something to consider: > As recently as 2008 Vadim Zetlin explains this: > http://www.archivum.info/comp.soft-sys.wxwindows/2008-04/msg00456.html > > So I would also recommend not using any wxStrings in your shared script-main > thread data. Thanks, that's definitely something to be aware of... In the wxCommandEvent derived class, I'm not setting/getting the wxString so hopefully that shouldn't be an issue. The event transports a pointer to a Command on the heap, which should only be accessed in one thread at a time - I did want to enforce this but it was complicating things so I left it to trust that it is used in the right way, for the time being. The command has to be deleted by the event handler after it has been applied. It's a somewhat unsophisticated way of doing it and it might be better to have commands stored by a central class which ensures there can only be one reference at a time to any given command. I haven't noticed any problems related to this as yet, but if anybody does have strange behaviour then please do let me know. I will definitely avoid wxStrings for the shared data though, because it sounds like that would almost certainly cause trouble. > > About where to block: > > On Sun, May 31, 2009 at 1:55 PM, Dan Horgan <da...@go...> wrote: > On Sun, May 31, 2009 at 03:52:36PM +0100, James Crook wrote: > > Dan Horgan wrote: > > > Rather than sending the > > > data back to the script thread (awkward since the events system can't be > > > used) I think it makes sense to let the main thread do the output, by > > > calling a function in the plugin. Since this would be done before the > > > event handler returns, commands would still be executed one at a time > > > and in the right order even if the script ignores the responses. > > > > > I don't think that is a good solution. Audacity GUI could hang waiting > > on the script in that case. For example if the script has been killed > > during processing the command. I'm not sure that is the case for pipes, > > but for TCP/IP it could be doing retries and so on that could go on for > > minutes. > > > > I think that doing the 'awkward thing' is necessary. You do need to get > > data back from the gui thread to the non gui thread. You'd use a mutex > > to protect an object or pointer used to share data between the two > > threads, and that would be picked up on the next poll from the non-gui > > thread, or pause and resume the non gui thread if the non gui thread > > needs to wait. > > I'd think the non GUI thread usually does need to wait - for the > > majority of operations that it invokes (play and record are possible > > exceptions that may need something more advanced). > > > > It is quite possible I've got things wrong here. If that's the case > > please argue it until it is clearer. > > There are other advantages to letting the main thread execute the entire > command - If you use the main thread for the user input only, and then do > the command execution on the script thread, you will be a TON more resources > that are currently non-threadsafe in audacity. It seems to me like you > might want to pass some info back to the scripting thread - but maybe this > should just be data about the scripting itself (e.g. %completed, user hits > cancel). The current plan as far as I'm aware is to have the following sort of sequence of events: 1) Script writes command string on pipe 2) mod-script-pipe reads command string (script thread) 3) String passed to more general execution function, still in script thread 4) Build a command from the string - if syntactically valid, send command in an event to main thread - if not, immediately send error back to script via mod-script-pipe and start again 5) Main thread event handler called with command event, command retrieved and executed, and responses are sent via shared data back to script thread 6) Script thread is waiting for all responses, sending them to the script as they are received 7) When finished, script thread gets next command string from pipe So it's only the command and the responses that are sent between threads. This does require that the communication method has enough buffering that sending several commands while the previous one is executing doesn't result in lost commands though... I'm not sure how likely this is to be a problem. I'm pretty sure now that it is necessary to send data back to the script thread, even if it was just a notification that the command has completed, because it can easily hang if a new command event is recieved while the previous one is executing... > > Is there an example that makes this difficult? I may be misunderstanding > something - if so, please clarify. > > Looks good overall, I'm excited about playing around with it. I hope to > give test results back on tuesday. I have finals mon and tues morning, but > will keep an eye on this thread. Good luck! Dan > > Best, > > Michael > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Michael C. <mc...@gm...> - 2009-06-03 05:29:40
|
Hi Dan, Looks great - I'm generally impressed with the code structure and cleanliness. Some comments on future implementations below: On Mon, Jun 1, 2009 at 12:22 PM, Dan Horgan <da...@go...> wrote: > <SNIP> > The current plan as far as I'm aware is to have the following sort of > sequence of events: > 1) Script writes command string on pipe > 2) mod-script-pipe reads command string (script thread) > 3) String passed to more general execution function, still in script > thread > 4) Build a command from the string - if syntactically valid, send > command in an event to main thread - if not, immediately send error back > to script via mod-script-pipe and start again > 5) Main thread event handler called with command event, command > retrieved and executed, and responses are sent via shared data back to > script thread > 6) Script thread is waiting for all responses, sending them to the script > as > they are received > 7) When finished, script thread gets next command string from pipe > > So it's only the command and the responses that are sent between > threads. This does require that the communication method has enough > buffering that sending several commands while the previous one is > executing doesn't result in lost commands though... I'm not sure how > likely this is to be a problem. > > I'm pretty sure now that it is necessary to send data back to the script > thread, even if it was just a notification that the command has > completed, because it can easily hang if a new command event is recieved > while the previous one is executing... If I understand it correctly, you only will have one command being executed at a time. So it is okay to block the script thread while the previous command is being executed by the main thread (assuming the input will be buffered on the pipe - I'm not knowledgeable about the pipe part.) This simple structure will also prevent the creation of new XCommandEvents. Also, have you looked at wxCondition (or the pthreads version)? It seems like the right idea since it will make the script wait until a previous one finishes: http://docs.wxwidgets.org/stable/wx_wxcondition.html#wxcondition You could have two wxConditions belong to the AppCommandEvent - one to unblock the script thread after the command has been finished, and another to keep the XCommandEvent around (before it gets deleted) so that the Script thread can access it's member variables to get a message out to send to the script. The first wxCondition would have its Wait called on the script thread, and Broadcast() on the main thread (in Apply.) The other wxCondition wuld have its Wait() in Apply(), and Broadcast() on the scripting thread. I don't think this would cause any deadlocks. I put a little time in to look at the script, and to try to get it working with audacity, but I think mod-script-pipe isn't compiling to a library yet for mac. Or am I mistaken? For starters I modified it to recognize mac machines. Best, Michael > > > > Is there an example that makes this difficult? I may be misunderstanding > > something - if so, please clarify. > > > > Looks good overall, I'm excited about playing around with it. I hope to > > give test results back on tuesday. I have finals mon and tues morning, > but > > will keep an eye on this thread. > > Good luck! > > Dan > > > > > Best, > > > > Michael > > > > ------------------------------------------------------------------------------ > > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > > is a gathering of tech-side developers & brand creativity professionals. > Meet > > the minds behind Google Creative Lab, Visual Complexity, Processing, & > > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > > _______________________________________________ > > audacity-devel mailing list > > aud...@li... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Dan H. <da...@go...> - 2009-06-04 01:01:19
|
On Wed, Jun 03, 2009 at 01:29:17AM -0400, Michael Chinen wrote: > <SNIP> > > If I understand it correctly, you only will have one command being executed > at a time. > So it is okay to block the script thread while the previous command is being > executed by the main thread (assuming the input will be buffered on the pipe > - I'm not knowledgeable about the pipe part.) This simple structure will > also prevent the creation of new XCommandEvents. > > Also, have you looked at wxCondition (or the pthreads version)? It seems > like the right idea since it will make the script wait until a previous one > finishes: > http://docs.wxwidgets.org/stable/wx_wxcondition.html#wxcondition > > You could have two wxConditions belong to the AppCommandEvent - one to > unblock the script thread after the command has been finished, and another > to keep the XCommandEvent around (before it gets deleted) so that the Script > thread can access it's member variables to get a message out to send to the > script. The first wxCondition would have its Wait called on the script > thread, and Broadcast() on the main thread (in Apply.) The other > wxCondition wuld have its Wait() in Apply(), and Broadcast() on the > scripting thread. I don't think this would cause any deadlocks. Thanks, this sounds like a good approach. One thing I'm hesitant about though is storing the wxConditions in the event - firstly I don't want to have to worry about what happens to the events behind the scenes (copying etc), and secondly keeping them separate might be useful later on in case we want to change things to allow unprompted 'responses' (i.e. script waits until notified that certain event has occurred in the app). The alternative at the moment would probably be putting them in ScriptCommandRelay, which currently means making them static. Anyway, I presume it is ok to block the main thread briefly in order to make sure the script thread is not accessing the shared data, rather than losing responses? > > I put a little time in to look at the script, and to try to get it working > with audacity, but I think mod-script-pipe isn't compiling to a library yet > for mac. Or am I mistaken? For starters I modified it to recognize mac > machines. Hopefully Leland's update has sorted this out... Thanks, Dan |
From: Michael C. <mc...@gm...> - 2009-06-06 01:25:58
|
Hi Leland, Thanks for looking into this. I haven't been able to build with the new mac project from xcode - mod-script-pipe gives the error: I've tried messing around with the "Mach-O Type" to no avail. Any ideas? My mac build breaks with: Ld "/Users/apple/cvscheckouts/audacity/mac/build/Debug Static/modules/mod-script-pipe.so" normal ppc <snip> /Developer/usr/bin/../libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: -single_module or -multi_module flags can only be used when -dylib is also specified collect2: ld returned 1 exit status On Wed, Jun 3, 2009 at 8:30 PM, Dan Horgan <da...@go...> wrote: > On Wed, Jun 03, 2009 at 01:29:17AM -0400, Michael Chinen wrote: > > <SNIP> > > > > If I understand it correctly, you only will have one command being > executed > > at a time. > > So it is okay to block the script thread while the previous command is > being > > executed by the main thread (assuming the input will be buffered on the > pipe > > - I'm not knowledgeable about the pipe part.) This simple structure will > > also prevent the creation of new XCommandEvents. > > > > Also, have you looked at wxCondition (or the pthreads version)? It seems > > like the right idea since it will make the script wait until a previous > one > > finishes: > > http://docs.wxwidgets.org/stable/wx_wxcondition.html#wxcondition > > > > You could have two wxConditions belong to the AppCommandEvent - one to > > unblock the script thread after the command has been finished, and > another > > to keep the XCommandEvent around (before it gets deleted) so that the > Script > > thread can access it's member variables to get a message out to send to > the > > script. The first wxCondition would have its Wait called on the script > > thread, and Broadcast() on the main thread (in Apply.) The other > > wxCondition wuld have its Wait() in Apply(), and Broadcast() on the > > scripting thread. I don't think this would cause any deadlocks. > > Thanks, this sounds like a good approach. One thing I'm hesitant about > though is storing the wxConditions in the event - firstly I don't want > to have to worry about what happens to the events behind the scenes > (copying etc), and secondly keeping them separate might be useful later > on in case we want to change things to allow unprompted 'responses' > (i.e. script waits until notified that certain event has occurred in the > app). The alternative at the moment would probably be putting them in > ScriptCommandRelay, which currently means making them static. > > Anyway, I presume it is ok to block the main thread briefly in order to > make > sure the script thread is not accessing the shared data, rather than > losing responses? > > > > > I put a little time in to look at the script, and to try to get it > working > > with audacity, but I think mod-script-pipe isn't compiling to a library > yet > > for mac. Or am I mistaken? For starters I modified it to recognize mac > > machines. > > Hopefully Leland's update has sorted this out... > > > Thanks, > Dan > |
From: Leland <le...@au...> - 2009-06-06 03:18:56
|
Michael Chinen wrote: > Hi Leland, > > Thanks for looking into this. > > I haven't been able to build with the new mac project from xcode - > mod-script-pipe gives the error: > And I see that the "Release" configurations don't build either using Xcode 2.5. :-( Working on it. Leland |
From: James C. <cr...@in...> - 2009-05-31 14:52:42
|
Dan Horgan wrote: > Rather than sending the > data back to the script thread (awkward since the events system can't be > used) I think it makes sense to let the main thread do the output, by > calling a function in the plugin. Since this would be done before the > event handler returns, commands would still be executed one at a time > and in the right order even if the script ignores the responses. > I don't think that is a good solution. Audacity GUI could hang waiting on the script in that case. For example if the script has been killed during processing the command. I'm not sure that is the case for pipes, but for TCP/IP it could be doing retries and so on that could go on for minutes. I think that doing the 'awkward thing' is necessary. You do need to get data back from the gui thread to the non gui thread. You'd use a mutex to protect an object or pointer used to share data between the two threads, and that would be picked up on the next poll from the non-gui thread, or pause and resume the non gui thread if the non gui thread needs to wait. I'd think the non GUI thread usually does need to wait - for the majority of operations that it invokes (play and record are possible exceptions that may need something more advanced). It is quite possible I've got things wrong here. If that's the case please argue it until it is clearer. --James. |
From: Leland <le...@au...> - 2009-06-07 18:15:26
|
Michael Chinen wrote: > Hi Leland, > > Thanks for looking into this. > > I haven't been able to build with the new mac project from xcode - > mod-script-pipe gives the error: > Sorry this took a while Michael. I just committed a fix. It should work okay now...hopefully. :-) Leland |
From: Michael C. <mc...@gm...> - 2009-06-08 03:03:05
|
Leland, Thanks, that did it! On Sun, Jun 7, 2009 at 2:15 PM, Leland <le...@au...> wrote: > Michael Chinen wrote: > > Hi Leland, > > > > Thanks for looking into this. > > > > I haven't been able to build with the new mac project from xcode - > > mod-script-pipe gives the error: > > > Sorry this took a while Michael. I just committed a fix. It should > work okay now...hopefully. :-) > > Leland > > > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Dan H. <da...@go...> - 2009-05-31 17:55:25
|
On Sun, May 31, 2009 at 03:52:36PM +0100, James Crook wrote: > Dan Horgan wrote: > > Rather than sending the > > data back to the script thread (awkward since the events system can't be > > used) I think it makes sense to let the main thread do the output, by > > calling a function in the plugin. Since this would be done before the > > event handler returns, commands would still be executed one at a time > > and in the right order even if the script ignores the responses. > > > I don't think that is a good solution. Audacity GUI could hang waiting > on the script in that case. For example if the script has been killed > during processing the command. I'm not sure that is the case for pipes, > but for TCP/IP it could be doing retries and so on that could go on for > minutes. Hmm, you may have a point. It works in the cases where writing is non-blocking - I believe this can be arranged for pipes and possibly for TCP/IP, but it might be best not to assume it. > > I think that doing the 'awkward thing' is necessary. You do need to get > data back from the gui thread to the non gui thread. You'd use a mutex > to protect an object or pointer used to share data between the two > threads, and that would be picked up on the next poll from the non-gui > thread, or pause and resume the non gui thread if the non gui thread > needs to wait. I notice that the latest wxwidgets has a wxMessageQueue<T> class designed for this very purpose. Is it worth trying to use this with the stable wxwidgets? > I'd think the non GUI thread usually does need to wait - for the > majority of operations that it invokes (play and record are possible > exceptions that may need something more advanced). > > It is quite possible I've got things wrong here. If that's the case > please argue it until it is clearer. > > > --James. > > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Leland <le...@au...> - 2009-06-03 05:43:57
|
Michael Chinen wrote: > > I put a little time in to look at the script, and to try to get it > working with audacity, but I think mod-script-pipe isn't compiling to a > library yet for mac. Or am I mistaken? You were not. But if you asked the question again, you would be. :-) (I re-enabled building of mod-script-pipe.) Leland |
From: Leland <le...@au...> - 2009-06-03 06:24:35
|
Leland wrote: > Michael Chinen wrote: >> I put a little time in to look at the script, and to try to get it >> working with audacity, but I think mod-script-pipe isn't compiling to a >> library yet for mac. Or am I mistaken? > > You were not. But if you asked the question again, you would be. :-) > > (I re-enabled building of mod-script-pipe.) > In case it matters (harmless otherwise), we are not getting this message when Audacity starts: Unable to open fifo from server to script: Interrupted system call Leland |