The manual says:"At most one tremulant can be attached to any given rank within the Custom Organ Design Module."Suppose I want a divisional soft trem for hymns and individual bold trems for groups of TO ranks within a division? Either with the built-in trem feature or the separate trem rank feature.Is there a way to program the CODM around this restriction? Or the ODF?

I don't know the details of programming, but any RANK can have its own trem. If you study the screenshots of Hauptwerk theatre organs you'll see that there are several trems on the larger instruments, each affecting a few ranks. Quite often all the Tibias and Voxes are on the same tremulant tab for instance.

Trems produced in software can be adjusted for speed (by a slider) or other parameters such as depth (via Hauptwerk's voicing controls). If tremulants are produced by providing two ranks - one straight and one tremmed - then you have no control over the parameters of the tremmed ranks, but complete control over which ranks sound tremulated. You could have a separate tremulant switch for every rank in an organ if you wished.

Within the CODM, any given virtual rank (entry in the Rank table) may definitely have at most a single modelled tremulant applied (via its Rank.Trem_... attributes). For 'sampled trems' the same restriction effectively holds via the StopRank....AlternateRank... attributes. Either way, the CODM was only designed to support a single tremulant per rank.

A conceivable work-around might be to use modelled tremulants but have two otherwise-identical entries for the pipe rank in the Rank table -- one with the 'soft trem' specified (via its Rank.Trem_... attributes), and the other with the 'bold trem' specified (via its Rank.Trem_... attributes). The StopRank entry that connects the stop would then specify the first Rank entry as the main rank, and the second rank entry as its 'alternate rank', with the StopRank.StopCodeToSwitchToAlternateRank specifying another (dummy) Stop entry that was displayed and labelled to indicate that it was the 'bold trem'. The 'bold' Tremulant entry itself would then need to be non-displayed and default to engaged (so that it was permanently running). However, the work-around wouldn't be ideal work-around because:

1. You would then have two copies of the samples loaded in memory and their routing and voicing would be duplicated, and:2. It wouldn't model the acoustic effects of both tremulants being engaged simultaneously, and:3. The second (e.g. 'bold') tremulant wouldn't start up and slow down gradually, instead retriggering the samples.

Within the 'full' ODF format it's technically possible to apply multiple tremulants to a single rank, or indeed to implement any logic at all, but we don't provide official support for the ODF format, since it's very complex.