Pro Tools "Compare" button

[jimstamm]

Does Juce 1.5 support the Pro Tools “Compare” feature? I thought that this would be enabled as part of parameter support, but it is not. I believe there is a “dirty” flag that goes with each parameter that has to be passed to the host.

Thanks
Jim Stammers
Minnetonka Audio Software, Inc.

[jules]

I’d never even heard of that feature, TBH…

[jimstamm]

I guess that means it’s not supported then

[jules]

If it doesn’t work, then no, I guess not! My PT setup is broken at the moment, but if you and/or other RTAS hackers want to tell me what needs tweaking I’ll happily help out in getting it working…

[jimstamm]

Jules,

In RTAS, in the PT SDK, CEffectProcess.h…

/*! \brief Called by host application. Determine if the chunk passed in is equal to the current settings.
*

• Checks values in EffectLayerDef::CONTROLS_CHUNK_ID chunk. Plugins can override this function
• if a custom chunk has been created \e and a change in a value of the custom chunk should
• turn on the “compare” light in the plugin header.
  */
  virtual ComponentResult CompareActiveChunk( SFicPlugInChunk *aChunkP, Boolean *aIsEqual);

The RTAS wrapper would override this method and invoke the equivalent method in the filter, peers to getStateInformation / setStateInformation I assume. The plugin author would have to do this compare, of course, since the state information chunk is plugin-specific.

Jim Stammers
Minnetonka Audio Software, Inc.

[Franky47]

I’m digging this up because it is quite related to my remarks:

I’ve been in contact with Digidesign’s support about chunk loading behaviours, they explained a lot of things about some weird multiple calls to setStateInformation I’ve only noticed recently.

Here’s what they said :

When a plug-in is first instantiated, CProcess::GetChunk() is called to retrieve the plug-in’s default chunk. Pro Tools caches this chunk in the session and associates it with the plug-in, and CProcess::SetChunk() is called with this default chunk on any future instantiations of the plug-in in the session.

for those of you who have an access to the Digidesign ThirdParty forum, here’s the link: https://developer.digidesign.com/phpbb/viewtopic.php?f=59&t=193&start=0&sid=235893b2e4fa699f2d68919225b87403

After more investigations, I measured the following behaviour for chunk access when using special features of ProTools:

First time instanciation:
[list]
[]Constructor[/]
[]GetChunkSize->getStateInformation (fetch the default chunk).[/]
[]SetChunk->setStateInformation (default chunk)[/]
[/list]

Other instanciations:
[list]
[]Constructor[/]
[]SetChunk->setStateInformation (default chunk)[/]
[/list]

Deactivation:
[list]
[]GetChunkSize->getStateInformation (save the state of the plugin)[/]
[]Destructor[/]
[/list]

Reactivation:
[list]
[]Constructor[/]
[]SetChunk->setStateInformation (load back the saved state).[/]
[/list]

Move instance:
[list]
[]GetChunkSize->getStateInformation[/]
[]Destructor[/]
[]Constructor[/]
[]SetChunk->setStateInformation (default chunk)[/]
[]SetChunk->setStateInformation (saved chunk)[/]
[/list]

Duplicate instance:
[list]
[]Constructor (duplicate)[/]
[]SetChunk->setStateInformation (duplicate, default chunk)[/]
[]GetChunkSize->getStateInformation (original)[/]
[]SetChunk->setStateInformation (duplicate, copied chunk)[/]
[/list]

Loading session:
[list]
[]Constructor[/]
[]SetChunk->setStateInformation (default chunk)[/]
[]SetChunk->setStateInformation (saved chunk)[/]
[/list]

I could not measure the sequence for saving session as development versions of ProTools (which allow debugging) cannot save.

The problem with this default chunk is that sometimes developers want to store things that might not be relevant at the moment where it is fetched, or it could lead to bugs when loading these default potential non-sensical values in every instance created (apart from those being reactivated, that are not applied the default chunk after creation). Also, it interferes with presets and compare light, as posted in digidesign’s dev blog:

If you have a plug-in with its own internal preset system then the behavior of the Compare Light in the Pro Tools plug-in header can be a bit unintuitive: instead of comparing your plug-in’s current state with the last preset that was loaded in the plug-in, the Compare Light will compare the plug-in’s state with the Factory Default settings that were stored by the plug-in when it was first loaded.

A solution was posted on digidesign’s dev blog, at the following address (requires login) https://developer.digidesign.com/devblog/?p=1092
One solution is to bypass the first fetch of this default chunk (to store an empty chunk for example), another is to ignore the first SetChunk calls (but this will break the de-activation/re-activation feature).

I’m afraid my problem is that users with existing default chunks saved in their sessions will have to cope with it, but for new plugins something could be added in the RTAS wrapper to avoid this. I’ll try some modifications and post them here if the results are satisfying.