Search:
Submit Search


Why doesn't this work? - enclosure switch test

Using the CODM to create your own organ definitions, exchange CODM organ definitions, ...

Why doesn't this work? - enclosure switch test

Postby ldeutsch » Wed Dec 15, 2010 5:36 pm

I responded to a post in the "enhancements" section of this forum a couple days ago with a suggestion on how to use the CODM to create a switch to selectively make a division enclosed in a chamber. I decided to use my airplane ride yesterday to create an example to post so that others could use the idea for their own designs. However, what I actually discovered was that something appears to be wrong with either the CODM interpreter or my understanding of it.

I created a simple CODM organ using only the material delivered with HW - so any of you can try this. The organ has a single division, the Great, and four stops. I also created a second dummy division that has the same four stops, but these are enclosed with the exception of the "en chamade" rank. Then you can select two couplers to transfer the dummy division so it plays from the Great keyboard instead of the Great's regular ranks. This is done using a Great Unison Off coupler (which I labeled "Great Enclosed") and a "dummy to Great 8'" coupler. In the first file,

http://www.nightbloomingjazzmen.com/HW%2DExamples/Les-Expression-Example.CustomOrgan.Hauptwerk.xml

I have displayed both couplers so you can verify that selecting them both results in the desired action.

In the second file

http://www.nightbloomingjazzmen.com/HW%2DExamples/Les-Expression-Example-2.CustomOrgan.Hauptwerk.xml

the only difference is that I have hidden the "dummy to Great" coupler and tied it to the other coupler using the

<CouplerCodeFromWhichToCopyState>1106</CouplerCodeFromWhichToCopyState>

line so that they move together - in theory. However, they actually do not move together. Instead, the "dummy to Great" coupler always has the opposite state from the "Unison off" coupler.

I am at a loss to understand this behavior so after a few hours of trying to debug this, I decided to post the two files to see if someone else can solve the problem.

I am trying this on a MacBook Pro running system 10.6 and I have HW 3.3.

Les
User avatar
ldeutsch
Member
 
Posts: 449
Joined: Tue Mar 04, 2008 1:02 pm
Location: Chatsworth, California, USA

Re: Why doesn't this work? - enclosure switch test

Postby mdyde » Thu Dec 16, 2010 12:55 pm

Hello Les,

I've been looking at this today, and have found the issue:

If using CouplerCodeFromWhichToCopyState then the CODM makes the referring coupler behave as an 'off' coupler (inverting the action, as with 'unison off') if and only if the referenced coupler is a unison-off coupler, and conversely.

It behaves that way to make it possible for custom unison-off couplers to copy their states from other standard unison-off couplers so that internal/floating divisions are possible. For example, ExampleCustomOrgan2 has an internal 'swell reeds' division (to allow for the Swell Reeds on Choir) so a Swell Reeds Unison Off coupler is needed which copies both state and inverting behaviour from the Swell Unison Off coupler.

Hence if you copy the state of a coupler between a unison-off coupler and another coupler then both or neither will automatically become 'off' (inverted) couplers.

Thus I'm afraid I don't think your idea to load all ranks twice into memory and use copy-couplers to switch between the enclosed and unenclosed versions of the ranks would be possible - sorry.

That said, I rather doubt that anybody would want to do it in practice anyway, since having switchable expression for a division isn't a common requirement, and doubling a sample set's memory usage to achieve it probably wouldn't be a trade-off that would normally be considered worthwhile.

Anyway, as in the original post:

http://forum.hauptwerk.com/viewtopic.php?f=5&t=7729

... we've logged as an enhancement request that Hauptwerk could have some native functionality (independent of sample set) to make MIDI expression pedals switchable in real-time between/to virtual expression pedals, so that could cover what you want to do for the longer-term.
Best regards,
Martin.

[Please use email or the Contact page if you need to contact us privately, rather than private forum messages.]

Image
User avatar
mdyde
Moderator
 
Posts: 10644
Joined: Fri Mar 14, 2003 2:19 pm
Location: UK

Re: Why doesn't this work? - enclosure switch test

Postby ldeutsch » Thu Dec 16, 2010 1:55 pm

Martin,

Thanks. I didn't think I was making any mistakes on this.

I suggest that a good enhancement would be to allow stops and couplers to track the inverted state of another switch in addition to tracking the same sate. One could indicate this with a negative number in the same line so you wouldn't need to create a new XML code for it if you didn't want to. This would add a great deal of flexibility in creating not only the switchable expression shoe, but also alterable voices.

It would be even nicer to have variables and some conditional statements in the CODM language. This would make the CODM as powerful as the best custom organ control systems on the market today. If you want to go this route and need some help defining the language, I would be happy to assist. As a mathematician I have a great deal of experience with such "little languages".

Les
User avatar
ldeutsch
Member
 
Posts: 449
Joined: Tue Mar 04, 2008 1:02 pm
Location: Chatsworth, California, USA

Re: Why doesn't this work? - enclosure switch test

Postby mdyde » Thu Dec 16, 2010 2:10 pm

Hello Les,

I suggest that a good enhancement would be to allow stops and couplers to track the inverted state of another switch in addition to tracking the same sate. One could indicate this with a negative number in the same line so you wouldn't need to create a new XML code for it if you didn't want to. This would add a great deal of flexibility in creating not only the switchable expression shoe, but also alterable voices.


I'll log it as another enhancement request.

It would be even nicer to have variables and some conditional statements in the CODM language. This would make the CODM as powerful as the best custom organ control systems on the market today. If you want to go this route and need some help defining the language, I would be happy to assist. As a mathematician I have a great deal of experience with such "little languages".


We already have a fully-fledged extremely powerful 'programming language' for Hauptwerk in the form of the 'full' organ definition format, which can implement any arbitrarily-complex virtual organ relay. If you want to do complex things then I'd recommend learning that instead.

I'm afraid we don't have time to provide formal support for it (except to the major sample set producers, since it's complex and requires a significant amount of time to learn and support), but if you want to teach yourself to use it then email Brett to request a copy of the sample set creator's guide, which covers it.

The CODM is specifically designed to be easy and quick to learn and use, whilst being sufficiently powerful to achieve what most people would want to do most of the time. We don't want to make that more and more arbitrarily complex, otherwise we'd just end with another format that nobody except computer programmers would be inclined/able to use.

Hence my recommendation would be to learn the full ODF format if you want to do complex things (but again, you're on your own if you want to use it, I'm afraid, since we don't have enough time to provide support/training for it, beyond providing the documentation).
Best regards,
Martin.

[Please use email or the Contact page if you need to contact us privately, rather than private forum messages.]

Image
User avatar
mdyde
Moderator
 
Posts: 10644
Joined: Fri Mar 14, 2003 2:19 pm
Location: UK


Return to Custom Organ Design Module (CODM)

Who is online

Users browsing this forum: No registered users and 1 guest