Re: [Audacity-devel] Scripting command requests

[John Martin Goddard <jmgoddar@sy...>]

Hi Dan,

Thanks a lot for your posting, and I'm glad to hear you're back.
And very sorry for my late response.

>I believe it's possible to set the selected track by number already,
>using something like: "Select: Type=Range FirstTrack=2 LastTrack=2",
>although it might still be good to have a more direct way of doing this.

Thanks for the reference to the Select script command.

The syntax is only very slightly different (I know you stated an approximation).
Instead of "Type" the syntax uses "Mode", so that the syntax is:

Select: Mode==None/All/Range/Name

(where Range is given by: "FirstTrack=2 LastTrack=3").

I see it's possible to select tracks by name.  This is wonderful for me,
because I want the user to be able to do this by voice, and having this
will make it a little easier, as long as I can resolve homophonic track names.

>Am I right in thinking this would return a 'y/n' depending on whether the
>specified track is selected?

Yes, I have it returning "true" or "false".  I'll check for consistency
before proceeding.  I agree "IsSelected" is better.

I have GetTrackInfo Type=Gain/Pan/Solo/Mute/Linked working but not
fully tested.


>> 2. Add to GetTrackInfo: Type=Pan and Type=Volume
>> This will allow remote update of status after incremental changes are made to these settings.
> This seems like a good idea. It'd probably make sense to add these types to
> SetTrackInfo as well.

Agreed.  But since there already exists the following:

MenuCommand: TrackPanLeft/TrackPanRight/TrackGainInc/Dec,

I'm not pressed to do this immediately.  But hopefeully eventually.


>> 3. Refresh after renaming a track, and perhaps some other changes, do not appear until a refresh happens.
> Regarding GUI refresh for track name, etc:
> Yes, it might be safest to just refresh after executing any received command.
> I haven't looked into how to force a refresh, but I know where to add the code.

If you do have a suggestion for this, I'd appreciate it, if you have a chance.


>As a side note: I believe it should (in theory) be possible for an Audacity
>module to add new commands to the set, which can then be used via the
>pipe. Not that it ought to be necessary in the above cases, but it does
>mean that specialised modules can extend the scripting capabilities if
>necessary.

I know another who's implemented a custom command and module which
fits into this category, so this is definitely a topic for further discussion.

>I'm also looking into using macros to make command definitions more
>concise, as there are a lot of similar class declarations at the moment.

Are you talking about refining the existing command set for consistency,
or about allowing macros to define more macros (which I consider to be
classical computer engineering)?

>Dan

I keep nudging progress on many fronts... and I hope it's not all too slowly.
Keeping consistency and necessity as priorities when making any changes
to Audacity.

Best Regards,
Marty

Re: [Audacity-devel] Scripting command requests

[Dan Horgan <danhgn@go...>]

On Tue, Oct 27, 2009 at 12:45:42PM +0000, John Martin Goddard wrote:
> Thanks for the reference to the Select script command.
> 
> The syntax is only very slightly different (I know you stated an approximation).
> Instead of "Type" the syntax uses "Mode", so that the syntax is:
> 
> Select: Mode==None/All/Range/Name
> 
> (where Range is given by: "FirstTrack=2 LastTrack=3").

Ah yes, sorry for the mistake.

> I see it's possible to select tracks by name.  This is wonderful for me,
> because I want the user to be able to do this by voice, and having this
> will make it a little easier, as long as I can resolve homophonic track names.
> 
> >Am I right in thinking this would return a 'y/n' depending on whether the
> >specified track is selected?
> 
> Yes, I have it returning "true" or "false".  I'll check for consistency
> before proceeding.  I agree "IsSelected" is better.
> 
> I have GetTrackInfo Type=Gain/Pan/Solo/Mute/Linked working but not
> fully tested.
> 

Sounds good, thanks - feel free to post patches when it's ready.

> >> 2. Add to GetTrackInfo: Type=Pan and Type=Volume
> >> This will allow remote update of status after incremental changes are made to these settings.
> > This seems like a good idea. It'd probably make sense to add these types to
> > SetTrackInfo as well.
> 
> Agreed.  But since there already exists the following:
> 
> MenuCommand: TrackPanLeft/TrackPanRight/TrackGainInc/Dec,
> 
> I'm not pressed to do this immediately.  But hopefeully eventually.
> 

The menu commands provide a lot of power but are intimately connected
with the GUI, so in the long term it will probably be better in general
to reproduce that functionality with dedicated commands. As well as
providing more control it'll avoid problems that could occur if GUI
behaviour changes. For example, the increment amount for the gain slider
could be adjusted, which might throw off scripts/programs that use
TrackGainInc.

> >> 3. Refresh after renaming a track, and perhaps some other changes, do not appear until a refresh happens.
> > Regarding GUI refresh for track name, etc:
> > Yes, it might be safest to just refresh after executing any received command.
> > I haven't looked into how to force a refresh, but I know where to add the code.
> 
> If you do have a suggestion for this, I'd appreciate it, if you have a chance.
> 

I've committed a change to CVS which should take care of this - at least,
it seems to work for the renaming case.

> 
> >As a side note: I believe it should (in theory) be possible for an Audacity
> >module to add new commands to the set, which can then be used via the
> >pipe. Not that it ought to be necessary in the above cases, but it does
> >mean that specialised modules can extend the scripting capabilities if
> >necessary.
> 
> I know another who's implemented a custom command and module which
> fits into this category, so this is definitely a topic for further discussion.

That's interesting to hear, I'm intrigued about how it's being used.

> 
> >I'm also looking into using macros to make command definitions more
> >concise, as there are a lot of similar class declarations at the moment.
> 
> Are you talking about refining the existing command set for consistency,
> or about allowing macros to define more macros (which I consider to be
> classical computer engineering)?

I was talking about preprocessor macros (i.e. #defines) along the lines
of DEFINE_COMMAND(Select) which, together with other similar statements,
would expand into class definitions like the ones in some of the files
in the commands directory, just to cut down the amount of repeated code.
I thought I'd mention it on the list in case there were any objections
to the style, although I think it's the same approach as is taken by
wxWidgets.

> >Dan
>