On Wed, Oct 28, 2009 at 12:29:13AM +0000, John Martin Goddard wrote:
> 1) Markus Meyer wrote:
> > I would rather use something human-readable, like a string, say
> > something like "00001111001110011" where "1" means "selected" and "0"
> > means "unselected".
>
> Thanks for your suggestion, I agree. Especially since it will be straightforward in Perl scripts and others (I hope).
>
> The only question now (and I propose the following answer) is:
>
> Which character in the string represents which track number in Audacity?
>
> I propose it is numbered from Left to Right, (the reverse of bits in binary word), so that the character string length only need be as long as the number of tracks, such that charater 0, on the Left, is Track 0, and so on, for as many tracks as there are in the session document.
>
> This is probably obvious to most everyone, but deserves an explicit declaration.
>
> Additional ideas are encouraged.
>
I also agree that sticking to human-readable is best for the time being.
To what extent a string of 0's and 1's is really still human readable, I
don't know, but I can't currently think of a better compromise.
Ideally there would be some sort of library for handling a kind of
serialisation of Audacity objects, such as tracks, so that
script/program authors don't need to keep rewriting these routines. It
might also help with maintainability since changing the underlying
protocol wouldn't completely break compatibility with existing
scripts/programs. On the other hand, it is something else to write and
maintain in itself.
It might be possible to write one such library in C++ and then use
something like SWIG to generate bindings for scripting languages. I
don't have any experience with SWIG though so I don't know how feasible
this would be.
On the plus side, if this existed, it'd be much nicer to use than
communicating directly with Audacity. For example, a call along the
lines of 'project.GetTracks()[0].Rename("Vocals")' that would deal with
the whole business of sending the relevant commands and reading the
responses.
Anything like that is quite a long way off though, and would need some
planning, so for now I'm happy to make command protocol decisions by
taking whatever approach seems most pragmatic.
There's also a general question of whether processing (such as filtering
tracks according to whether they are selected) should take place in
Audacity or in the client. It's probably more flexible to have Audacity
make the state available in its most basic form (for example, with just
a command to get information about a single track) and then have the
script use that basic information in whatever way it needs to (e.g. loop
over the tracks and check whether each is selected). But that is more
awkward for the script author and it also requires more commands to be
sent.
I think getting the track information all in one go is a common enough
need to justify its inclusion in the command set, but in general it's
probably worth thinking carefully about any new command that may
duplicate functionality.
Just thinking aloud really - hope some of it turns out to be worthwhile!
Dan
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
