On Wed, Jul 29, 2009 at 02:03:46PM +0000, John Martin Goddard wrote:
> Hello Everyone,
>
> I want to build a version of Audacity that accepts events from an external source and controls the record and playback functions of Audacity, and was hoping for advice on the best direction to go.
>
> Should I create and send command events into the WxWidgets part of the program?
> I perused the Creating Custom Events part of the WxWidgets docs, but I believe I'm not really creating custom events, but rather generating existing events from a customized source.
>
> Also, should my command-event-generating module be compiled into a DLL and loaded as a module with the others in the “LoadModules()” code? I am concerned about marshalling my object for method calls, and about it running on its own thread.
>
> Thanks in advance for any advice.
>
> I see there’s a big effort to get a release out, and prefer to help rather than hinder in this regard.
>
> Best Regards,
> Marty Goddard
>
> p.s. I’m compiling Audacity version 1.3.7 on Windows using Vista Business edition, and Visual Studio 9 (2008).
>
Hello,
I've been doing some work on the fairly experimental 'script pipe'
module which covers similar ground - it'd be great to be able to
coordinate efforts on this as controlling record/playback from a script
would be very useful.
The script module receives commands on a named pipe, interprets them and
builds appropriate 'Command' objects, which are tasked with actually
performing the action in question. (They can be given various parameters
as required and produce output on different channels). The command
objects are then posted to the main thread where they can be 'executed'
safely.
Currently this all happens synchronously and sequentially, which may or
may not be a problem for playing/recording. It's actually already
possible to send menu commands from a script, so I can trigger playback
and recording successfully. (For some reason, sending 'stop' after that
doesn't work though - haven't investigated this yet.)
This code is in CVS and much of it is reasonably new - none of the
'command' system is in 1.3.7, and it has changed a bit since 1.3.8 (and
may well change further) - but if you'd like to try this route I'm very
happy to answer any questions about getting it working.
The script pipe DLL itself is in lib-src/mod-script-pipe and is built
separately (haven't tried it on Vista but it works on XP). Even if you
decide you'd rather start a separate module, it's probably useful to
look at to see how the method calls and so on are done.
I'd imagine sending command events directly would work as that's quite
similar to how the script commands are sent (they are custom events, so
that they can hold the command data, and they're sent from a callback
function which is in the main program and is registered with the script
module).
If I was doing it I'd try creating Command classes for play/record/stop
(which would also allow scripts to perform those functions) - then a
module could use those classes directly or a separate program could act
as a script to call them via the named pipe.
Many thanks,
Dan
|
