[Audacity-devel] InterApplication Communication (IAC) via Named Pipes

[John M. G. <jmg...@sy...>]

Hello James and David,

Thanks for the recommendation to set up a Wiki page on remoting via named pipes.   I will study existing pages for format and content ideas and set one up as soon as I can.  However, since I'm still deep in development, I won't be able to offer any working code for awhile.  I hope this is okay.

I'd like to link to David Wallace's page as well as the one for Scripting.

By the way, I wonder what happened to the previous "Scripting" page.  Has it been replaced with "Automation"?  I think there's a page describing how to upload new code additions.

As existing scripts are limited to menu commands and batch commands, I am interested in learning how David sets start/end times.  I know this is also something Dan Horgan has implemented, but I haven't yet tried.

I want to be able to mute/solo tracks, name them, set volume levels, and more.  However, I'll exhaust the possibilities with standard menu commands before venturing into custom Commands.

>David Wallace:  I started my development from the same premise but eventually concluded that mod-
>script-pipe would not suit my purpose. It is suited to asynchronous batch processing a
>set of commands and uses 2 uni-directional pipes. I have an "instantaneous"
>handshaking exchange of information over a single bi-directional pipe.

I agree that Audacity uses two pipes: "ToSrvPipe", and "FromSrvPipe", but I believe each is initialized as bi-directional (PIPE_ACCESS_DUPLEX), but they are only used as unidirectional pipes.   I wonder, was this done for a specific reason, instead of using a single bi-directional pipe?

Or why instead of setting up ToSrvPipe as PIPE_ACCESS_INBOUND, and FromSrvPipe as PIPE_ACCESS_OUTBOUND (or perhaps the other way around --- but I believe To/FromSrvPipe names to be from the Point of View of the ExternalScript).  It makes sense that this was probably done for better interface with Perl scripts.

Perhaps this points to having separate pipes, one for IAC and one Perl Scripting?

I'm flexible at the moment, but will latch on to whatever works best.  From this vantage point, it seems that a lot could be done over IAC, using the existing command handling for scripts.

At the moment, I'm working toward a having functioning prototype, investigating instabilities such as the pipe going into a bogus state, such that it cannot be accessed by the scripts, nor by my toy application...

Thanks again for your advice on the Wiki.   I would look forward to testing out any prototypes that are made available.

Best Regards,
Marty