[Bug? Solved] Rack Re-Initialization

Cantabile
1

I’ve encountered a situation where C4 (v4062) is re-loading the same Linked Rack between two songs. The state of the Linked Rack is re-initialized and the Rack->[On Load] bindings in the rack are re-triggered. This might need @brad attention.

As I understand it, a given Linked Rack should stay loaded between songs … as long as it is the same Rack that is loaded. On a switch from song S1 to song S2, if the same rack R1 is in both songs, the state of R1 should remain intact and the Rack->[On Load] bindings in R1 should not be triggered.

The issue, I think, is how C4 determines if two rack references in two different song files are determined to refer to “the same rack”.

After a lot of sleuthing, it appears to be the way the two songs refer to the rack. From the “RackHost” entries in two .cantabileSong files:

S1:

"RackFile": "C:\\SoundLib\\Cantabile\\Racks\\Rig\\Rig.cantabileRack",
"RackFileRelative": "..\\..\\Racks\\Rig\\Rig.cantabileRack",

S2:

"RackFile": "C:\\SoundLib\\Cantabile\\Racks\\Rig\\Rig.cantabileRack",
"RackFileRelative": "C:\\SoundLib\\Cantabile\\Racks\\Rig\\Rig.cantabileRack",

It appears that C4 compares the “RackFileRelative” values to determine if the two racks are “the same”. Both “RackFileRelative” values shown above do resolve to the same file. However, the way it appears above, C4 will (incorrectly) re-load the Rack and re-trigger Rack->[On Load]. If I change either of the “RackFileRelative” to match the other file, the rack is (correctly) not re-loaded and the [On Load] events are not retriggered.

I’m not entirely sure how one “RackFileRelative” came to be relative and the other a full path specification. It may have to do with the Junctions I was formerly using, and it may be that this situation would never arise for other folks, but I’m thinking that …

Maybe C4 could be smarter about resolving “RackFileRelative” path names?

3

Not sure what’s going on here. Cantabile should be comparing the fully qualified name of the file since that’s all it stores internally anyway - the relative paths are only generated/resolved on save and load.

Note the relative path is resolved against the path of the song. What is the path of S1? Any chance it causes the rack to resolve to a different location where you have a second copy of the rack?

I’d be interested to see a log file of this showing switch between the two songs. Perhaps also a copy of the two song files and I’ll see if I can figure out what’s going on.

Brad

4

This issue relates to my (misguided) use of two NTFS Junctions to my real C4 datastore:

C:/SoundLib ==NTFS Junction==> E:/Dropbox/SoundLib

D:/SoundLib ==NTFS Junction==> E:/Dropbox/SoundLib

My /Cantabile directory (with all content, including Settings) is a sub-directory of /SoundLib. The two different Junctions caused C4 song files (and other JSON files) to accumulate a mixture of C: and D: file references. Bad idea.

My original assessment of this [Rig] rack reload issue was not correct:

This does not cause a reload of the [Rig] rack.

The real issue is the difference between:

S1:

"RackFile": "C:\\SoundLib\\Cantabile\\Racks\\Rig\\Rig.cantabileRack",

S2:

"RackFile": "D:\\SoundLib\\Cantabile\\Racks\\Rig\\Rig.cantabileRack",

Which does (understandably) cause a reload of the [Rig] rack.

My solution (got a show Tuesday … hope this works!) is to write a perl script to hack all my relevant Cantabile files. For me, that comprises .cantabileSong, .cantabileRecSet, and .cantabileSetList files, along with settings.json in each configuration directory I use. The script will:

  • Change each D:/SoundLib reference to C:/SoundLib, and
  • Change all “*FileRelative”: entries to a relative reference, based on the location (actually the directory depth) of the file being hacked.

I’ll then (gulp) remove the D:/SoundLib junction and see if things work …

5

I did process all files through my script and it appears to be successful … Cantabile runs with no issues, and the racks are not re-loaded on song changes.

Note that I only did the first time and not do the second item listed below in my script … since Brad suggested it was not necessary (since C4 resets the FileRelative entries).

1 Like
6

Hi Clint,

Glad you got this sorted!

Brad