joslloand
commented
8 years ago Hi @lossius, yes, separating out LFE for sending to another track makes sense.
Here's an important FYI...
In reworking the fixed matrices for loading, I've realised that we need to solve the conflict between different channel ordering between atk-sc3 and atk-reaper. The 5_0, 7_0 and quad encoders/decoders are the main culprits here.
I'm for 5_0 and 7_0, I'm going to make two new matrices called 5_1 and 7_1. The _1 (LFE) will be ignored / blank as the current practice with BR's TOA.
What this'll mean:
- atk-sc3 & atk-reaper get a new encoder / decoder called 5_1
- atk-sc3 & atk-reaper get get a new encoder called 7_1
- atk-sc3 keeps its old 5_0 and 7_0 encoders / decoders
- atk-reaper deprecates its old 5_0 and 7_0 encoders / decoders (as that function is assumed by the new _1s)
The rationale for this thinking:
- the external matrix loading is intended to stabilise and unify atk-sc3 & atk-reaper
- e.g., only need to add new encoders/decoders once - and both sc3 and reaper get the benefits
- no drift between matrices available on separate platforms!
Why deprecate the current use of _0 names on atk-reaper?
- These are already behaving like _1 encoders/decoders (a la BR's TOA).
- atk-reaper is described as being in beta
Does this make sense? (Hope so!)
In any case, at the moment I'm writing code to chuck out the matrices, and am writing out both the "old" and the "new" ones, so these will be available to load....
This will be shorter than the encode mono and stereo tutorials, and mostly focusing on how yo need to work with tracks and send/receive routings in Reaper.
The idea is to encode the regular channels using 5_0 or 7_0 encoders (and then exposed to further transforms such as rotations), while the LFE channel is routed to a different track where it is encoded using the Omni encoder.
Do this makes sense with respect to what way to best encode LFE, @joslloand ?